> -----Original Message----- > From: George Dunlap <[email protected]> > Sent: 26 November 2019 12:32 > To: Paul Durrant <[email protected]>; Durrant, Paul <[email protected]> > Cc: xen-devel <[email protected]>; Stefano Stabellini > <[email protected]>; Julien Grall <[email protected]>; Wei Liu > <[email protected]>; Konrad Rzeszutek Wilk <[email protected]>; George > Dunlap <[email protected]>; Andrew Cooper > <[email protected]>; Ian Jackson <[email protected]>; Jan > Beulich <[email protected]> > 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 <[email protected]> wrote: > >> > >> ...when their values are larger than the per-domain configured limits. > >> > >> Signed-off-by: Paul Durrant <[email protected]> > >> --- > >> Cc: Andrew Cooper <[email protected]> > >> Cc: George Dunlap <[email protected]> > >> Cc: Ian Jackson <[email protected]> > >> Cc: Jan Beulich <[email protected]> > >> Cc: Julien Grall <[email protected]> > >> Cc: Konrad Rzeszutek Wilk <[email protected]> > >> Cc: Stefano Stabellini <[email protected]> > >> Cc: Wei Liu <[email protected]> > >> > >> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
