[Xen-devel] Xen Project policy on feature flags

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.

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.

Cheers,

Stefano



P.S.
FYI the question has been raised in regards to
XENFEAT_grant_map_identity: we know now that it is not a complete
solution to the problem it was introduced to solve and we'll probably
want to remove it if/when we'll find a better alternative.
However if we cannot remove the feature in the future we would need to
get rid of it now, before is casted in stone in our ABI.

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