Re: [Xen-devel] [PATCH 5/5] xen: add new hypercall to get grant table limits

[Juergen Gross <jgross@xxxxxxxx>]

On 24/08/17 17:04, Jan Beulich wrote:
>>>> On 24.08.17 at 16:48, <jgross@xxxxxxxx> wrote:
>> On 24/08/17 16:28, Jan Beulich wrote:
>>>>>> On 21.08.17 at 20:05, <jgross@xxxxxxxx> wrote:
>>>> Today a guest can get the maximum grant table frame number for the
>>>> currently selected grant table interface version (1 or 2) only. Add
>>>> a new grant table operation to get the limits of both variants in
>>>> order to give the guest an opportunity to select the version serving
>>>> its needs best.
>>>>
>>>> Background for the need for this new hypercall is that e.g. the Linux
>>>> kernel won't use v2 as long as this will allow less active grants as
>>>> v1. As soon as the kernel can detect it can create as many v2 entries
>>>> as for v1, it will have no reason not to use v2. And this will allow
>>>> Xen placing a pv-domain with such a kernel above the current 16TB
>>>> RAM limit.
>>>>
>>>> For setting up the grant table a kernel needs the following
>>>> information:
>>>> - current version (kexec case)
>>>> - current size (kexec case)
>>>> - max size v1
>>>> - max size v2
>>>> In order not to have to issue 3 hypercalls (GNTTABOP_query_size,
>>>> GNTTABOP_get_version, GNTTABOP_get_v1_and_v2_max), let the new
>>>> hypercall return all the needed information.
>>>
>>> I'm not sure I follow: v2 is always going to allow less active grants
>>> than v1, as the limit is always derived from the number of frames
>>> allowed for a domain.
>>
>> Right. Patch 3 adds support for different number of allowed frames for
>> v1 and v2. So the system can be configured to allow the same max.
>> number of grants for v1 and v2, or even more v2 grants than v1.
>>
>>> I also don't see a problem with issuing multiple
>>> calls - none of this ought to be performance critical. I would,
>>> however, agree that rather than adding a new hypercall to just
>>> return the max sizes adding one like you suggest would be
>>> preferable. I'm simply not convinced yet that returning the max
>>> sizes is actually necessary.
>>
>> How would the guest know whether using v2 grants is no disadvantage?
> 
> As said - it's always going to be a disadvantage. Even if controlling
> the number of frames per-domain, that same number of frames
> will always fit more v1 than v2 entries.

And my patches break the assumption "same number of frames".

> I don't think the config
> setting should directly control the number of active grants.

Why not? In the end that number is the one the guest is interested in.
BTW: the number of needed maptrack frames is depending on the number
of grants only, not on v1 or v2. And the default for the max. number
of maptrack frames is much higher than the one of the grant frames
(1024 vs 32).

> Or if we did it that way, then the answer to your question would be
> "based on hypervisor version".

Yeah, or based on the answer from the hypervisor regarding my new
info call (if the answer is "-ENOSYS" the guest probably would choose
v1 as today).


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel