Re: Hand over of the Xen shared info page

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>]

Hi,

On 5/20/21 12:46 PM, Julien Grall wrote:
>
>
> On 20/05/2021 06:21, Oleksandr Andrushchenko wrote:
>> Hi, all!
>
> Hi,
>
>
>> On 5/20/21 2:11 AM, Stefano Stabellini wrote:
>>> On Wed, 19 May 2021, Julien Grall wrote:
>>>> On 14/05/2021 10:50, Anastasiia Lukianenko wrote:
>>>>> Hi Julien!
>>>> Hello,
>>>>
>>>>> On Thu, 2021-05-13 at 09:37 +0100, Julien Grall wrote:
>>>>>> On 13/05/2021 09:03, Anastasiia Lukianenko wrote:
>>>>>> The alternative is for U-boot to go through the DT and infer which
>>>>>> regions are free (IOW any region not described).
>>>>> Thank you for interest in the problem and advice on how to solve it.
>>>>> Could you please clarify how we could find free regions using DT in U-
>>>>> boot?
>>>> I don't know U-boot code, so I can't tell whether what I suggest would work.
>>>>
>>>> In theory, the device-tree should described every region allocated in address
>>>> space. So if you parse the device-tree and create a list (or any
>>>> datastructure) with the regions, then any range not present in the list would
>>>> be free region you could use.
>>> Yes, any "empty" memory region which is neither memory nor MMIO should
>>> work.
>>
>> You need to account on many things while creating the list of regions:
>>
>> device register mappings, reserved nodes, memory nodes, device tree
>>
>> overlays parsing etc. It all seem to be a not-that-trivial task and after
>>
>> all if implemented it only lives in U-boot and you have to maintain that
>>
>> code. So, if some other entity needs the same you need to implement
>>
>> that as well.
>
> Yes, there are some complexity. I have suggested other approach in a separate thread. Did you look at them?

Yes, so probably we can re-use the solution from that thread when it comes to some conclusion

and implementation.

>
>> And also you can imagine a system without device tree at all...
> Xen doesn't provide a stable guest layout. Such system would have to be tailored to a given guest configuration, Xen version (can be custom)...
>
> Therefore, hardcoding the value in the system (not in Xen headers!) is not going to make it much worse.
Agree to some extent
>
>> So, I am not saying it is not possible to implement, but I just question if
>>
>> such an implementation is really a good way forward.
>>
>>>
>>>
>>>> However, I realized a few days ago that the magic pages are not described in
>>>> the DT. We probably want to fix it by marking the page as "reserved" or create
>>>> a specific bindings.
>>>>
>>>> So you will need a specific quirk for them.
>>> It should also be possible to keep the shared info page allocated and
>>> simply pass the address to the kernel by adding the right node to device
>>> tree.
>> And then you need to modify your OS and this is not only Linux...
>>> To do that, we would have to add a description of the magic pages
>>> to device tree, which I think would be good to have in any case. In that
>>> case it would be best to add a proper binding for it under the "xen,xen"
>>> node.
>>
>> I would say that querying Xen for such a memory page seems much
>>
>> more cleaner and allows the guest OS either to continue using the existing
>>
>> method with memory allocation or using the page provided by Xen.
>
> IIUC your proposal, you are asking to add an hypercall to query which guest physical region can be used for the shared info page.
>
> This may solve the problem you have at hand, but this is not scalable. There are a few other regions which regions unallocated memory (e.g. grant table, grant mapping, foreign memory map,....).
>
> So if we were going to involve Xen, then I think it is better to have a generic way to ask Xen for unallocated space.
Agree
>
> Cheers,
>
Thank you,

Oleksandr