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

From: "Durrant, Paul" <pdurrant@amazon.com>
To: George Dunlap <george.dunlap@citrix.com>,
	Paul Durrant <pdurrant@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH] domain_create: honour global grant/maptrack frame limits...
Date: Tue, 26 Nov 2019 13:26:49 +0000	[thread overview]
Message-ID: <fd50674c8f3c433093a92439c6778f8f@EX13D32EUC003.ant.amazon.com> (raw)
In-Reply-To: <cce5aa9a-6d3d-49ac-b633-21eaa1fcbd69@citrix.com>

> -----Original Message-----
> From: George Dunlap <george.dunlap@citrix.com>
> Sent: 26 November 2019 12:32
> To: Paul Durrant <pdurrant@gmail.com>; Durrant, Paul <pdurrant@amazon.com>
> Cc: xen-devel <xen-devel@lists.xenproject.org>; Stefano Stabellini
> <sstabellini@kernel.org>; Julien Grall <julien@xen.org>; Wei Liu
> <wl@xen.org>; Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>; George
> Dunlap <George.Dunlap@eu.citrix.com>; Andrew Cooper
> <andrew.cooper3@citrix.com>; Ian Jackson <ian.jackson@eu.citrix.com>; Jan
> Beulich <jbeulich@suse.com>
> 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@amazon.com> wrote:
> >>
> >> ...when their values are larger than the per-domain configured limits.
> >>
> >> Signed-off-by: Paul Durrant <pdurrant@amazon.com>
> >> ---
> >> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> >> Cc: George Dunlap <George.Dunlap@eu.citrix.com>
> >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >> Cc: Jan Beulich <jbeulich@suse.com>
> >> Cc: Julien Grall <julien@xen.org>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> Cc: Stefano Stabellini <sstabellini@kernel.org>
> >> Cc: Wei Liu <wl@xen.org>
> >>
> >> 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?

  Paul

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