** Description changed: + [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://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases + + * 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. + + + --- + Hi. We have OpenStack cluster (ubuntu 20.04 ussuri) with old Skylake (Skylake-Server-IBRS) Intel CPU, and try to extend cluster with new Cascadelake (Cascadelake-Server-noTSX) servers with backward compatibility mode in nova.conf cpu_mode = custom cpu_models = Skylake-Server-IBRS But got an error: CPU doesn't have compatibility Similar issue for Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1761678
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1922907 Title: Unable to use Skylake capability on Cascadelake server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1922907/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
