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

[Oleksandr <olekstysh@gmail.com>]

On 03.08.21 15:53, Jan Beulich wrote:

Hi, Jan

Thank you for the input.

> On 30.07.2021 18:13, Oleksandr wrote:
>> Well, if new hypercall and, what is more, "the querying hypervisor at
>> runtime to find unused space" model itself is not welcome, I am ok,
>> let's try to create a working system,
>> may we please find a common ground to move this forward (at least on Arm
>> for now, the foreign mapping is the most important question).
>>
>> I got the proposed idea in general, but I haven't connected all dots
>> yet, some points need clarification.
>>
>> 1. The safe range must be defined/allocated in advance and must remain
>> const during the runtime. The safe range must be chosen by the toolstack.
>> [For the initial implementation we can start with some large value
>> (128GB) as discussed above]
>>
>> Questions:
>>
>> - Do we need to inform Xen about that range (via domain_create
>> hypercall, etc)?
>> - What will be in charge of guaranteeing the safety of that range at
>> runtime (reject new mapping requests with possible overlaps, etc), Xen,
>> toolstack or both?
> Well, what other entity than Xen could enforce this? (By implication,
> the answer to the earlier question can imo only be "yes", unless it's
> Xen itself to establish the region.)

Indeed, agree.


>
>> - Where that range should be located in guest address space, should that
>> range be the same for all domains (how GUEST_GNTTAB_BASE(SIZE) for example)
>> or it should be calculated based on actual guest_ram_base(size) for a
>> particular domain?
> The default size may well be fixed or amount-of-memory-dependent, but
> I think there will need to be a way to enlarge the region for guests
> with particular needs.
Well, but why we couldn't just make a large chunk by default which would
satisfy all guests, as it was mentioned earlier in this thread "as it 
doesn't consume resource when not being used"
to avoid an extra configuration option, etc?


>
>> - What about a safe range the Dom0 can use itself? Xen should choose it
>> for Dom0 the same way how toolstack chooses it for other domains, correct?
>>
>> 2. The safe range must be provided to domain using the firmware table.
>> [We can start with the DTB and leave ACPI unimplemented for now,
>> assuming we will be able to solve open questions as discussed above]
>>
>> Questions:
>>
>> - Do we need distinguish between foreign and grant mappings at the
>> domain side at all? Can the same safe range be used for all types of
>> mapping?
> Like Stefano I don't think so.

Agree.

-- 
Regards,

Oleksandr Tyshchenko