Re: [PATCH v2 for-4.7] docs: Feature Levelling feature document

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 03/06/16 15:59, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH for-4.7] docs: Feature Levelling feature document"):
>> On 01/06/16 13:14, Ian Jackson wrote:
>>> IMO xl ought to have the moving parts necessary to allow an
>>> administrator to: 1. collect feature information from their hosts;
>>> 2. combine that information into the desired feature set to expose to
>>> guests; 3. specify the feature set in their host configuration; 4. do
>>> all of the above conveniently, without seddery.
>>>
>>> We should assume that the administrator has available tools like
>>> GNU parallel, ansible, or whatever.
>>>
>>> I don't want to design this now but I do want the feature levelling
>>> documentation to welcome suggestions for it, or at least not to seem
>>> to rule it out.
>> 1) is currently available via the `xen-cpuid` binary introduced,
>> although I intended it more as a developer tool
>>
>> Combining is the awkward part, but in the common case, it is just a
>> bitwise AND of the bitmaps provided by `xen-cpuid`.
> Right.
>
>> 3) I don't know what you mean about their host configuration.  Do you
>> mean guest configuration?
> No, I mean that
>
> 1. the admin should have the ability to write a default to be used for
>    all guests, in one place
>
> 2. the admin should have the ability to write this information
>    somewhere other than the domain config file (because domain config
>    files are often generated by other tools)

Ah ok - I see what you mean now.  This is a non-trivial UX problem to
solve, especially as any stashed default is stale as soon as you reboot
the host, but I agree that we can definitely do better than the current
status quo.

>
>> All of this works in combination with the existing cpuid= guest
>> configuration.
> Great.  Documentation on how to do it `by hand' would be nice but I
> don't think it's essential.

Sadly, while the most common case is easy, there are many sharp edges a
user should be aware of before playing in this area.

A part of the submitted series was to do with sanding some of the edges
in Xen, so that a misinformed toolstack can't actually advertise
features to the guest which Xen can't fulfil.

>
> Below: incremental diff as a "squash!" patch, followed by combined
> updated patch.

Thanks.  I have folded it in and submitted a v2.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel