Re: Hand over of the Xen shared info page

[Julien Grall <julien@xxxxxxx>]

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?
> 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.
> 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.
Cheers,

--
Julien Grall