Re: [RFC PATCH] xen/memory: Introduce a hypercall to provide unallocated space

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 4 Aug 2021, Julien Grall wrote:
> > +#define GUEST_SAFE_RANGE_BASE   xen_mk_ullong(0xDE00000000) /* 128GB */
> > +#define GUEST_SAFE_RANGE_SIZE   xen_mk_ullong(0x0200000000)
> > 
> > While the possible new DT bindings has not been agreed yet, I re-used
> > existing "reg" property under the hypervisor node to pass safe range as a
> > second region,
> > https://elixir.bootlin.com/linux/v5.14-rc4/source/Documentation/devicetree/bindings/arm/xen.txt#L10:
> >  
> 
> So a single region works for a guest today, but for dom0 we will need multiple
> regions because it is may be difficult to find enough contiguous space for a
> single region.
> 
> That said, as dom0 is mapped 1:1 (including some guest mapping), there is also
> the question where to allocate the safe region. For grant table, we so far
> re-use the Xen address space because it is assumed it will space will always
> be bigger than the grant table.
> 
> I am not sure yet where we could allocate the safe regions. Stefano, do you
> have any ideas?

The safest choice would be the address range corresponding to memory
(/memory) not already allocated to Dom0.

For instance from my last boot logs:
(XEN) Allocating 1:1 mappings totalling 1600MB for dom0:
(XEN) BANK[0] 0x00000010000000-0x00000070000000 (1536MB)
(XEN) BANK[1] 0x00000078000000-0x0000007c000000 (64MB)

All the other ranges could be given as unallocated space:

- 0x0 - 0x10000000
- 0x70000000 - 0x78000000
- 0x8_0000_0000 - 0x8_8000_0000



The second best choice would be an hole: an address range not used by
anybody else (no reg property) and also not even mappable by a bus (not
covered by a ranges property). This is not the best choice because there
can cases where physical resources appear afterwards.