Re: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 11/26/19 1:26 PM, Durrant, Paul wrote:
>> -----Original Message-----
>> From: George Dunlap <george.dunlap@xxxxxxxxxx>
>> Sent: 26 November 2019 12:32
>> To: Paul Durrant <pdurrant@xxxxxxxxx>; Durrant, Paul <pdurrant@xxxxxxxxxx>
>> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; Stefano Stabellini
>> <sstabellini@xxxxxxxxxx>; Julien Grall <julien@xxxxxxx>; Wei Liu
>> <wl@xxxxxxx>; Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; George
>> Dunlap <George.Dunlap@xxxxxxxxxxxxx>; Andrew Cooper
>> <andrew.cooper3@xxxxxxxxxx>; Ian Jackson <ian.jackson@xxxxxxxxxxxxx>; Jan
>> Beulich <jbeulich@xxxxxxxx>
>> Subject: Re: [Xen-devel] [PATCH] domain_create: honour global
>> grant/maptrack frame limits...
>>
>> On 11/26/19 11:30 AM, Paul Durrant wrote:
>>> On Wed, 13 Nov 2019 at 13:55, Paul Durrant <pdurrant@xxxxxxxxxx> wrote:
>>>>
>>>> ...when their values are larger than the per-domain configured limits.
>>>>
>>>> Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
>>>> ---
>>>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
>>>> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>>>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
>>>> Cc: Julien Grall <julien@xxxxxxx>
>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>>>> Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>> Cc: Wei Liu <wl@xxxxxxx>
>>>>
>>>> After mining through commits it is still unclear to me exactly when Xen
>>>> stopped honouring the global values, but I really think this commit
>> should
>>>> be back-ported to stable trees as it was a behavioural change that can
>>>> cause domUs to fail in non-obvious ways.
>>>
>>> Any other opinions on this? AFAICT questions is still open:
>>>
>>> - Do we consider not honouring the command line values to be a
>>> regression (since domUs that would have worked before will no longer
>>> work after a basic upgrade of Xen)?
>>
>> This would be a bit easier to form a "policy" opinion on (or perhaps
>> alternate solutions to) if more of the situation were outlined here.
>>
>> Is the problem that the per-domain config is always set, and doesn't
>> take the hypervisor-set config into account?  Wouldn't it be better to
>> modify the toolstack to use the hypervisor value if it's not set?
>>
>> In fact, it looks kind of like things are screwed up anyway -- the
>> "default" value of max_grant_frames, if no value is specified, is set in
>> xl.c.  If that were the behavior we wanted, it should be set in libxl.c.
>>
>> But it doesn't seem like it should be terribly difficult to get a "use
>> the default" sentinel value passed in to Xen, such that:
>>
>> 1. People who don't do anything will get the default currently specified
>> in xl.c
>>
>> 2. People who set the value on the Xen command-line and don't set
>> anything in the guest config file will get the Xen command-line value
>>
>> 3. People who set the value in the config file will get the value they
>> specified (regardless of the global setting).
>>
>> Is that the behaviour you'd like to see, Paul?
> 
> I think the order should be:
> 
> If set in xl.cfg => use that, else
> If set in xl.conf => use that, else
> Use the command line/default value
> 
> I.e. the ultimate value should be set in Xen (and possibly overridden by the 
> command line) and not hardcoded at any other layer.
> 
> There is also the issue of limits but I guess the rationale there should be: 
> If a value *is* specified then it should not exceed the value set in Xen.
> 
> Does that sound right?

So part of the issue here sounds like a terminology issue.  Is it the
case that there's a default "max", and you want to raise the default
"max"; is that right?

But the documentation actually says:

"Specify the maximum number of frames which any domain may use as part
of its grant table."

Which makes it sound a lot more like a "maximum max" -- i.e., that any
domain which is created with a value higher than this should fail.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel