lkml.org 
[lkml]   [2022]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] x86,acpi: Limit "Dummy wait" workaround to older AMD and Intel processors
On Fri, Sep 23, 2022 at 09:08:01PM +0530, K Prateek Nayak wrote:
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index ef4775c6db01..fcd3617ed315 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -460,5 +460,6 @@
> #define X86_BUG_MMIO_UNKNOWN X86_BUG(26) /* CPU is too old and its MMIO Stale Data status is unknown */
> #define X86_BUG_RETBLEED X86_BUG(27) /* CPU is affected by RETBleed */
> #define X86_BUG_EIBRS_PBRSB X86_BUG(28) /* EIBRS is vulnerable to Post Barrier RSB Predictions */
> +#define X86_BUG_STPCLK X86_BUG(29) /* STPCLK# signal does not get asserted in time during IOPORT based C-state entry */
>
> #endif /* _ASM_X86_CPUFEATURES_H */
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 48276c0e479d..8cb5887a53a3 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -988,6 +988,18 @@ static void init_amd(struct cpuinfo_x86 *c)
> if (!cpu_has(c, X86_FEATURE_XENPV))
> set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>
> + /*
> + * CPUs based on the Zen microarchitecture (Fam 17h onward) can
> + * guarantee that STPCLK# signal is asserted in time after the
> + * P_LVL2 read to freeze execution after an IOPORT based C-state
> + * entry. Among the older AMD processors, there has been at least
> + * one report of an AMD Athlon processor on a VIA chipset
> + * (circa 2006) having this issue. Mark all these older AMD
> + * processor families as being affected.
> + */
> + if (c->x86 < 0x17)
> + set_cpu_bug(c, X86_BUG_STPCLK);
> +
> /*
> * Turn on the Instructions Retired free counter on machines not
> * susceptible to erratum #1054 "Instructions Retired Performance
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 2d7ea5480ec3..96fe1320c238 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -696,6 +696,18 @@ static void init_intel(struct cpuinfo_x86 *c)
> ((c->x86_model == INTEL_FAM6_ATOM_GOLDMONT)))
> set_cpu_bug(c, X86_BUG_MONITOR);
>
> + /*
> + * Intel chipsets prior to Nehalem used the ACPI processor_idle
> + * driver for C-state management. Some of these processors that
> + * used IOPORT based C-states could not guarantee that STPCLK#
> + * signal gets asserted in time after P_LVL2 read to freeze
> + * execution properly. Since a clear cut-off point is not known
> + * as to when this bug was solved, mark all the chipsets as
> + * being affected. Only the ones that use IOPORT based C-state
> + * transitions via the acpi_idle driver will be impacted.
> + */
> + set_cpu_bug(c, X86_BUG_STPCLK);
> +
> #ifdef CONFIG_X86_64
> if (c->x86 == 15)
> c->x86_cache_alignment = c->x86_clflush_size * 2;

Quiz time:

#define X86_VENDOR_INTEL 0
#define X86_VENDOR_CYRIX 1
#define X86_VENDOR_AMD 2
#define X86_VENDOR_UMC 3
#define X86_VENDOR_CENTAUR 5
#define X86_VENDOR_TRANSMETA 7
#define X86_VENDOR_NSC 8
#define X86_VENDOR_HYGON 9
#define X86_VENDOR_ZHAOXIN 10
#define X86_VENDOR_VORTEX 11
#define X86_VENDOR_NUM 12
#define X86_VENDOR_UNKNOWN 0xff

For how many of the above have you changed behaviour?

Not to mention that this is the gazillion-th time AMD has failed to
change HYGON in lock-step. That's Zen too -- deal with it.

\
 
 \ /
  Last update: 2022-09-26 15:57    [W:0.340 / U:1.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site