On 11/26/19 1:26 PM, Durrant, Paul wrote: >> -----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?
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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
