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 <[email protected]>
Cc: Pawan Gupta <[email protected]>
Cc: Sean Christopherson <[email protected]>
Cc: Andrew Cooper <[email protected]>
Cc: Xi Ruoyao <[email protected]>
Signed-off-by: Sean Christopherson <[email protected]>
---
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
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
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/[email protected]
> 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".