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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 26 Sep 2014, Konrad Rzeszutek Wilk wrote:
> 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@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
> > minute.
> 
> I am in favour of reverting things. That is a simple way of fixing
> bugs :-)

Unfortunately in this case it is complicated :-)

The real cause of the problem are Zoltan's changes to netback to switch
to grant mapping operations on ARM. Unfortunately when we realized it,
Linux 3.15 had already been released so we tried to fix the issue
instead. It turns out that the fix doesn't work on non-LPAE dom0.
Reverting the LPAE-only fix still gives you a broken setup.


> > 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?

No


> Is the Linux code able to boot without this flag?

It can boot but later on it would encour into serious issues if the
kernel in question is used as dom0 kernel and you have dma-capable
network devices on your platform.


> Let me rephrase - will it boot in the same fashion (And with the same
> bugs) as it did prior to this functionality being introduced?

3.15 -> dom0 on ARM broken (if netback is used)
3.17 -> dom0 on ARM is fixed, only if the kernel is compiled with 
CONFIG_ARM_LPAE

Reverting the XENFEAT_grant_map_identity related changes would give you
a system broken even with CONFIG_ARM_LPAE.
Reverting Zoltan's changes to netback would give you a working system.



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

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