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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



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