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
Subject: [PATCH 0/4] KVM: x86: More EFER.LMA vs. CR4.PAE fixes
Date: Thu, 22 Oct 2026 15:30:48 -0700 [thread overview]
Message-ID: <20261022223052.646891-1-seanjc@google.com> (raw)
Revert a change I made years ago to allow userspace to stuff EFER before
configuring guest CPUID, as configuring CPUID and feature MSRs before anything
else is now a hard requirement (though I suspect I was just a bit overzealous
at the time). The biggest problem with that change, other than creating what
should be impossible state, is that it also bypassed this check:
if (is_paging(vcpu) &&
(vcpu->arch.efer & EFER_LME) != (efer & EFER_LME))
return 1;
which was kinda sorta intentional? I assume the idea was that userspace could
stuff CR0 vs. EFER in any order. Except that in doing so, userspace could get
impossible state in CR0+CR4+EFER (in the aggregate, not in any one individual
register). KVM doesn't advertise MSR_EFER as an MSR that needs to be
saved/restored, and AFAICT no VMM manually does that, they all just use
KVM_{G,S}ET_SREGS{,2} (which is what we want).
So, hit the "I'm feeling lucky!" button and simply revert the misguided
commit.
Patch 2 is more hardening. Rather than pend a triple fault, which is flawed
because (a) KVM still yanks the vCPU out of L2 without going through a normal
nested VM-Exit and (b) there's a window where KVM can do stuff, e.g. init the
MMU, before the triple fault request is handled, immediately synthesize a #GP.
The only reason I didn't go with a #GP the first time around is that I didn't
want to bleed EFER_SVME information into the common set_efer(), KVM effectively
doesn't allow kvm_x86_call(set_efer)() to inject faults, and the vendor version
is used for many flows, whereas set_efer() is strictly used for WRMSR emulation.
Patch 3 is also more hardening, to try and detect+prevent EFER.LMA from going
stale.
Finally, update the EFER selftest to match the new #GP behavior.
Sean Christopherson (4):
Revert "KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated
writes"
KVM: nSVM: Synthesize #GP instead of SHUTDOWN if L2 attempts to clear
EFER.SVME
KVM: x86: Recompute EFER.LMA instead of inheriting the current value
on EFER writes
KVM: selftests: Update nSVM EFER test to expect #GP when clearing SVME
in L2
arch/x86/kvm/msrs.c | 54 ++++++++-------
arch/x86/kvm/svm/svm.c | 15 ++---
.../selftests/kvm/x86/svm_nested_efer_test.c | 65 +++++++++++--------
3 files changed, 74 insertions(+), 60 deletions(-)
base-commit: 164405e8e9a0378c7e1aff2254625a6553a291f1
--
2.56.0.257.gf7497c7d27-goog
next reply other threads:[~2026-10-22 22:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 22:30 Sean Christopherson [this message]
2026-10-22 22:30 ` [PATCH 1/4] Revert "KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes" Sean Christopherson
2026-10-22 22:30 ` [PATCH 2/4] KVM: nSVM: Synthesize #GP instead of SHUTDOWN if L2 attempts to clear EFER.SVME Sean Christopherson
2026-10-22 22:30 ` [PATCH 3/4] KVM: x86: Recompute EFER.LMA instead of inheriting the current value on EFER writes Sean Christopherson
2026-10-22 22:30 ` [PATCH 4/4] KVM: selftests: Update nSVM EFER test to expect #GP when clearing SVME in L2 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=20261022223052.646891-1-seanjc@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/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®