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

From: Julien Grall <julien@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Elliott Mitchell <ehem+xen@m5p.com>,
	xen-devel@lists.xenproject.org,
	Roger Pau Monn?? <royger@freebsd.org>,
	Mitchell Horne <mhorne@freebsd.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Uses of /hypervisor memory range (was: FreeBSD/Xen/ARM issues)
Date: Thu, 20 May 2021 10:51:57 +0100	[thread overview]
Message-ID: <b6fe6e06-517c-ee4c-5b71-a1bee4d4df13@xen.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2105191611540.14426@sstabellini-ThinkPad-T480s>

Hi Stefano,

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.

Cheers,

-- 
Julien Grall