From: Jim Mattson <jmattson@google.com>
To: seanjc@google.com, pbonzini@redhat.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
nikunj@amd.com, yosry@kernel.org,
Jim Mattson <jmattson@google.com>
Subject: [PATCH v2 0/4] KVM: x86: Honor EFER_LMSLE_MBZ
Date: Wed, 23 Sep 2026 17:25:41 -0700 [thread overview]
Message-ID: <cover.1790208413.git.jmattson@google.com> (raw)
v1 was a single patch that made KVM reject EFER.LMSLE=1 when the guest's
CPUID enumerates EFER_LMSLE_MBZ, CPUID.80000008H:EBX[bit 20]. Review turned
up two more things: KVM's *own* enumeration of the defeature is wrong today,
and the new guest-CPUID check needs an escape hatch so that userspace can
still set the bit on a host where KVM doesn't advertise it.
The motivation, as discussed in the v1 thread, is to be able to defeature a
virtual Rome, i.e. to set EFER_LMSLE_MBZ even though Rome itself supports
long mode segment limits, so that the vCPU can be hosted on Milan and later.
The opposite direction isn't interesting; in general you can't host
generation N+1 on generation N.
Patch 1 fixes KVM's enumeration of the defeature. Today KVM passes
hardware's EFER_LMSLE_MBZ through as-is, i.e. leaves the bit clear on Intel
and on AMD with kvm_amd.nested=0, which tells userspace that long mode
segment limits *are* available. But KVM allows EFER.LMSLE if and only if
nested SVM is supported, so on exactly those hosts KVM then rejects
WRMSR(EFER) with EFER.LMSLE=1. Set EFER_LMSLE_MBZ whenever KVM refuses
EFER.LMSLE; the bit means precisely "EFER.LMSLE must be zero". Note, this
is guest visible for userspace that reflects KVM's supported CPUID into the
guest.
Patch 2 is v1, plus the partial-emulation hunk Sean suggested so that
userspace can set EFER_LMSLE_MBZ on a host that does support LMSLE. It
also masks EFER_LMSLE out of the value consumed by efer_trap(). Under
SEV-ES, EFER writes are *trapped*, not intercepted. Rejecting the write
would inject a #GP *and* leave EFER.LMSLE set, which is strictly worse than
honoring a write that hardware allowed.
Patches 3 and 4 rename svm_nested_clear_efer_svme to svm_nested_efer_test
and add coverage for the defeature.
Tested on Rome, which supports LMSLE and so actually exercises the emulated
path, and on Skylake.
v1: https://lore.kernel.org/all/20260918154530.4129698-1-jmattson@google.com
Jim Mattson (4):
KVM: x86: Advertise EFER_LMSLE_MBZ when KVM disallows EFER.LMSLE
KVM: x86: Honor the guest's EFER_LMSLE_MBZ
KVM: selftests: Rename svm_nested_clear_efer_svme to
svm_nested_efer_test
KVM: selftests: Add coverage for the EFER_LMSLE_MBZ defeature
Documentation/virt/kvm/api.rst | 25 ++
arch/x86/kvm/cpuid.c | 20 ++
arch/x86/kvm/msrs.c | 12 +-
arch/x86/kvm/svm/svm.c | 21 +-
arch/x86/kvm/vmx/vmx.c | 7 +
arch/x86/kvm/x86.c | 9 +-
tools/testing/selftests/kvm/Makefile.kvm | 2 +-
.../selftests/kvm/include/x86/processor.h | 1 +
.../kvm/x86/svm_nested_clear_efer_svme.c | 50 ----
.../selftests/kvm/x86/svm_nested_efer_test.c | 273 ++++++++++++++++++
10 files changed, 366 insertions(+), 54 deletions(-)
delete mode 100644 tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c
create mode 100644 tools/testing/selftests/kvm/x86/svm_nested_efer_test.c
base-commit: f0100363d8c374bd8e9ea7c9ba02744f0b802ca4
--
2.56.0.rc1.315.gc6ed9934b7-goog
next reply other threads:[~2026-09-24 0:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 0:25 Jim Mattson [this message]
2026-09-24 0:25 ` [PATCH v2 1/4] KVM: x86: Advertise EFER_LMSLE_MBZ when KVM disallows EFER.LMSLE Jim Mattson
2026-09-24 0:25 ` [PATCH v2 2/4] KVM: x86: Honor the guest's EFER_LMSLE_MBZ Jim Mattson
2026-09-24 0:25 ` [PATCH v2 3/4] KVM: selftests: Rename svm_nested_clear_efer_svme to svm_nested_efer_test Jim Mattson
2026-09-24 0:25 ` [PATCH v2 4/4] KVM: selftests: Add coverage for the EFER_LMSLE_MBZ defeature Jim Mattson
2026-09-29 0:41 ` 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=cover.1790208413.git.jmattson@google.com \
--to=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=yosry@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.