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 <[email protected]>
---
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 <[email protected]>
> ---
> 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