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
