Re: [PATCH 00/12] add per-domain and per-cpupool generic parameters

["Jan Beulich" <JBeulich@suse.com>]

>>> On 18.09.18 at 13:29, <george.dunlap@citrix.com> wrote:
> On 09/18/2018 12:23 PM, Jan Beulich wrote:
>>>>> On 18.09.18 at 13:20, <george.dunlap@citrix.com> wrote:
>>> On 09/18/2018 12:19 PM, Jan Beulich wrote:
>>>>>>> On 18.09.18 at 13:02, <jgross@suse.com> wrote:
>>>>> On 18/09/18 12:32, Jan Beulich wrote:
>>>>>>>>> On 18.09.18 at 08:02, <jgross@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.

Oh, I see - a completely different meaning of "mandatory": I was
assuming some options (say "xpti") would be considered mandatory
by the implementation.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel