Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 4/4] KVM: selftests: Update nSVM EFER test to expect #GP when clearing SVME in L2
Date: Thu, 22 Oct 2026 22:51:12 +0000	[thread overview]
Message-ID: <sashiko-outbox-182135@kernel.org> (raw)
In-Reply-To: <20261022223052.646891-5-seanjc@google.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] KVM: selftests: l1_clear_efer_svme() misses L2 exit and completion checks
- [Medium] KVM: selftests: test_host_initiated_lmsle() not updated for EFER CPUID check
- [Low] KVM: selftests: l2_clear_efer_svme() assert message says EFER.LME not SVME
--

commit bfd1afa646e17ebc8c26cbfd62dcc99d73a0c1f3
Author: Sean Christopherson <seanjc@google.com>

KVM: selftests: Update nSVM EFER test to expect #GP when clearing SVME in L2

This commit updates svm_nested_efer_test to expect a #GP fault in L2 when
clearing EFER.SVME via WRMSR instead of a triple-fault shutdown of L1, and
factors out a helper to run the guest EFER test cases.

> diff --git a/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c
> index fa0d76a9c390b..f612146d23ac2 100644
> --- a/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c
> +++ b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c
> @@ -15,13 +15,18 @@ static bool l2_ran;
>  static void l2_clear_efer_svme(void)
>  {
>  	u64 efer = rdmsr(MSR_EFER);
> +	u8 vector;
>  
>  	/* generic_svm_setup() initializes EFER_SVME set for L2 */
>  	GUEST_ASSERT(efer & EFER_SVME);
> -	wrmsr(MSR_EFER, efer & ~EFER_SVME);
>  
> -	/* Unreachable, L1 should be shutdown */
> -	GUEST_ASSERT(0);
> +	vector = wrmsr_safe(MSR_EFER, efer & ~EFER_SVME);
> +	__GUEST_ASSERT(vector == GP_VECTOR,
> +		       "Expected #GP when clearing EFER.LME in L2, got %s",
> +		       ex_str(vector));

[Severity: Low]
In l2_clear_efer_svme(), should the __GUEST_ASSERT() format string say
EFER.SVME instead of EFER.LME when wrmsr_safe(MSR_EFER, efer & ~EFER_SVME)
returns a vector other than GP_VECTOR?

> +
> +	l2_ran = true;
> +	vmmcall();
>  }
>  
>  static void l1_clear_efer_svme(struct svm_test_data *svm)
> @@ -29,8 +34,7 @@ static void l1_clear_efer_svme(struct svm_test_data *svm)
>  	generic_svm_setup(svm, l2_clear_efer_svme);
>  	run_guest(svm->vmcb, svm->vmcb_gpa);
>  
> -	/* Unreachable, L1 should be shutdown */
> -	GUEST_ASSERT(0);
> +	GUEST_DONE();
>  }

[Severity: Medium]
When test_clear_efer_svme() runs l1_clear_efer_svme(), run_guest() enters
l2_clear_efer_svme(), which sets l2_ran = true and executes vmmcall().
However, when run_guest() returns to l1_clear_efer_svme(), it immediately
calls GUEST_DONE() without checking l2_ran or svm->vmcb->control.exit_code
(unlike l1_lmsle()):

tools/testing/selftests/kvm/x86/svm_nested_efer_test.c:l1_lmsle() {
	...
	} else {
		GUEST_ASSERT_EQ(vmcb->control.exit_code, SVM_EXIT_VMMCALL);
		GUEST_ASSERT(l2_ran);
		GUEST_ASSERT(vmcb->save.efer & EFER_LMSLE);
	}
}

If VMRUN fails or if clearing EFER.SVME in L2 triggers a nested VM-Exit to L1
instead of injecting #GP into L2, wouldn't run_guest() return to
l1_clear_efer_svme() with l2_ran == false and still pass the test? Also,
should l2_clear_efer_svme() re-read MSR_EFER after wrmsr_safe() to verify
that EFER_SVME remained set?

[ ... ]

> @@ -248,7 +257,7 @@ int main(int argc, char *argv[])
>  		test_clear_efer_svme();
>  		test_lmsle(true);
>  	} else {
> -		ksft_test_result_skip("L2 clearing EFER.SVME shuts down L1\n");
> +		ksft_test_result_skip("L2 clearing EFER.SVME gets #GP\n");
>  		ksft_test_result_skip("Guest EFER_LMSLE_MBZ=1\n");
>  	}
>  

[Severity: Medium]
Earlier in this series, commit f8fc3a0796b0 ("Revert \"KVM: x86: Skip EFER
vs. guest CPUID checks for host-initiated writes\"") updated set_efer() in
arch/x86/kvm/msrs.c to enforce kvm_valid_efer() unconditionally on all
MSR_EFER writes, including host-initiated writes:

arch/x86/kvm/msrs.c:set_efer() {
	...
	if (!kvm_valid_efer(vcpu, efer))
		return 1;
	...
}

Because kvm_valid_efer() rejects EFER_LMSLE when X86_FEATURE_EFER_LMSLE_MBZ
is set in guest CPUID, won't main() -> test_host_initiated_lmsle() in
tools/testing/selftests/kvm/x86/svm_nested_efer_test.c now fail on hosts
where has_lmsle is true?

tools/testing/selftests/kvm/x86/svm_nested_efer_test.c:test_host_initiated_lmsle() {
	...
	vcpu_set_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ);
	...
	efer = vcpu_get_msr(vcpu, MSR_EFER);
	TEST_ASSERT(!(efer & EFER_LMSLE), "EFER.LMSLE unexpectedly set");

	vcpu_set_msr(vcpu, MSR_EFER, efer | EFER_LMSLE);
	...
}

Does test_host_initiated_lmsle() also need to be updated or removed to expect
host-initiated KVM_SET_MSRS writes to reject EFER_LMSLE when
X86_FEATURE_EFER_LMSLE_MBZ is set?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261022223052.646891-1-seanjc@google.com?part=4

      reply	other threads:[~2026-10-22 22:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 22:30 [PATCH 0/4] KVM: x86: More EFER.LMA vs. CR4.PAE fixes Sean Christopherson
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:38   ` sashiko-bot
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:41   ` sashiko-bot
2026-10-26 18:17     ` 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:48   ` sashiko-bot
2026-10-26 17:51     ` Sean Christopherson
2026-10-26 18:09       ` Sean Christopherson
2026-10-23 15:04   ` Yosry Ahmed
2026-10-26 17:37     ` 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
2026-10-22 22:51   ` sashiko-bot [this message]

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-182135@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox