Re: [Qemu-devel] Dropped CPU feature names and backward compatibility

[Eduardo Habkost]

On Tue, Sep 18, 2018 at 03:26:18PM +0200, Jiri Denemark wrote:
> On Tue, Sep 18, 2018 at 10:14:45 -0300, Eduardo Habkost wrote:
> > On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote:
> > > Sure, libvirt could just avoid passing feature=off for any feature which
> > > is not supported by the QEMU binary it is about to start since such
> > > feature should be disabled anyway. And if it actually is enabled even if
> > > it is not supported (which can apparently happen according to the commit
> > > message which removed ospke), we can at least rely on QEMU doing it
> > > consistently. But what should we do if the user explicitly asked for the
> > > feature to be enabled, QEMU enabled it, and suddenly the feature is not
> > > supported by new QEMU?
> > 
> > I incorrectly assumed that nobody would be using the option
> > names, because the options did nothing (ospke and osxsave are
> > runtime CPU state flags exposed via CPUID, and were never
> > configurable from the command-line).
> > 
> > If it broke something, we should restore the option names and
> > declare them as deprecated.
> > 
> > > 
> > > Any ideas on how we should deal with the two features which were removed
> > > from QEMU 3.0 and how to make sure we don't have to discuss this again
> > > when some other feature is removed?
> > 
> > Removing the flags without notice was a mistake.  Next time, we
> > should follow the deprecation policy and communicate the option
> > removal more clearly.
> 
> Fair enough, however once they are declared as deprecated they will
> actually be removed at some point. And we're back in this situation.
> Deprecating or removing command line options or QMP commands is
> different, because libvirt can detect what is (un)supported and use an
> alternative command or option.
> 
> But if a CPU feature is removed (unfortunately it doesn't really matter
> if it was doing something or not), we need to have a plan what to do in
> a situation when the feature is used in domain XML. We can detect the
> feature is not supported, but does it mean the feature was didn't have
> any effect and thus it was removed or are we just talking to a QEMU
> binary which does not support the feature (yet)?

In this specific case, libvirt needs to encode the knowledge that
it was using an option that had zero effects on the resulting
virtual machine.

When QEMU provides an alternative, this is also easy to deal
with: we need to teach libvirt to use the alternative.

Now, if we're going to remove actual features from QEMU without
providing a replacement, this is a more complex discussion.  I
was planning to start a thread about that, because we need to be
able to remove features from QEMU in the future (esp. CPU models
and machine-types) even if existing VMs are using them, and
libvirt and management apps need to deal with that somehow.

-- 
Eduardo