Re: Xen Project policy on feature flags

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

On 26/09/14 14:39, Jan Beulich wrote:
>>>> On 26.09.14 at 15:24, <stefano.stabellini@eu.citrix.com> wrote:
>> I am writing to request a clarification on Xen feature flags
>> (XENFEAT_*) and backward compatibility:
>>     
>> is the hypervisor allowed to remove any feature flags in a future
>> release, even though doing so might break some existing guests?
>>
>> For example one could write a PV on HVM guest that requires
>> XENFEAT_hvm_callback_vector (regardless of PVH), could a future Xen
>> release remove that feature? Or is it now part of our ABI, therefore
>> maintained for backward compatibility, following the rule that we don't
>> break existing guests?
>>
>>
>> I always thought that any XENFEAT feature flags could be removed going
>> forward, if the hypervisor maintainers decide to do so. However Ian
>> Campbell is of the opposite opinion, so I think we should have a clear
>> policy regarding them.
>>
>> In any case I think that it is generally useful to have optional flags
>> that advertise the presence of a feature but can also be removed going
>> forward. If XENFEAT feature flags are not them, then we might still want
>> to introduce them as a separate concept.
> My view is that these are precisely there to indicate what the
> hypervisor supports. I.e. while we can't remove the definition
> from the public header, the hypervisor could stop advertising that
> it's capable of a certain feature at any time. Consumers are
> expected to check for the feature flag and deal with it being off.

Agreed.  It is an administrator policy whether their deployed Xen
supports all the features, or a subset.  (e.g. disabling features for
embedded or security-surface reasons)

In this case it is fine for a guest not to function if its minimum
required featureset not completely supported by Xen, but it should fail
with "Xen doesn't support required feature $FOO".

~Andrew