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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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.

(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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel