Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, Sean Christopherson <seanjc@google.com>,
	 Mathias Krause <minipli@grsecurity.net>,
	Andrew Jones <andrew.jones@linux.dev>
Subject: [kvm-unit-tests PATCH v3 10/20] x86/vmx: Track VMCS "launched" state per-CPU
Date: Thu, 14 May 2026 14:04:50 -0700	[thread overview]
Message-ID: <20260514210500.1626871-11-seanjc@google.com> (raw)
In-Reply-To: <20260514210500.1626871-1-seanjc@google.com>

Track whether or not a VMCS has been "launched" per-CPU to play nice with
VMX tests that use multiple VMCSes.  Arguably, it would be better to add a
structure to track the current VMCS and its launched state, but there's no
immediate benefit to doing so, and practically speaking the only thing that
would be tracked (without support for e.g. eVMCS) would be the "launched"
state.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 lib/x86/smp.h |  4 ++++
 x86/vmx.c     | 10 +++++-----
 x86/vmx.h     |  3 ++-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/lib/x86/smp.h b/lib/x86/smp.h
index e4dc0395..7f973227 100644
--- a/lib/x86/smp.h
+++ b/lib/x86/smp.h
@@ -56,7 +56,10 @@ struct percpu_data {
 		uint32_t exception_data;
 	};
 	void *apic_ops;
+
 	struct guest_regs guest_regs;
+	/* Track whether or not the current CPU's VMCS has been "launched". */
+	bool launched;
 };
 
 #define typeof_percpu(name) typeof(((struct percpu_data *)0)->name)
@@ -109,6 +112,7 @@ BUILD_PERCPU_OP(exception_vector);
 BUILD_PERCPU_OP(exception_rflags_rf);
 BUILD_PERCPU_OP(exception_error_code);
 BUILD_PERCPU_OP(apic_ops);
+BUILD_PERCPU_OP(launched);
 
 void smp_init(void);
 
diff --git a/x86/vmx.c b/x86/vmx.c
index 7da549d1..85772cae 100644
--- a/x86/vmx.c
+++ b/x86/vmx.c
@@ -60,7 +60,6 @@ static struct test_teardown_step teardown_steps[MAX_TEST_TEARDOWN_STEPS];
 static test_guest_func v2_guest_main;
 
 u64 hypercall_field;
-bool launched;
 static int matched;
 static int guest_finished;
 static int in_guest;
@@ -1728,6 +1727,8 @@ static int exit_handler(union exit_reason exit_reason)
  */
 static noinline void vmx_enter_guest(struct vmentry_result *result)
 {
+	bool launched = this_cpu_read_launched();
+
 	memset(result, 0, sizeof(*result));
 
 	in_guest = 1;
@@ -1779,7 +1780,7 @@ static int vmx_run(void)
 			 * VMCS isn't in "launched" state if there's been any
 			 * entry failure (early or otherwise).
 			 */
-			launched = 1;
+			this_cpu_write_launched(true);
 			ret = exit_handler(result.exit_reason);
 		} else if (current->entry_failure_handler) {
 			ret = current->entry_failure_handler(&result);
@@ -1848,7 +1849,6 @@ static int test_run(struct vmx_test *test)
 	v2_guest_main = NULL;
 	test->exits = 0;
 	current = test;
-	launched = 0;
 	guest_finished = 0;
 	printf("\nTest suite: %s\n", test->name);
 
@@ -1867,7 +1867,7 @@ static int test_run(struct vmx_test *test)
 	while (teardown_count > 0)
 		run_teardown_step(&teardown_steps[--teardown_count]);
 
-	if (launched && !guest_finished)
+	if (this_cpu_read_launched() && !guest_finished)
 		report_fail("Guest didn't run to completion.");
 
 out:
@@ -1975,7 +1975,7 @@ void __enter_guest(u8 abort_flag, struct vmentry_result *result)
 		return;
 	}
 
-	launched = 1;
+	this_cpu_write_launched(true);
 	check_for_guest_termination(result->exit_reason);
 	return;
 
diff --git a/x86/vmx.h b/x86/vmx.h
index 56f37633..c1c6eba4 100644
--- a/x86/vmx.h
+++ b/x86/vmx.h
@@ -794,7 +794,6 @@ static inline bool is_mbec_supported(void)
 }
 
 extern u64 *bsp_vmxon_region;
-extern bool launched;
 
 void vmx_set_test_stage(u32 s);
 u32 vmx_get_test_stage(void);
@@ -856,6 +855,8 @@ static inline int vmcs_clear(struct vmcs *vmcs)
 	bool ret;
 	u64 rflags = read_rflags() | X86_EFLAGS_CF | X86_EFLAGS_ZF;
 
+	this_cpu_write_launched(false);
+
 	asm volatile ("push %1; popf; vmclear %2; setbe %0"
 		      : "=q" (ret) : "q" (rflags), "m" (vmcs) : "cc");
 	return ret;
-- 
2.54.0.563.g4f69b47b94-goog


  parent reply	other threads:[~2026-05-14 21:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14 21:04 [kvm-unit-tests PATCH v3 00/20] x86: Better backtraces for leaf functions Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 01/20] x86/vmx: Drop unused SYSENTER "support" in nested VMX infrastructure Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 02/20] x86/vmx: Drop unused guest_regs " Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 03/20] x86/svm: Sort (and swap) GPRs by their index, not alphabetically Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 04/20] x86: Dedup guest/host context switch of registers across SVM and VMX Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 05/20] x86/virt: Use macro shenanigans to get reg offsets when swapping guest/host regs Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 06/20] x86/virt: Track "guest regs" using per-CPU variable Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 07/20] x86/svm: Don't VMLOAD/VMSAVE "guest" state around VMRUN Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 08/20] x86/vmx: Use separate VMCSes for BSP vs. AP in INIT test Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 09/20] x86/vmx: Swap GPRs after checking "launched" status Sean Christopherson
2026-05-14 21:04 ` Sean Christopherson [this message]
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 11/20] x86/vmx: Track "is this CPU in guest mode" per-CPU Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 12/20] x86/vmx: Communicate hypercalls via RAX, not a global field Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 13/20] x86/vmx: Initialize test stage in SIPI test *before* launching AP thread Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 14/20] x86/kvmclock: Replace spaces with tabs Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 15/20] x86/kvmclock: Skip kvmclock test when not running on KVM with CLOCKSOURCE2 Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 16/20] x86/vmx: Tag "struct vmx_msr_entry" as needing to be 16-byte aligned Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 17/20] x86/smp: Align the stack to a 16-byte boundary when invoking SMP function calls Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 18/20] x86/vmx: Write to KVM's WALL_CLOCK MSR via VM-Entry load list sync in SIPI test Sean Christopherson
2026-05-14 21:04 ` [kvm-unit-tests PATCH v3 19/20] x86: Better backtraces for leaf functions Sean Christopherson
2026-05-14 21:05 ` [kvm-unit-tests PATCH v3 20/20] x86: Prevent realmode test code instrumentation with nop-mcount 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=20260514210500.1626871-11-seanjc@google.com \
    --to=seanjc@google.com \
    --cc=andrew.jones@linux.dev \
    --cc=kvm@vger.kernel.org \
    --cc=minipli@grsecurity.net \
    --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