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

[Oleksandr Andrushchenko <andr2000@gmail.com>]

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
>