From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v3 1/7] Revert "KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes"
Date: Fri, 30 Oct 2026 21:39:38 +0000 [thread overview]
Message-ID: <sashiko-outbox-191540@kernel.org> (raw)
In-Reply-To: <20261030212721.2606393-2-seanjc@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] KVM: x86: outdated EFER_LMSLE_MBZ api.rst doc and __kvm_valid_efer() comment
--
commit e9f88969b96c2ee54c7d5d0af947bad813dd2acc
Author: Sean Christopherson <seanjc@google.com>
Revert "KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes"
This commit reverts commit 11988499e62b ("KVM: x86: Skip EFER vs. guest CPUID
checks for host-initiated writes") so that host-initiated writes to MSR_EFER
via set_efer() are once again validated against guest CPUID capabilities and
CR0.PG vs. EFER.LME constraints.
> diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
> index e91650af44c20..2df42276fd826 100644
> --- a/arch/x86/kvm/msrs.c
> +++ b/arch/x86/kvm/msrs.c
> @@ -580,8 +580,11 @@ static int do_get_feature_msr(struct kvm_vcpu *vcpu, unsigned index, u64 *data)
> kvm_get_feature_msr);
> }
>
> -static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
> +bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
> {
> + if (efer & ~kvm_caps.supported_efer_bits)
> + return false;
> +
> if (efer & EFER_AUTOIBRS && !guest_cpu_cap_has(vcpu, X86_FEATURE_AUTOIBRS))
> return false;
>
> @@ -610,33 +613,18 @@ static bool __kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
>
> return true;
> }
> -
> -bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer)
> -{
> - if (efer & ~kvm_caps.supported_efer_bits)
> - return false;
> -
> - return __kvm_valid_efer(vcpu, efer);
> -}
> EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_valid_efer);
>
> -static int set_efer(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> +static int set_efer(struct kvm_vcpu *vcpu, u64 efer)
> {
> u64 old_efer = vcpu->arch.efer;
> - u64 efer = msr_info->data;
> int r;
>
> - if (efer & ~kvm_caps.supported_efer_bits)
> + if (!kvm_valid_efer(vcpu, efer))
> return 1;
>
> - if (!msr_info->host_initiated) {
> - if (!__kvm_valid_efer(vcpu, efer))
> - return 1;
> -
> - if (is_paging(vcpu) &&
> - (vcpu->arch.efer & EFER_LME) != (efer & EFER_LME))
> - return 1;
> - }
> + if (is_paging(vcpu) && (vcpu->arch.efer & EFER_LME) != (efer & EFER_LME))
> + return 1;
[Severity: Low]
As reported by Sashiko on v1 [1], now that set_efer() in arch/x86/kvm/msrs.c
unconditionally calls kvm_valid_efer() (including the
X86_FEATURE_EFER_LMSLE_MBZ check) even on host-initiated MSR_EFER writes and
folds __kvm_valid_efer() into kvm_valid_efer(), should
Documentation/virt/kvm/api.rst and the comment in efer_trap() in
arch/x86/kvm/svm/svm.c also be updated?
Specifically, commit 7358d13e1f19 ("KVM: x86: Honor the guest's
EFER_LMSLE_MBZ") added the following note under "Long mode segment limits" in
Documentation/virt/kvm/api.rst:
Note, ``KVM_SET_MSRS`` is exempt from the check, as host-initiated MSR writes
skip guest CPUID checks so that userspace can set MSRs before it sets guest
CPUID. ``KVM_SET_SREGS`` and nested VMRUN are not exempt.
While the selftest failure in test_host_initiated_lmsle() in
tools/testing/selftests/kvm/x86/svm_nested_efer_test.c is addressed later in
this series by commit "KVM: selftests: Expect failure when trying to set EFER
that violates vCPU model", Documentation/virt/kvm/api.rst still states that
KVM_SET_MSRS is exempt from the check.
Additionally, efer_trap() in arch/x86/kvm/svm/svm.c still references the
removed __kvm_valid_efer() helper in its comment:
/*
* Clear the EFER_SVME bit from EFER. The SVM code always sets this
* bit in svm_set_efer(), but __kvm_valid_efer() checks it against
* whether the guest has X86_FEATURE_SVM - this avoids a failure if
* the guest doesn't have X86_FEATURE_SVM.
*/
[1] https://lore.kernel.org/r/20261022223052.646891-2-seanjc@google.com
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261030212721.2606393-1-seanjc@google.com?part=1
next prev parent reply other threads:[~2026-10-30 21:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 21:27 [PATCH v3 0/7] KVM: x86: More EFER.LMA vs. CR4.PAE fixes Sean Christopherson
2026-10-30 21:27 ` [PATCH v3 1/7] Revert "KVM: x86: Skip EFER vs. guest CPUID checks for host-initiated writes" Sean Christopherson
2026-10-30 21:39 ` sashiko-bot [this message]
2026-10-30 21:27 ` [PATCH v3 2/7] KVM: x86: Treat EFER.LMA, not EFER.LMA, as an EFER MMU role bit Sean Christopherson
2026-10-30 21:27 ` [PATCH v3 3/7] KVM: x86: Reject clearing EFER.SVME via KVM_SYNC_X86_SREGS if L2 is active Sean Christopherson
2026-10-30 21:27 ` [PATCH v3 4/7] KVM: nSVM: Synthesize #GP instead of SHUTDOWN if L2 attempts to clear EFER.SVME Sean Christopherson
2026-10-30 21:27 ` [PATCH v3 5/7] KVM: x86: Recompute EFER.LMA instead of inheriting the current value on EFER writes Sean Christopherson
2026-10-30 22:24 ` sashiko-bot
2026-10-30 21:27 ` [PATCH v3 6/7] KVM: selftests: Update nSVM EFER test to expect #GP when clearing SVME in L2 Sean Christopherson
2026-10-30 21:27 ` [PATCH v3 7/7] 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=sashiko-outbox-191540@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seanjc@google.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 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.