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

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

Hi, all!

What do we need in order to move on on this?

It seems this can be good to have for many use-cases around

Thank you,

Oleksandr

On 20.05.21 19:21, Stefano Stabellini wrote:
> 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