On 11/26/19 1:26 PM, Durrant, Paul wrote: >> -----Original Message----- >> From: George Dunlap <george.dun...@citrix.com> >> Sent: 26 November 2019 12:32 >> To: Paul Durrant <pdurr...@gmail.com>; Durrant, Paul <pdurr...@amazon.com> >> Cc: xen-devel <xen-devel@lists.xenproject.org>; Stefano Stabellini >> <sstabell...@kernel.org>; Julien Grall <jul...@xen.org>; Wei Liu >> <w...@xen.org>; Konrad Rzeszutek Wilk <konrad.w...@oracle.com>; George >> Dunlap <george.dun...@eu.citrix.com>; Andrew Cooper >> <andrew.coop...@citrix.com>; Ian Jackson <ian.jack...@eu.citrix.com>; Jan >> Beulich <jbeul...@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 <pdurr...@amazon.com> wrote: >>>> >>>> ...when their values are larger than the per-domain configured limits. >>>> >>>> Signed-off-by: Paul Durrant <pdurr...@amazon.com> >>>> --- >>>> Cc: Andrew Cooper <andrew.coop...@citrix.com> >>>> Cc: George Dunlap <george.dun...@eu.citrix.com> >>>> Cc: Ian Jackson <ian.jack...@eu.citrix.com> >>>> Cc: Jan Beulich <jbeul...@suse.com> >>>> Cc: Julien Grall <jul...@xen.org> >>>> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> >>>> Cc: Stefano Stabellini <sstabell...@kernel.org> >>>> Cc: Wei Liu <w...@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?
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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
