Re: Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues)

[Stefano Stabellini <sstabellini@kernel.org>]

On Thu, 20 May 2021, Julien Grall wrote:
> On 20/05/2021 00:25, Stefano Stabellini wrote:
> > On Sat, 15 May 2021, Julien Grall wrote:
> > > > My feeling is one of two things should happen with the /hypervisor
> > > > address range:
> > > > 
> > > > 1>  OSes could be encouraged to use it for all foreign mappings.  The
> > > > range should be dynamic in some fashion.  There could be a handy way to
> > > > allow configuring the amount of address space thus reserved.
> > > 
> > > In the context of XSA-300 and virtio on Xen on Arm, we discussed about
> > > providing a revion for foreign mapping. The main trouble here is figuring
> > > out
> > > of the size, if you mess it up then you may break all the PV drivers.
> > > 
> > > If the problem is finding space, then I would like to suggest a different
> > > approach (I think I may have discussed it with Andrew). Xen is in
> > > maintaining
> > > the P2M for the guest and therefore now where are the unallocated space.
> > > How
> > > about introducing a new hypercall to ask for "unallocated space"?
> > > 
> > > This would not work for older hypervisor but you could use the RAM instead
> > > (as
> > > Linux does). This is has drawbacks (e.g. shattering superpage, reducing
> > > the
> > > amount of memory usuable...), but for 1> you would also need a hack for
> > > older
> > > Xen.
> > 
> > I am starting to wonder if it would make sense to add a new device tree
> > binding to describe larger free region for foreign mapping rather then a
> > hypercall. It could be several GBs or even TBs in size. I like the idea
> > of having it device tree because after all this is static information.
> > I can see that a hypercall would also work and I am open to it but if
> > possible I think it would be better not to extend the hypercall
> > interface when there is a good alternative.
> 
> There are two issues with the Device-Tree approach:
>   1) This doesn't work on ACPI
>   2) It is not clear how to define the size of the region. An admin doesn't
> have the right information in hand to know how many mappings will be done (a
> backend may map multiple time the same page).
> 
> The advantage of the hypercall solution is the size is "virtually" unlimited
> and not based on a specific firmware.

Fair enough