[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 00/12] add per-domain and per-cpupool generic parameters
On 18/09/18 13:29, George Dunlap wrote: > On 09/18/2018 12:23 PM, Jan Beulich wrote: >>>>> On 18.09.18 at 13:20, <george.dunlap@xxxxxxxxxx> wrote: >>> On 09/18/2018 12:19 PM, Jan Beulich wrote: >>>>>>> On 18.09.18 at 13:02, <jgross@xxxxxxxx> wrote: >>>>> On 18/09/18 12:32, Jan Beulich wrote: >>>>>>>>> On 18.09.18 at 08:02, <jgross@xxxxxxxx> wrote: >>>>>>> Instead of using binary hypervisor interfaces for new parameters of >>>>>>> domains or cpupools this patch series adds support for generic text >>>>>>> based parameter parsing. >>>>>>> >>>>>>> Parameters are defined via new macros similar to those of boot >>>>>>> parameters. Parsing of parameter strings is done via the already >>>>>>> existing boot parameter parsing function which is extended a little >>>>>>> bit. >>>>>>> >>>>>>> Parameter settings can either be specified in configuration files of >>>>>>> domains or cpupools, or they can be set via new xl sub-commands. >>>>>> >>>>>> Without having looked at any of the patches yet (not even their >>>>>> descriptions) I'm still wondering what the benefit of textual parameters >>>>>> really is: Just like "binary" ones, they become part of the public >>>>>> interface, and hence subsequently can't be changed any more or >>>>>> less than the ones we currently have (in particular, anything valid in >>>>>> a guest config file will imo need to remain to be valid and meaningful >>>>>> down the road). >>>>>> >>>>>> If this is solely or mainly about deferring the parsing from the tool >>>>>> stack to the hypervisor, then I'm not at all convinced of the approach >>>>>> (I'd even be tempted to call it backwards). >>>>> >>>>> The main advantage is that it would be much easier to backport new >>>>> parameters like the xpti per-domain one. No need to bump sysctl/domctl >>>>> interface versions for that. >>>> >>>> Additions to sysctl/domctl interfaces don't require such a bump. >>>> >>>>> It might be a good idea to support mandatory and optional parameters >>>>> in the guest config. Optional parameters not supported by the hypervisor >>>>> would then be ignored instead of leading to failure at guest creation >>>>> time. >>>> >>>> Except that over time opinions may change what is supposed to >>>> be optional vs mandatory. >>> >>> I thought the idea would be that the admin would specify which ones were >>> optional or mandatory. >> >> If this was admin controlled, there would be no way to encode in >> the hypercall handler which ones to reject when unknown. Even >> without admin involvement it's not really clear to me how options >> we don't even know of today could be treated as either optional >> or mandatory. > > My interpretation was the hypervisor would always return "-ENOSYS" (or > whatever) when passed an unknown option, and the toolstack would decide > what to do about it -- whether to simply throw a warning or stop > creation of the domain. That way in some configs you could write: > > # Disable xpti if it's available, otherwise just run > optional_params=['xpti=off'] > > and other configs you could write: > > # Only run if we're certain we have xpti enabled > mandatory_params=['xpti=on'] > > The toolstack would attempt to enable / disable xpti during domain > creation, and DTRT if the hypercall failed. That was the idea, right. > (I admit I haven't looked at the series to see if that's compatible with > what's planned.) The series is implementing mandatory params only at the moment, but that would be easy to expand. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |