The series was merged in 3a1acf5d47295d22ffdae0982a2fd808b802a7da as a prep to qemu 4.1. But the changes are rather invasive and after a review I think for the SRU we will not add them.
For example the changes around: "model runnability guarantees won't apply to unversioned CPU models anymore" seems non backportable to me. I agree it is the right path going forward to keep the proliferation of CPU models under control and provide something like a "moving head" weakening the runability guarantees that can be regained by fetching the exact versions via alias-of. But none of the old systems management stacks will be able to do so. Yes there is [2] but I'm still scared in an SRU context to add that when it is a valid (more effort but working) option to add model+flags for the time being. And in addition the code for making the models versionable will be another great set of backports with potential backport flaws added. Hence at least for now my decision would be: - make the features available at least to the last LTS (Bionic) which will reach LTS-1 for many (to admit not all) users via Ubuntu cloud archive - do not backport the versioned CPU model changes (too much risk / incompatibilities) - pro: no changes to the higher virt stack needed - pro: less regression risk for the SRUs - pro: the new security features will be available - con: security features must be enabled individually via feature flags @Rafael that should match what you had prepared in your MPs already. I'll create a PPA with your any my changes for general regression tests. @Quaxlan - for the versioned CPUs an all that belongs to that context I'd ask you to file a new bug. I expect that will be in qemu 4.1 (just entered rc0) and a later (yet to be defined) libvirt version. Once all of that has properly landed we can consider if we will pull it back into Eoan (as long as it isn't released and under the SRU policy) OR if we wait for these new features to properly arrive in the next Ubuntu release being 20.04. Once you happen to know which libvirt version will have the appropriate changes to properly tolerate and exploit what was added to qemu via [1] (version and commits if you have both) let us know there. [1]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg627282.html [2]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg628326.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: In Progress Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: In Progress Status in linux source package in Cosmic: Confirmed Status in qemu source package in Cosmic: In Progress Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: In Progress Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: In Progress Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case] * From Original Description: """ 1. Boot up guest using: -cpu Cascadelake-Server [root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio char device redirected to /dev/pts/3 (label serial0) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] 2. To check CPU ID related to features[FEAT_7_0_EDX] ：CPUID_7_0_EDX_ARCH_CAPABILITIES Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be 1. Actual Result: Host's cpuid: 0x00000007 0x00: eax=0x00000000 ebx=0xd39ffffb ecx=0x00000818 edx=0xbc000000 (EDX bit 29=1) Guest's cpuid : 0x00000007 0x00: eax=0x00000000 ebx=0xd19f0fb9 ecx=0x00000818 edx=0x84000000 (EDX bit 29=0) Commit:2bdb76c015df7125783d8394d6339d181cb5bc30 Target Kerned: 5.1 Target Release: 19.10 """ [Regression Potential] * Most changes are related to CPU type definitions and its supported features. They are all based in upstream changes but, for obvious reasons, backporting and/or cherry-picking those could bring issues. Biggest concern is breaking something that currently works. Right now, the parts being changed that could affect other CPU types would be related to a small refactoring of how the features are organized, and that would be seen right away when trying to start a new VM after the package is installed. * Other tests, related to the features being backported, are being done by our KVM regression tests, including migration combinations, to reduce chances that a regression is introduced. [Other Info] * N/A To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1828495/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
