From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Sashiko Bot <sashiko-bot@kernel.org>
Subject: [PATCH v2 4/6] KVM: x86: Recompute EFER.LMA instead of inheriting the current value on EFER writes
Date: Tue, 27 Oct 2026 15:49:12 -0700 [thread overview]
Message-ID: <20261027224914.1574319-5-seanjc@google.com> (raw)
In-Reply-To: <20261027224914.1574319-1-seanjc@google.com>
Recompute EFER.LMA on bare writes to EFER (via WRMSR or KVM_SET_MSRS)
instead of carrying forward the current EFER.LMA. While it _should_ be
impossible for EFER.LMA to end up in an inconsistent state on such a write,
KVM has had a rash of exactly those bugs, mostly because SVM is quite lax
when it comes to consistenty checks, which in turn bleeds into KVM's nested
SVM implementation. Retaining the existing EFER is also rather confusing,
as understanding why keeping EFER.LMA is correct requires a lot of a priori
knowledge of both x86-64 and KVM.
Keep the core concept of the existing logic as a sanity check: WARN if the
computed EFER.LMA would be toggled, because as described above, that
_should_ be impossible. Don't return an error if the sanity check fails,
e.g. don't inject a #GP, as setting EFER.LMA based on the current state
provides architecturally consistency.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/msrs.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
index c3cb1575fe66..c55402970a34 100644
--- a/arch/x86/kvm/msrs.c
+++ b/arch/x86/kvm/msrs.c
@@ -638,8 +638,17 @@ static int set_efer(struct kvm_vcpu *vcpu, u64 efer)
(vcpu->arch.efer & EFER_SVME) && !(efer & EFER_SVME))
return 1;
- efer &= ~EFER_LMA;
- efer |= vcpu->arch.efer & EFER_LMA;
+ if ((efer & EFER_LME) && is_paging(vcpu) && is_pae(vcpu))
+ efer |= EFER_LMA;
+ else
+ efer &= ~EFER_LMA;
+
+ /*
+ * Toggling EFER.LMA on a bare write to EFER should be impossible, as
+ * it means KVM allowed architecturally invalid state at some point in
+ * the past, i.e. allowed EFER.LMA=1 && (!CR0.PG || !CR4.PAE).
+ */
+ WARN_ON_ONCE((efer & EFER_LMA) != (vcpu->arch.efer & EFER_LMA));
r = kvm_x86_call(set_efer)(vcpu, efer);
if (r) {
--
2.56.0.307.g5fe7bd680c-goog
next prev parent reply other threads:[~2026-10-27 22:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 22:49 [PATCH v2 0/6] KVM: x86: More EFER.LMA vs. CR4.PAE fixes Sean Christopherson
2026-10-27 22:49 ` [PATCH v2 1/6] Revert "KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes" Sean Christopherson
2026-10-27 22:49 ` [PATCH v2 2/6] KVM: x86: Reject clearing EFER.SVME via KVM_SYNC_X86_SREGS if L2 is active Sean Christopherson
2026-10-28 0:08 ` Yosry Ahmed
2026-10-27 22:49 ` [PATCH v2 3/6] KVM: nSVM: Synthesize #GP instead of SHUTDOWN if L2 attempts to clear EFER.SVME Sean Christopherson
2026-10-27 22:49 ` Sean Christopherson [this message]
2026-10-27 22:49 ` [PATCH v2 5/6] KVM: selftests: Update nSVM EFER test to expect #GP when clearing SVME in L2 Sean Christopherson
2026-10-27 22:49 ` [PATCH v2 6/6] KVM: selftests: Expect failure when trying to set EFER that violates vCPU model Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261027224914.1574319-5-seanjc@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sashiko-bot@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®