Re: Xen Project policy on feature flags

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Sep 26, 2014 at 03:19:32PM +0100, Ian Campbell wrote:
> On Fri, 2014-09-26 at 14:39 +0100, 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.
> 
> 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
> minute.

I am in favour of reverting things. That is a simple way of fixing
bugs :-)

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

Wasn't this feature considered 'experimental' in Linux code?

Is the Linux code able to boot without this flag? Let me rephrase - will
it boot in the same fashion (And with the same bugs) as it did prior
to this functionality being introduced?

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