[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220920205922.1564814-1-jmattson@google.com>
Date: Tue, 20 Sep 2022 13:59:19 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H . Peter Anvin" <hpa@...or.com>,
Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc: Jim Mattson <jmattson@...gle.com>
Subject: [PATCH v2 0/3] KVM: EFER.LMSLE cleanup
KVM has never properly virtualized EFER.LMSLE. However, when the
"nested" module parameter is set, KVM lets the guest set EFER.LMSLE.
Ostensibly, this is so that SLES11 Xen 4.0 will boot as a nested
hypervisor.
KVM passes EFER.LMSLE to the hardware through the VMCB, so
the setting works most of the time, but the KVM instruction emulator
completely ignores the bit, so incorrect guest behavior is almost
certainly assured.
With Zen3, AMD has abandoned EFER.LMSLE. KVM still allows it, though, as
long as "nested" is set. However, since the hardware doesn't support it,
the next VMRUN after the emulated WRMSR will fail with "invalid VMCB."
To clean things up, revert the hack that allowed a KVM guest to set
EFER.LMSLE, and enumerate CPUID.80000008H:EDX.EferLmsleUnsupported[bit
20] in KVM_GET_SUPPORTED_CPUID on SVM hosts.
Jim Mattson (3):
Revert "KVM: SVM: Allow EFER.LMSLE to be set with nested svm"
x86/cpufeatures: Introduce X86_FEATURE_NO_LMSLE
KVM: SVM: Unconditionally enumerate EferLmsleUnsupported
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 2 --
arch/x86/kvm/svm/svm.c | 3 ++-
3 files changed, 3 insertions(+), 3 deletions(-)
v1 -> v2: Make no attempt to preserve existing behavior [Sean, Borislav]
--
2.37.3.968.ga6b4b080e4-goog
Powered by blists - more mailing lists