** 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 + * 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. + * 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 + * 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 + * 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 + * 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. + * 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. + * 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-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
