Alright. I had in mind that (for bionic/cosmic) but we definitely have to mention what you said (for started guests). About the migration, will cause the issue and report back after cosmic/disco backport.
About needed CPU features. I could get the following... these are the needed cpuflags to have a good mitigation status (and opt out from some heavy workarounds/mitigations inside guest): arch_capabilities=on ssbd=on md-clear=on, wbnoinvd=off bpb=off virt-ssbd=off rdctl-no=yes ibrs-all=yes rsba=yes skip-l1dfl-vmentry=yes ssb-no=yes As we've discussed, I backported EOAN's libvirt 5.4.0-0ubuntu2 to Bionic and checked support... This is the difference when starting CPU as passthrough and CPU as CascadeLake: $ diff -y one two | grep -E "(>|<)" arch_capabilities < arch_perfmon < ept < flexpriority < ibrs_enhanced < md_clear < > pti ss < tpr_shadow < tsc_adjust < umip < vmx < vnmi < vpid < xsaves < xtopology < As you can see we have to enable the CPU features in order to fully inform guest about HW mitigations and such. Going a bit deeper: INTEL: arch-capabilities invpcid <cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>Cascadelake-Server</model> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='invpcid'/> </cpu> AMD ONLY: wbnoinvd ibpb virt-ssbd saw support in libvirt XML files. COULD NOT FIND specific support for the following CPU features: ssbd md-clear bpb ibrs-all rdctl-no rsba skip-l1dfl-vmentry I guess that we will have to backport this support in libvirt, in order to allow QEMU to pick specific CPU mitigation flags. ---- This is the difference from executing QEMU with passthrough versus specifying the Cascadelake Server WITHOUT picking up specific flags (as they are unsupported): ---- HOST has MD_CLEAR, CPU type not: * VERW instruction is available: YES (MD_CLEAR feature bit) HOST has arch_capabilities, CPU type not: * CPU indicates ARCH_CAPABILITIES MSR availability: YES * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: YES * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): YES * CPU/Hypervisor indicates L1D flushing is not necessary on this system: YES HOST reports not being vulnerable to: * Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): NO * Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): NO * Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): NO ---- Passing the flags (ibrs_enhanced): CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigated according to the /sys interface: YES (Mitigation: Enhanced IBRS, IBPB: conditional, RSB filling) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: YES * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES * Kernel supports RSB filling: YES > STATUS: NOT VULNERABLE (IBRS + IBPB are mitigating the vulnerability) Not passing the flags (ibrs_enhanced): CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: YES (for firmware code only) * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Kernel supports RSB filling: YES > STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the > vulnerability) ---- Passing the flags (from arch_capabilities MSR (INVPCID)): CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load' * Mitigated according to the /sys interface: YES (Not affected) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: NO * Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced) * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not > vulnerable) CVE-2018-3640 aka 'Variant 3a, rogue system register read' * CPU microcode mitigates the vulnerability: YES > STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability) Not passing the flags: CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load' * Mitigated according to the /sys interface: YES (Mitigation: PTI) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced) * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) CVE-2018-3640 aka 'Variant 3a, rogue system register read' * CPU microcode mitigates the vulnerability: YES > STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability) ---- Passing the flags (from arch_capabilities MSR): CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault' * CPU microcode mitigates the vulnerability: N/A > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not > vulnerable) Not passing the flags: CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault' * Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion) * Kernel supports PTE inversion: YES (found in kernel image) * PTE inversion enabled and active: YES > STATUS: NOT VULNERABLE (Mitigation: PTE Inversion) ---- Passing the flags (from arch_capabilities MSR): CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' * Information from the /sys interface: Not affected * This system is a host running a hypervisor: NO * Mitigation 1 (KVM) * EPT is disabled: NO * Mitigation 2 * L1D flush is supported by kernel: YES (found flush_l1d in kernel image) * L1D flush enabled: NO * Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower) * Hyper-Threading (SMT) is enabled: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not > vulnerable) Not passing the flags: CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' * Information from the /sys interface: Mitigation: PTE Inversion * This system is a host running a hypervisor: NO * Mitigation 1 (KVM) * EPT is disabled: N/A (the kvm_intel module is not loaded) * Mitigation 2 * L1D flush is supported by kernel: YES (found flush_l1d in kernel image) * L1D flush enabled: UNKNOWN (unrecognized mode) * Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower) * Hyper-Threading (SMT) is enabled: NO > STATUS: NOT VULNERABLE (this system is not running a hypervisor) -- 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: Confirmed Status in qemu package in Ubuntu: Confirmed Status in linux source package in Bionic: New Status in qemu source package in Bionic: Confirmed Status in linux source package in Cosmic: New Status in qemu source package in Cosmic: Confirmed Status in linux source package in Disco: New Status in qemu source package in Disco: Confirmed Status in linux source package in Eoan: Confirmed Status in qemu source package in Eoan: Confirmed 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