[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen Project policy on feature flags

On 26/09/14 14:39, Jan Beulich wrote:
>>>> On 26.09.14 at 15:24, <stefano.stabellini@xxxxxxxxxxxxx> 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".


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.