On 09/18/2018 12:23 PM, Jan Beulich wrote: >>>> On 18.09.18 at 13:20, <george.dun...@citrix.com> wrote: >> On 09/18/2018 12:19 PM, Jan Beulich wrote: >>>>>> On 18.09.18 at 13:02, <jgr...@suse.com> wrote: >>>> On 18/09/18 12:32, Jan Beulich wrote: >>>>>>>> On 18.09.18 at 08:02, <jgr...@suse.com> 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. (I admit I haven't looked at the series to see if that's compatible with what's planned.) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
