From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Xen Project policy on feature flags Date: Fri, 26 Sep 2014 10:29:59 -0400 Message-ID: <20140926142959.GA19421@laptop.dumpdata.com> References: <542588A90200007800039B3E@mail.emea.novell.com> <1411741172.26149.75.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1411741172.26149.75.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xensource.com, keir@xen.org, Tim Deegan , Stefano Stabellini , george.dunlap@eu.citrix.com, Ian Jackson , Lars Kurth , DavidVrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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, 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. >