@@ -1595,25 +1595,8 @@ static u64 kvm_get_arch_capabilities(void)
data |= ARCH_CAP_SSB_NO;
if (!boot_cpu_has_bug(X86_BUG_MDS))
data |= ARCH_CAP_MDS_NO;
-
- if (!boot_cpu_has(X86_FEATURE_RTM)) {
- /*
- * If RTM=0 because the kernel has disabled TSX, the host might
- * have TAA_NO or TSX_CTRL. Clear TAA_NO (the guest sees RTM=0
- * and therefore knows that there cannot be TAA) but keep
- * TSX_CTRL: some buggy userspaces leave it set on tsx=on hosts,
- * and we want to allow migrating those guests to tsx=off hosts.
- */
- data &= ~ARCH_CAP_TAA_NO;
- } else if (!boot_cpu_has_bug(X86_BUG_TAA)) {
+ if (!boot_cpu_has_bug(X86_BUG_TAA))
data |= ARCH_CAP_TAA_NO;
- } else {
- /*
- * Nothing to do here; we emulate TSX_CTRL if present on the
- * host so the guest can choose between disabling TSX or
- * using VERW to clear CPU buffers.
- */
- }
return data;
}
On CPUs that are not affected by TSX Async Abort (TAA), some host/guest configurations can result in guest unnecessarily report TAA vulnerability and deploy its mitigation. Particularly when a host exports MSR_IA32_TSX_CTRL to guests and hides TAA_NO. Due to MSR_IA32_TSX_CTRL exported by commit 7131636e7ea5 ("KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off"), a guest with CPUID.RTM=0 and "tsx=on" cmdline parameter will try to enable TSX feature (using the exported MSR). Although TSX won't actually be enabled in the hardware, but the guest would think that it is. Such a guest would then set its X86_FEATURE_RTM. Also, KVM hides MSR IA32_ARCH_CAPABILITIES[TAA_NO] bit from guests when TSX is disabled on host. TAA mitigation selection in guest then sees X86_FEATURE_RTM=1 and TAA_NO=0, and deploys "Clear CPU buffers" mitigation. Export TAA_NO to guests when host is not affected by TAA to ensure that guest doesn't deploy TAA mitigation unnecessarily. Fixes: c11f83e0626b ("KVM: vmx: implement MSR_IA32_TSX_CTRL disable RTM functionality") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215969 Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> --- I am not sure if exporting TAA_NO would affect migration pools and if this is a sane thing to do. Any feedback on same is highly appreciated. arch/x86/kvm/x86.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56