The LFENCE_RDTSC / LFENCE always serializing feature was a scattered bit
and open-coded for KVM in __do_cpuid_func(). Add it to its newly added
CPUID leaf 0x80000021 EAX proper, and propagate it in kvm_set_cpu_caps()
instead.
Also drop the bit description comments now it's more self-describing.
Whilst there, switch to using the more efficient cpu_feature_enabled()
instead of static_cpu_has().
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
---
arch/x86/include/asm/cpufeatures.h | 3 ++-
arch/x86/kvm/cpuid.c | 9 ++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 0cd7b4afd528..79da8e492c0f 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -97,7 +97,7 @@
#define X86_FEATURE_SYSENTER32 ( 3*32+15) /* "" sysenter in IA32 userspace */
#define X86_FEATURE_REP_GOOD ( 3*32+16) /* REP microcode works well */
#define X86_FEATURE_AMD_LBR_V2 ( 3*32+17) /* AMD Last Branch Record Extension Version 2 */
-#define X86_FEATURE_LFENCE_RDTSC ( 3*32+18) /* "" LFENCE synchronizes RDTSC */
+/* FREE, was #define X86_FEATURE_LFENCE_RDTSC ( 3*32+18) "" LFENCE synchronizes RDTSC */
#define X86_FEATURE_ACC_POWER ( 3*32+19) /* AMD Accumulated Power Mechanism */
#define X86_FEATURE_NOPL ( 3*32+20) /* The NOPL (0F 1F) instructions */
#define X86_FEATURE_ALWAYS ( 3*32+21) /* "" Always-present feature */
@@ -428,6 +428,7 @@
/* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */
#define X86_FEATURE_NO_NESTED_DATA_BP (20*32+ 0) /* "" AMD No Nested Data Breakpoints */
+#define X86_FEATURE_LFENCE_RDTSC (20*32+ 2) /* "" LFENCE always serializing / synchronizes RDTSC */
/*
* BUG word(s)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 69e433e4e9ff..88c970046c10 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -742,8 +742,10 @@ void kvm_set_cpu_caps(void)
F(SME_COHERENT));
kvm_cpu_cap_mask(CPUID_8000_0021_EAX,
- F(NO_NESTED_DATA_BP)
+ F(NO_NESTED_DATA_BP) | F(LFENCE_RDTSC)
);
+ if (cpu_feature_enabled(X86_FEATURE_LFENCE_RDTSC))
+ kvm_cpu_cap_set(X86_FEATURE_LFENCE_RDTSC);
kvm_cpu_cap_mask(CPUID_C000_0001_EDX,
F(XSTORE) | F(XSTORE_EN) | F(XCRYPT) | F(XCRYPT_EN) |
@@ -1229,7 +1231,6 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
cpuid_entry_override(entry, CPUID_8000_0021_EAX);
/*
* Pass down these bits:
- * EAX 2 LAS, LFENCE always serializing
* EAX 6 NSCB, Null selector clear base
*
* Other defined bits are for MSRs that KVM does not expose:
@@ -1239,10 +1240,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
* KVM doesn't support SMM_CTL.
* EAX 9 SMM_CTL MSR is not supported
*/
- entry->eax &= BIT(2) | BIT(6);
+ entry->eax &= BIT(6);
entry->eax |= BIT(9);
- if (static_cpu_has(X86_FEATURE_LFENCE_RDTSC))
- entry->eax |= BIT(2);
if (!static_cpu_has_bug(X86_BUG_NULL_SEG))
entry->eax |= BIT(6);
break;
--
2.34.1
On Tue, Jan 10, 2023 at 04:46:39PM -0600, Kim Phillips wrote: > The LFENCE_RDTSC / LFENCE always serializing feature was a scattered bit > and open-coded for KVM in __do_cpuid_func(). Add it to its newly added > CPUID leaf 0x80000021 EAX proper, and propagate it in kvm_set_cpu_caps() > instead. > > Also drop the bit description comments now it's more self-describing. > > Whilst there, switch to using the more efficient cpu_feature_enabled() > instead of static_cpu_has(). > > Signed-off-by: Kim Phillips <kim.phillips@amd.com> > --- > arch/x86/include/asm/cpufeatures.h | 3 ++- > arch/x86/kvm/cpuid.c | 9 ++++----- > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h > index 0cd7b4afd528..79da8e492c0f 100644 > --- a/arch/x86/include/asm/cpufeatures.h > +++ b/arch/x86/include/asm/cpufeatures.h > @@ -97,7 +97,7 @@ > #define X86_FEATURE_SYSENTER32 ( 3*32+15) /* "" sysenter in IA32 userspace */ > #define X86_FEATURE_REP_GOOD ( 3*32+16) /* REP microcode works well */ > #define X86_FEATURE_AMD_LBR_V2 ( 3*32+17) /* AMD Last Branch Record Extension Version 2 */ > -#define X86_FEATURE_LFENCE_RDTSC ( 3*32+18) /* "" LFENCE synchronizes RDTSC */ > +/* FREE, was #define X86_FEATURE_LFENCE_RDTSC ( 3*32+18) "" LFENCE synchronizes RDTSC */ > #define X86_FEATURE_ACC_POWER ( 3*32+19) /* AMD Accumulated Power Mechanism */ > #define X86_FEATURE_NOPL ( 3*32+20) /* The NOPL (0F 1F) instructions */ > #define X86_FEATURE_ALWAYS ( 3*32+21) /* "" Always-present feature */ > @@ -428,6 +428,7 @@ > > /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */ > #define X86_FEATURE_NO_NESTED_DATA_BP (20*32+ 0) /* "" AMD No Nested Data Breakpoints */ > +#define X86_FEATURE_LFENCE_RDTSC (20*32+ 2) /* "" LFENCE always serializing / synchronizes RDTSC */ Hmm, a synthetic bit which gets replaced with a vendor one and then the other vendors set it too. I don't see why that cannot work but we probably should be careful here. dhansen, am I missing an angle? Also, X86_FEATURE_LFENCE_RDTSC gets set in init_amd() along with setting DE_CFG[1]. I think you should check the new flag here first and avoid the setting if that flag is set. Just for good measure - not that it changes anything but still, it is cheap to do. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
On 1/16/23 10:13, Borislav Petkov wrote: >> /* AMD-defined Extended Feature 2 EAX, CPUID level 0x80000021 (EAX), word 20 */ >> #define X86_FEATURE_NO_NESTED_DATA_BP (20*32+ 0) /* "" AMD No Nested Data Breakpoints */ >> +#define X86_FEATURE_LFENCE_RDTSC (20*32+ 2) /* "" LFENCE always serializing / synchronizes RDTSC */ > Hmm, a synthetic bit which gets replaced with a vendor one and then the other > vendors set it too. I don't see why that cannot work but we probably should be > careful here. > > dhansen, am I missing an angle? I don't think so. I'd be surprised if we don't have a _few_ other cases like this around, but nothing is coming to mind. Either way, it doesn't seem problematic.
On Mon, Jan 16, 2023 at 01:15:29PM -0800, Dave Hansen wrote: > I don't think so. > > I'd be surprised if we don't have a _few_ other cases like this around, > but nothing is coming to mind. Either way, it doesn't seem problematic. Yeah, probably. The cases I remember are the other way around - we map vendor-specific flags to synthetic ones... Anyway, thanks for checking! -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2025 Red Hat, Inc.