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

[Oleksandr <olekstysh@xxxxxxxxx>]

On 06.08.21 03:30, Stefano Stabellini wrote:

Hi Stefano

> 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
Thank you for the ideas.

If I got the idea correctly, yes, as these ranges represent the real 
RAM, so no I/O would be in conflict with them and as the result - no 
overlaps would be expected.
But, I wonder, would this work if we have IOMMU enabled for Dom0 and 
need to establish 1:1 mapping for the DMA devices to work with grant 
mappings...
In arm_iommu_map_page() we call guest_physmap_add_entry() with gfn = 
mfn, so the question is could we end up with this new gfn replacing the 
valid mapping
(with gfn allocated from the safe region)?


> 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.
Unfortunately, yes.


--
Regards,

Oleksandr Tyshchenko