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

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 26/09/14 14:24, Stefano Stabellini wrote:
> Hello all,
> 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.

A guest that runs on Xen version V /must/ continue to run on V+1.

The is similar to the policy the Linux kernel has for the user space ABI.

This does permit support for features to be removed but only if no guest
would be broken by its removal.  But since it it is not possible to know
what guests people have running and what features they require, I can't
see how any feature could be safely removed.

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

I don't think "optional" feature flags are any different.  You can
specify that guests must handle the feature being missing but that's no
guarantee that guest will actually implement the fallback.

David

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