Commit Graph

4 Commits

Author SHA1 Message Date
Tim Wiederhake
fa54595178 cpu_map: Drop 'mpx' from x86 cpu models
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>
2024-05-02 19:56:45 +02:00
Tim Wiederhake
986be35f2e cpu_map: Sort cpu features
Some feature words were not sorted correctly.

Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2024-02-20 17:29:27 +01:00
Jiri Denemark
48341b025a cpu_x86: Penalize disabled features when computing CPU model
For finding the best matching CPU model for a given set of features
while we don't know the CPU signature (i.e., when computing a baseline
CPU model) we've been using a "shortest list of features" heuristics.
This works well if new CPU models are supersets of older models, but
that's not always the case. As a result it may actually select a new CPU
model as a baseline while removing some features from it to make it
compatible with older models. This is in general worse than using an old
CPU model with a bunch of added features as a guest OS or apps may crash
when using features that were disabled.

On the other hand we don't want to end up with a very old model which
would guarantee no disabled features as it could stop a guest OS or apps
from using some features provided by the CPU because they would not
expect them on such an old CPU.

This patch changes the heuristics to something in between. Enabled and
disabled features are counted separately so that a CPU model requiring
some features to be disabled looks worse than a model with fewer
disabled features even if its complete list of features is longer. The
penalty given for each additional disabled feature gets bigger to make
longer list of disabled features look even worse.

https://bugzilla.redhat.com/show_bug.cgi?id=1851227

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-05-06 17:33:47 +02:00
Jiri Denemark
63d633b9a4 cputest: Add some real world baseline tests
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-05-06 17:33:46 +02:00