qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jiri Denemark
Subject: Re: [Qemu-devel] Dropped CPU feature names and backward compatibility
Date: Tue, 18 Sep 2018 15:26:18 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

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)?

Jirka



reply via email to

[Prev in Thread] Current Thread [Next in Thread]