[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.