Re: Aligning Xen to physical memory maps on embedded systems

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 22 Feb 2021, Julien Grall wrote:
> (+ Stefano)

Hi Julien, thanks for CCing me.


> On 21/02/2021 16:30, Levenglick Dov wrote:
> > Hi,
> 
> Hi,
> 
> > I am booting True Dom0-less on Xilinx ZynqMP UltraScale+ using Xen 4.11,
> > taken from https://github.com/Xilinx/xen.
> 
> This tree is not an official Xen Project tree. I can provide feedback based on
> how Xen upstream works, but I don't know for sure if this will apply to the
> Xilinx tree.
> 
> For any support, I would recommend to contect Xilinx directly.
> 
> > The system has 2GB of RAM (0x00000000 - 0x80000000) of which Xen and the
> > DomU
> > have an allocation of 1.25GB, per this memory map:
> > 1. DomU1: 0x60000000 - 0x80000000
> > 2. DomU2: 0x40000000 - 0x60000000
> > 3. Xen: 0x30000000 - 0x40000000
> 
> How did you tell Xen which regions is assigned to which guests? Are your
> domain mapped 1:1 (i.e guest physical address == host physical address)?
> 
> > I am able to support True Dom0-less by means of the patch/hack demonstrated
> > By Stefano Stabellini at https://youtu.be/UfiP9eAV0WA?t=1746.
> > 
> > I was able to forcefully put the Xen binary at the address range immediately
> > below 0x40000000 by means of modifying get_xen_paddr() - in itself an ugly
> > hack.
> > 
> > My questions are:
> > 1. Since Xen performs runtime allocations from its heap, it is allocating
> >     downwards from 0x80000000 - thereby "stealing" memory from DomU1.
> 
> In theory, any memory reserved for domains should have been carved out from
> the heap allocator. This would be sufficient to prevent Xen allocating memory
> from the ranges you described above.
> 
> Therefore, to me this looks like a bug in the tree you are using.
> 
> >     Can I force the runtime allocations to be from a specific address range?
> > 2. Has the issue of physical memory map address maps been addressed by Xen
> > for embedded?
> 
> Xen 4.12+ will not relocate itself to the top of the memory anymore. Instead,
> it will stay where it was first loaded in memory.
> 
> I would recommend to ask Xilinx if they can provide you with a more recent
> tree.

The following is based on 4.13:

https://github.com/xilinx/xen/tree/xilinx/release-2020.2