From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Xen Project policy on feature flags Date: Fri, 26 Sep 2014 14:56:35 +0100 Message-ID: <54257093.5010809@citrix.com> References: <542588A90200007800039B3E@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <542588A90200007800039B3E@mail.emea.novell.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: Jan Beulich , Stefano Stabellini , xen-devel@lists.xensource.com Cc: keir@xen.org, Tim Deegan , george.dunlap@eu.citrix.com, Ian Jackson , Lars Kurth , DavidVrabel , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 26/09/14 14:39, 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. Agreed. It is an administrator policy whether their deployed Xen supports all the features, or a subset. (e.g. disabling features for embedded or security-surface reasons) In this case it is fine for a guest not to function if its minimum required featureset not completely supported by Xen, but it should fail with "Xen doesn't support required feature $FOO". ~Andrew