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