public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] KVM: x86: Advertise PCID based on hardware support (with an asterisk)
@ 2024-04-11 16:31 Sean Christopherson
  2024-04-11 16:36 ` Paolo Bonzini
  0 siblings, 1 reply; 3+ messages in thread
From: Sean Christopherson @ 2024-04-11 16:31 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
	Sean Christopherson, Paolo Bonzini, Andy Lutomirski,
	Peter Zijlstra
  Cc: linux-kernel, kvm, Michael Kelley, Pawan Gupta, Andrew Cooper,
	Xi Ruoyao

Force set a synthetic feature, GUEST_PCID, if PCID can be safely used in
virtual machines, even if the kernel itself disables PCID support, and
advertise PCID support in KVM if GUEST_PCID is set.

When running on a CPU that is affected by Intel's "Global INVLPG" erratum,
which does NOT affect VMX non-root mode, it is safe to virtualize PCID for
KVM guests, even though it is not safe for the kernel itself to enable PCID.
Ditto for if the kernel disables PCID because CR4.PGE isn't supported.

Use a synthetic bit instead of having KVM check raw CPUID so that KVM
honors disabling PCID via the "nopcid" kernel parameter, and to guard
against PCID being disabled due to a erratum that DOES affect guests.

Cc: Michael Kelley <mhklinux@outlook.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---

Tagged RFC because I'm 50/50 on whether or not this is worth doing.  On one
hand, it's a relatively small patch.  On the other hand, we can simply wait for
the ucode fix to roll out (the !PGE case doesn't seem like sufficient motivation
to carry this code).

 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/kvm/cpuid.c               | 7 +++++++
 arch/x86/mm/init.c                 | 8 ++++++++
 3 files changed, 16 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index a38f8f9ba657..97006581278c 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -227,6 +227,7 @@
 #define X86_FEATURE_FLEXPRIORITY	( 8*32+ 1) /* Intel FlexPriority */
 #define X86_FEATURE_EPT			( 8*32+ 2) /* Intel Extended Page Table */
 #define X86_FEATURE_VPID		( 8*32+ 3) /* Intel Virtual Processor ID */
+#define X86_FEATURE_GUEST_PCID          ( 8*32+ 4) /* "" PCID is safe to expose to KVM guests */
 
 #define X86_FEATURE_VMMCALL		( 8*32+15) /* Prefer VMMCALL to VMCALL */
 #define X86_FEATURE_XENPV		( 8*32+16) /* "" Xen paravirtual guest */
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 2f1dd059ea79..4ae4b7291b5a 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -628,6 +628,13 @@ void kvm_set_cpu_caps(void)
 	/* KVM emulates x2apic in software irrespective of host support. */
 	kvm_cpu_cap_set(X86_FEATURE_X2APIC);
 
+	/*
+	 * On some CPUs, PCID can be used in virtual machines, even if it's
+	 * disabled in the host kernel.
+	 */
+	if (boot_cpu_has(X86_FEATURE_GUEST_PCID))
+		kvm_cpu_cap_set(X86_FEATURE_PCID);
+
 	kvm_cpu_cap_mask(CPUID_1_EDX,
 		F(FPU) | F(VME) | F(DE) | F(PSE) |
 		F(TSC) | F(MSR) | F(PAE) | F(MCE) |
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 679893ea5e68..9b85beee06dc 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -287,6 +287,14 @@ static void setup_pcid(void)
 	if (!boot_cpu_has(X86_FEATURE_PCID))
 		return;
 
+	/*
+	 * PCID is supported in hardware and can be safely exposed to virtual
+	 * machines, even if the kernel doesn't utilize PCID itself, e.g. due
+	 * to lack of PGE support, or because of Intel's errata (which doesn't
+	 * impact VMX non-root mode, a.k.a. guest mode).
+	 */
+	setup_force_cpu_cap(X86_FEATURE_GUEST_PCID);
+
 	if (x86_match_cpu(invlpg_miss_ids)) {
 		pr_info("Incomplete global flushes, disabling PCID");
 		setup_clear_cpu_cap(X86_FEATURE_PCID);

base-commit: f10f3621ad80f008c218dbbc13a05c893766a7d2
-- 
2.44.0.683.g7961c838ac-goog


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [RFC PATCH] KVM: x86: Advertise PCID based on hardware support (with an asterisk)
  2024-04-11 16:31 [RFC PATCH] KVM: x86: Advertise PCID based on hardware support (with an asterisk) Sean Christopherson
@ 2024-04-11 16:36 ` Paolo Bonzini
  2024-04-11 19:11   ` Sean Christopherson
  0 siblings, 1 reply; 3+ messages in thread
From: Paolo Bonzini @ 2024-04-11 16:36 UTC (permalink / raw)
  To: Sean Christopherson, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, Dave Hansen, x86, Andy Lutomirski,
	Peter Zijlstra
  Cc: linux-kernel, kvm, Michael Kelley, Pawan Gupta, Andrew Cooper,
	Xi Ruoyao

On 4/11/24 18:31, Sean Christopherson wrote:
> Force set a synthetic feature, GUEST_PCID, if PCID can be safely used in
> virtual machines, even if the kernel itself disables PCID support, and
> advertise PCID support in KVM if GUEST_PCID is set.
> 
> When running on a CPU that is affected by Intel's "Global INVLPG" erratum,
> which does NOT affect VMX non-root mode, it is safe to virtualize PCID for
> KVM guests, even though it is not safe for the kernel itself to enable PCID.
> Ditto for if the kernel disables PCID because CR4.PGE isn't supported.

But the guest would not use it if the f/m/s matches, right?  If the 
advantage is basically not splitting the migration pool, is that a 
concern for the affected Alder Lake/Gracemont/Raptor Lake processors?

Paolo


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC PATCH] KVM: x86: Advertise PCID based on hardware support (with an asterisk)
  2024-04-11 16:36 ` Paolo Bonzini
@ 2024-04-11 19:11   ` Sean Christopherson
  0 siblings, 0 replies; 3+ messages in thread
From: Sean Christopherson @ 2024-04-11 19:11 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
	Andy Lutomirski, Peter Zijlstra, linux-kernel, kvm,
	Michael Kelley, Pawan Gupta, Andrew Cooper, Xi Ruoyao

On Thu, Apr 11, 2024, Paolo Bonzini wrote:
> On 4/11/24 18:31, Sean Christopherson wrote:
> > Force set a synthetic feature, GUEST_PCID, if PCID can be safely used in
> > virtual machines, even if the kernel itself disables PCID support, and
> > advertise PCID support in KVM if GUEST_PCID is set.
> > 
> > When running on a CPU that is affected by Intel's "Global INVLPG" erratum,
> > which does NOT affect VMX non-root mode, it is safe to virtualize PCID for
> > KVM guests, even though it is not safe for the kernel itself to enable PCID.
> > Ditto for if the kernel disables PCID because CR4.PGE isn't supported.
> 
> But the guest would not use it if the f/m/s matches, right?

Maybe?  There's another in-flight patch for dealing with the guest side of
things.

https://lore.kernel.org/all/20240411144322.14585-2-xry111@xry111.site

> If the advantage is basically not splitting the migration pool, is that a
> concern for the affected Alder Lake/Gracemont/Raptor Lake processors?

I have put _zero_ thought into what value this actually adds (another reason I
tagged it RFC).  This was purely a "it's easy, so why not".

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-04-11 19:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-11 16:31 [RFC PATCH] KVM: x86: Advertise PCID based on hardware support (with an asterisk) Sean Christopherson
2024-04-11 16:36 ` Paolo Bonzini
2024-04-11 19:11   ` Sean Christopherson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox