From: Adrian Hunter <adrian.hunter@intel.com>
To: "Xin Li (Intel)" <xin@zytor.com>, <linux-kernel@vger.kernel.org>,
<kvm@vger.kernel.org>, <linux-pm@vger.kernel.org>,
"Shishkin, Alexander" <alexander.shishkin@intel.com>
Cc: <seanjc@google.com>, <pbonzini@redhat.com>, <tglx@linutronix.de>,
<mingo@redhat.com>, <bp@alien8.de>, <dave.hansen@linux.intel.com>,
<x86@kernel.org>, <hpa@zytor.com>, <rafael@kernel.org>,
<pavel@kernel.org>, <brgerst@gmail.com>, <david.kaplan@amd.com>,
<peterz@infradead.org>, <andrew.cooper3@citrix.com>,
<kprateek.nayak@amd.com>, <arjan@linux.intel.com>,
<chao.gao@intel.com>, <rick.p.edgecombe@intel.com>,
<dan.j.williams@intel.com>, "Kleen, Andi" <andi.kleen@intel.com>
Subject: Re: [RFC PATCH v1 1/5] x86/boot: Shift VMXON from KVM init to CPU startup phase
Date: Wed, 10 Sep 2025 08:37:58 +0300 [thread overview]
Message-ID: <4f76756a-d1f3-4a39-8de7-5a77d94c55da@intel.com> (raw)
In-Reply-To: <20250909182828.1542362-2-xin@zytor.com>
On 09/09/2025 21:28, Xin Li (Intel) wrote:
> +/*
> + * Executed during the CPU startup phase to execute VMXON to enable VMX. This
> + * ensures that KVM, often loaded as a kernel module, no longer needs to worry
> + * about whether or not VMXON has been executed on a CPU (e.g., CPU offline
> + * events or system reboots while KVM is loading).
> + *
> + * VMXON is not expected to fault, but fault handling is kept as a precaution
> + * against any unexpected code paths that might trigger it and can be removed
> + * later if unnecessary.
> + */
> +void cpu_enable_virtualization(void)
> +{
> + u64 vmxon_pointer = __pa(this_cpu_ptr(&vmxon_vmcs));
> + int cpu = raw_smp_processor_id();
> + u64 basic_msr;
> +
> + if (!is_vmx_supported())
> + return;
> +
> + if (cr4_read_shadow() & X86_CR4_VMXE) {
> + pr_err("VMX already enabled on CPU%d\n", cpu);
> + return;
> + }
> +
> + memset(this_cpu_ptr(&vmxon_vmcs), 0, PAGE_SIZE);
> +
> + /*
> + * Even though not explicitly documented by TLFS, VMXArea passed as
> + * VMXON argument should still be marked with revision_id reported by
> + * physical CPU.
> + */
> + rdmsrq(MSR_IA32_VMX_BASIC, basic_msr);
> + this_cpu_ptr(&vmxon_vmcs)->hdr.revision_id = vmx_basic_vmcs_revision_id(basic_msr);
> +
> + intel_pt_handle_vmx(1);
intel_pt_handle_vmx() depends on pt_pmu.vmx which is not initialized
until arch_initcall(pt_init), but it looks like cpu_enable_virtualization()
is called earlier than that.
Also note, intel_pt_handle_vmx() exists because Intel PT and
VMX operation are not allowed together if MSR_IA32_VMX_MISC[14] == 0.
That only affects BDW AFAIK.
And note, moving intel_pt_handle_vmx() back to vmx_enable_virtualization_cpu()
does not look right. It seems to belong with VMXON, refer SDM:
APPENDIX A VMX CAPABILITY REPORTING FACILITY
A.6 MISCELLANEOUS DATA
If bit 14 is read as 1, Intel® Processor Trace (Intel PT) can be used in VMX operation. If the processor supports
Intel PT but does not allow it to be used in VMX operation, execution of VMXON clears IA32_RTIT_CTL.TraceEn
(see “VMXON—Enter VMX Operation” in Chapter 32); any attempt to write IA32_RTIT_CTL while in VMX
operation (including VMX root operation) causes a general-protection exception.
next prev parent reply other threads:[~2025-09-10 5:38 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 18:28 [RFC PATCH v1 0/5] x86/boot, KVM: Move VMXON/VMXOFF handling from KVM to CPU lifecycle Xin Li (Intel)
2025-09-09 18:28 ` [RFC PATCH v1 1/5] x86/boot: Shift VMXON from KVM init to CPU startup phase Xin Li (Intel)
2025-09-10 5:37 ` Adrian Hunter [this message]
2025-09-10 7:25 ` Chao Gao
2025-09-11 6:57 ` Xin Li
2025-09-10 8:02 ` Huang, Kai
2025-09-10 11:10 ` Chao Gao
2025-09-10 11:35 ` Huang, Kai
2025-09-10 13:13 ` Arjan van de Ven
2025-09-10 20:52 ` Huang, Kai
2025-09-09 18:28 ` [RFC PATCH v1 2/5] x86/boot: Move VMXOFF from KVM teardown to CPU shutdown phase Xin Li (Intel)
2025-09-09 18:28 ` [RFC PATCH v1 3/5] x86/shutdown, KVM: VMX: Move VMCLEAR of VMCSs to cpu_disable_virtualization() Xin Li (Intel)
2025-09-09 18:28 ` [RFC PATCH v1 4/5] x86/reboot: Remove emergency_reboot_disable_virtualization() Xin Li (Intel)
2025-09-09 18:28 ` [RFC PATCH v1 5/5] KVM: Remove kvm_rebooting and its references Xin Li (Intel)
2025-09-16 17:56 ` Sean Christopherson
2025-09-17 16:51 ` Xin Li
2025-09-17 23:02 ` Sean Christopherson
2025-09-11 14:20 ` [RFC PATCH v1 0/5] x86/boot, KVM: Move VMXON/VMXOFF handling from KVM to CPU lifecycle Sean Christopherson
2025-09-11 15:20 ` Dave Hansen
2025-09-16 17:29 ` Sean Christopherson
2025-09-11 17:04 ` Arjan van de Ven
2025-09-16 17:54 ` Sean Christopherson
2025-09-16 18:25 ` Jim Mattson
2025-09-17 13:48 ` Arjan van de Ven
2025-09-17 17:30 ` Xin Li
2025-09-17 22:40 ` 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=4f76756a-d1f3-4a39-8de7-5a77d94c55da@intel.com \
--to=adrian.hunter@intel.com \
--cc=alexander.shishkin@intel.com \
--cc=andi.kleen@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=chao.gao@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david.kaplan@amd.com \
--cc=hpa@zytor.com \
--cc=kprateek.nayak@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xin@zytor.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