| Message ID | 20240411163130.1809713-1-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] KVM: x86: Advertise PCID based on hardware support (with an asterisk) | expand |
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/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".
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);
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(+) base-commit: f10f3621ad80f008c218dbbc13a05c893766a7d2