Hi Rafael, thanks for giving it try. We knew it might be complex when we first saw the changes. And I consider it wise to - at some point - step back and realize this won't be SRUable. I'll summarize what we know about the libvirt portion of this:
## SRUability ## The changes are rather complex, and will most likely not be SRUable. Even if prepared for an upload they are massive and with a huge risk of regressing other use cases which we'd generally want to avoid. I haven't done/tried the porting myself, but your doc reads fine and it grows and grows to become borderline to considering a major version bump which isn't an option here. ## How strict is the need for these ## 1. I know - after all I was a performance engineer for a decade - that speed is important. And those extra mitigation flags are all about improved mitigations for speed. But TBH, that also makes them not strictly required for the function. 2. After all the CPU features we are talking about here are still rare. You only get them at the very latest CPUs. So the chances that an existing server Farm needs those changes desperately are low. This will mostly be for consideration of new setups, and they can/should use the new code of the new release. ## Availability ## 1. The majority of this code is upstream in 5.5 and we backported it to 5.4 for Eoan - so there is a Ubuntu release that can use this code already. 2. LTS users in Bionic (way more than Eoan I'd think) can get also access to it via the Ubuntu Cloud Archive [1]. And that is not only true for the now released 5.4, but when we release Ubuntu 20.04 there will be a new UCA along it containing all the final upstream fixes (not only our backports) - and that will be supported for an even longer time. ## Verdict ## I second your call on these patches after reading your summary, lets call the related libvirt backports Won't Fix for now. ## TODOs ## @Rafael - do you still have a TODO on the kernel side as there are tasks open and assigned? @Rafael - while I generally dislike raw qemu-cmdline in XML documenting an example as you suggested might be useful, will you come up with a draft for it? @Rafael/Christian - lets also talk with the Team about it to get everyone on the same page. [1]: https://wiki.ubuntu.com/OpenStack/CloudArchive ** Changed in: libvirt (Ubuntu Disco) Status: Opinion => Won't Fix -- 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 libvirt package in Ubuntu: Fix Released Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: Fix Released Status in libvirt source package in Bionic: Won't Fix Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Fix Released Status in libvirt source package in Disco: Won't Fix Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Fix Released Status in libvirt source package in Eoan: Fix Released Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: Fix Released 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
