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

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

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?

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

If we release with it then we will regress at least Linux 3.16 and 3.17
when we remove this flag.

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


Xen-devel mailing list



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