[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hand over of the Xen shared info page

On 20/05/2021 06:21, Oleksandr Andrushchenko wrote:
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!

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-
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

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
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"

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.


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.