Re: Hand over of the Xen shared info page

From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>
To: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>
Cc: Anastasiia Lukianenko <Anastasiia_Lukianenko@epam.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrii Chepurnyi <Andrii_Chepurnyi@epam.com>
Subject: Re: Hand over of the Xen shared info page
Date: Thu, 20 May 2021 05:21:07 +0000	[thread overview]
Message-ID: <4b686071-3260-87b1-d240-8d3c2b48f1f8@epam.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2105191604130.14426@sstabellini-ThinkPad-T480s>

Hi, all!

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. And also you can imagine a system without device tree at all...

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.