The mpx feature was removed from the corresponding qemu cpu models.
With mpx in the libvirt cpu models, libvirt believes the feature
to be implicitly enabled when creating qemu VMs, while in fact it is
disabled.
This became an issue when commit 94eacd5a5f introduced new vmx-*
features, of which some are dependent on mpx (see "feature_dependencies"
table in qemu target/i386/cpu.c), e.g. vmx-exit-clear-bndcfgs and
vmx-entry-load-bndcfgs. These features cannot be enabled by qemu
without also mpx being enabled, leading to the error message
error: Failed to create domain from testdomain.xml
error: operation failed: guest CPU doesn't match
specification: missing features: mpx,vmx-exit-clear-bndcfgs,
vmx-entry-load-bndcfgs
when trying to create a VM with a "host-model" cpu on a host that
does support mpx and the mentioned vmx-* features:
<domain>
...
<cpu mode='host-model' check='full' />
...
</domain>
Resolve the issue by removing mpx from libvirt's cpu models as well.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Internally we already collect x86 host family + model + stepping
numeric values. This exposed them in capabilities CPU output.
Example:
$ sudo virsh capabilities | grep -A1 -B1 signature
<microcode version='240'/>
<signature family='6' model='94' stepping='3'/>
<counter name='tsc' frequency='3408010000' scaling='no'/>
Users need to know these values to calculate an expected.
SEV-ES/SEV-SNP launch measurement.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
QEMU commits:
e37a5c7fa4 (v2.12.0)
i386: Add Intel Processor Trace feature support
c2f193b538 (v2.7.0)
target-i386: Add support for UMIP and RDPID CPUID bits
aff9e6e46a (v2.12.0)
x86/cpu: Enable new SSE/AVX/AVX512 cpu features
f77543772d (v2.9.0)
x86: add AVX512_VPOPCNTDQ features
5131dc433d (v3.1.0)
i386: Add CPUID bit for PCONFIG
59a80a19ca (v3.1.0)
i386: Add CPUID bit for WBNOINVD
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
While "x86" is a CPU sub driver name, it is not a recognized name of any
architecture known to libvirt. Let's use "x86_64" prefix which can be
used with virArch APIs.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>