Unable to use Skylake capability on Cascadelake server
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Christian Ehrhardt | ||
Groovy |
Fix Released
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* To avoid bugs with newer Hardware and to allow users/admins to control
the KVM guests correctly we usually try to backport major CPU-
detect/control features back to at least the last LTS (currently Focal)
In SRU Terms this is under the second entry in
https:/
* In this particular case it is about skylake and cascade lake CPUs.
Which turned out to differ on so few details that not only the new type
is needed to be known, but also the feature to parse and consider the
CPU stepping needs to be added.
Only then can libvirt properly differ those types.
[Test Plan]
* First of all we'll (and have in advance) run general regression tests
* Second and for this case in particular we expect libvirt to recognize
skylake/cascade lake chips better. So with access to those chips you'd
before the fix see both recognized as the same (wrong) and after the
fix as different cpu types.
$ virsh domcapabilities
^^ look for the host-model section
Comment #14 in this bug has sample output data
* With the fixes you can define a guest with a CascadeLake based
named type
[Where problems could occur]
* There are two areas to look at
a) compat behavior on old systems - e.g. if you used to say "host-
model" on two different chips that are related to these fixes you
might have ended up with the same model. But now the newer chip
would get the newer better definition.
That is correct and good - but for others might appear as a change
in behavior they didn't expect.
b) Migrations between systems - in fact this is an area we fix for some
combinations. But if e.g. (a) above applies then you can't migrate
from the new to the old chip if the newer one has features enable
that don't exist on the old chip.
Again this is what we want (better than silently failing) but for
every scenario fixed there might be a combination of chips and use
cases which will at first stumble over the new behavior.
Since we only change the named types, but not qemu implementation
those issues should not be much of a problem as you can do:
"type X+Feat" == "type Y", but still those are the areas to look at.
[Other Info]
* The change itself that is the fix/ability to differentiate those two
chips is part of a larger series that mostly does rewrite manual
alloc/free code into glib based auto-free. These efforts have been
started before the version in Focal so everything is in place.
Backporting the fix without those was evaluated but considered more
risky of a regression than also pulling (the then mostly cleanly
applying) code rewrites - as they are not much functional change, but
more new style to do the same.
* This is not the first time new chips need quite some effort to be able
to be handled - for example bug 1828495 was similar
---
Hi.
We have OpenStack cluster (ubuntu 20.04 ussuri) with old Skylake (Skylake-
cpu_mode = custom
cpu_models = Skylake-Server-IBRS
But got an error:
CPU doesn't have compatibility
Similar issue for Red Hat: https:/
Related branches
- Robie Basak: Approve (sru)
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 7404 lines (+7112/-0)48 files modifieddebian/changelog (+12/-0)
debian/patches/series (+46/-0)
debian/patches/ubuntu/lp-1921754-cpumap-Add-support-for-ibrs-CPU-feature.patch (+59/-0)
debian/patches/ubuntu/lp-1921880-cpu_map-Add-EPYC-Milan-x86-CPU-model.patch (+129/-0)
debian/patches/ubuntu/lp-1921880-cpu_map-Add-support-for-fsrm-CPU-feature.patch (+73/-0)
debian/patches/ubuntu/lp-1921880-cpu_map-Fix-spelling-of-svme-addr-chk-feature.patch (+51/-0)
debian/patches/ubuntu/lp-1921880-cpu_map-Install-x86_EPYC-Milan.xml.patch (+39/-0)
debian/patches/ubuntu/lp-1921880-cpumap-Add-support-for-svme-addr-check-CPU-feature.patch (+33/-0)
debian/patches/ubuntu/lp-1922907-cleanup-test-data.patch (+28/-0)
debian/patches/ubuntu/lp-1922907-cpu_map-Distinguish-Cascadelake-Server-from-Skylake-.patch (+151/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Add-support-for-stepping-part-of-CPU-signatu.patch (+180/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Don-t-check-return-value-of-x86ModelCopy.patch (+71/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Drop-noTSX-hint-for-incompatible-CPUs.patch (+99/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Introduce-virCPUx86SignatureFromCPUID.patch (+68/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Introduce-virCPUx86SignaturesFree.patch (+61/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Move-and-rename-x86FormatSignatures.patch (+85/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Move-and-rename-x86ModelCopySignatures.patch (+97/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Move-and-rename-x86ModelHasSignature.patch (+98/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Replace-32b-signatures-in-virCPUx86Model-wit.patch (+317/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86Baseline.patch (+157/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86CheckFeature.patch (+51/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86Compare.patch (+66/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86CopyMigratable.patch (+51/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86DataParse.patch (+84/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86ExpandFeatures.patch (+83/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86GetHost.patch (+68/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86LoadMap.patch (+48/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86Translate.patch (+82/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86Update.patch (+70/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-virCPUx86UpdateLive.patch (+101/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86Compute.patch (+178/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86DataToCPU.patch (+68/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86Decode.patch (+96/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86Encode.patch (+138/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86EncodePolicy.patch (+43/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86FeatureParse.patch (+112/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86ModelFromCPU.patch (+71/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86ModelParse.patch (+77/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86UpdateHostModel.patch (+68/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-g_auto-in-x86VendorParse.patch (+73/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-glib-allocation-for-virCPU-x86-Data.patch (+142/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-glib-allocation-for-virCPUx86Feature.patch (+71/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-glib-allocation-for-virCPUx86Map.patch (+66/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-glib-allocation-for-virCPUx86Model.patch (+100/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-glib-allocation-for-virCPUx86Vendor.patch (+50/-0)
debian/patches/ubuntu/lp-1922907-cpu_x86-Use-glib-allocation-in-virCPUx86GetModels.patch (+49/-0)
debian/patches/ubuntu/lp-1922907-cputest-Add-data-for-Intel-R-Xeon-R-Gold-6130-CPU.patch (+1460/-0)
debian/patches/ubuntu/lp-1922907-cputest-Add-data-for-Intel-R-Xeon-R-Platinum-9242-CP.patch (+1692/-0)
Upstream fixes https:/ /listman. redhat. com/archives/ libvir- list/2020- March/msg01197. html