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

[Julien Grall <julien@xxxxxxx>]

Hi Andrew,

On 28/07/2021 18:19, Andrew Cooper wrote:
> On 28/07/2021 17:18, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> >
> > Add XENMEM_get_unallocated_space hypercall which purpose is to
> > query hypervisor to find regions of guest physical address space
> > which are unused and can be used to create grant/foreign mappings
> > instead of wasting real pages from the domain memory for
> > establishing these mappings. The problem with the current Linux
> > on Xen on Arm behaviour is if we want to map some guest memory
> > regions in advance or to perform cache mappings in the backend
> > we might run out of memory in the host (see XSA-300).
> > This of course, depends on the both host and guest memory sizes.
> >
> > The "unallocated space" can't be figured out precisely by
> > the domain on Arm without hypervisor involvement:
> > - not all device I/O regions are known by the time domain starts
> >    creating grant/foreign mappings
> > - the Dom0 is not aware of memory regions used for the identity
> >    mappings needed for the PV drivers to work
> > In both cases we might end up re-using these regions by
> > a mistake. So, the hypervisor which maintains the P2M for the domain
> > is in the best position to provide "unallocated space".
> I'm afraid this does not improve the situation.
>
> If a guest follows the advice from XENMEM_get_unallocated_space, and
> subsequently a new IO or identity region appears, everything will
> explode, because the "safe area" wasn't actually safe.
>
> The safe range *must* be chosen by the toolstack, because nothing else
> can do it safely or correctly.
The problem is how do you size it? In particular, a backend may map 
multiple time the same page (for instance if the page is granted twice).
> Once a safe range (or ranges) has been chosen, any subsequent action
> which overlaps with the ranges must be rejected, as it will violate the
> guarantees provided.
>
> Furthermore, the ranges should be made available to the guest via normal
> memory map means.  On x86, this is via the E820 table, and on ARM I
> presume the DTB.  There is no need for a new hypercall.
Device-Tree only works if you have a guest using it. How about ACPI?

To me the hypercall solution at least:
  1) Avoid to have to define the region on every single firmware table
  2) Allow to easily extend after the guest run

Cheers,

--
Julien Grall