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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.14 at 16:19, <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2014-09-26 at 14:39 +0100, 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.
> 
> What if there is no way to deal with it being off other than crashing or
> refusing to work etc?

Generally that would mean bad coding on the kernel side. But
in this specific case...

> The context here is XENFEAT_grant_map_identity which turns out not to
> work in practice (it doesn't actually allow non-LPAE arm32 dom0 to work,
> which it was supposed to). We've not released with it yet (as it stands
> it'll be included in 4.5).
> 
> We do have some other ideas for an alternative fix to the underlying
> issue. But we've not actually tried them yet.
> 
> IMHO We need to decide whether to nuke that flag now or in the future
> (i.e. post 4.5). Given that it doesn't actually work and that we've not
> released with it I'm most in favour of not releasing with it, and given
> that I'm in favour of removing it now and not waiting until the last
> minute.
> 
> If we release with it then we will regress at least Linux 3.16 and 3.17
> when we remove this flag.

... I agree removing it now (by reverting respective commit(s)) would
be better.

> I don't think we have many other flags which are "work at all" flags
> rather than "enhance" flags.

Indeed, and in such a case it may be a bad choice to consider this a
feature flag in the first place.

Jan


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