[Top][All Lists]

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

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

From: Eduardo Habkost
Subject: Re: [Qemu-devel] Dropped CPU feature names and backward compatibility
Date: Tue, 18 Sep 2018 10:14:45 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote:
> Hi,
> I noticed two x86_64 CPU features were removed from QEMU in 3.0.0:
>     - ospke removed by 9ccb9784b57
>     - osxsave removed by f1a23522b03
> More precisely, the CPUID bits are still there (and for example Icelake
> CPU model has the ospke bit set), but the string representations were
> removed. Thus QEMU will no longer report there features and it will not
> accept it on the command line anymore. Which is a regression which we
> need to deal with somehow.
> With QEMU < 3.0:
> $ qemu-system-x86_64 -machine pc,accel=kvm -cpu Skylake-Client,osxsave=on
> qemu-system-x86_64: warning: host doesn't support requested feature: 
> CPUID.01H:ECX.osxsave [bit 27]
> $ qemu-system-x86_64 -machine pc,accel=kvm -cpu Skylake-Client,osxsave=off
> While new QEMU 3.0 complains:
> $ qemu-system-x86_64 -machine pc,accel=kvm -cpu Skylake-Client,osxsave=off
> qemu-system-x86_64: can't apply global Skylake-Client-x86_64-cpu.osxsave=off: 
> Property '.osxsave' not found
> I accept the argument that setting those two features was never actually
> allowed, but that doesn't mean they should be just removed. It's quite
> likely that somebody has a libvirt domain defined with either of the two
> features explicitly enabled or disabled. It's likely because both
> virt-manager and virt-install can be told to copy host CPU configuration
> to the domain XML. This is normally not a problem, because it will just
> ask QEMU to enable all features available on the host and QEMU will
> enable only some of them. To make sure libvirt can provide stable guest
> CPU ABI after migration or save/restore, we ask QEMU what CPU features
> were enabled and disabled and update the active definition. This means
> that an explicit <feature name='osxsave' policy='require'/> will likely
> turn into <feature name='osxsave' policy='disable'/>. In other words,
> the -cpu option will have an explicit osxsave=off parameter during
> migration. As a result of this such domain would happily migrate to QEMU
> < 3.0, but fail to migrate to QEMU 3.0.
> 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.


reply via email to

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