On Sun, Apr 25, 2021 at 9:35 AM Huang Rui ray.huang@amd.com wrote:

Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:

~ → lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000

Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies")

Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791 Signed-off-by: Huang Rui ray.huang@amd.com Cc: Alex Deucher alexander.deucher@amd.com Cc: Nathan Fontenot nathan.fontenot@amd.com Cc: Rafael J. Wysocki rafael.j.wysocki@intel.com Cc: Borislav Petkov bp@suse.de Cc: x86@kernel.org Cc: stable@vger.kernel.org

---

Changes from V1 -> V2:

• Enhance the commit message.
• Move amd_get_highest_perf() into amd.c.
• Refine the implementation of switch-case.
• Cc stable mail list.

Changes from V2 -> V3:

• Move the update into cppc_get_perf_caps() to correct the highest perf value in the API.

Changes from V3 -> V4:

• Rollback to V2 implementation because acpi_cppc.c will be used by ARM as well. It's not good to add x86-specific calling there.
• Simplify the implementation of the functions.

All of my comments have been addressed, so:

Reviewed-by: Rafael J. Wysocki rafael.j.wysocki@intel.com

and I'm expecting the x86 maintainers to take care of this patch.

---

arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 16 ++++++++++++++++ arch/x86/kernel/smpboot.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 6 +++++- 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index f1b9ed5efaa9..908bcaea1361 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -804,8 +804,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);

#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif

static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 347a956f71ca..bc3496669def 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }

+u32 amd_get_highest_perf(void) +{

•   struct cpuinfo_x86 *c = &boot_cpu_data;
  

•   if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
  

•                          (c->x86_model >= 0x70 && c->x86_model < 0x80)))
  

•       return 166;
  

•   if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
  

•                          (c->x86_model >= 0x40 && c->x86_model < 0x70)))
  

•       return 166;
  

•   return 225;
  

+} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 02813a7f3a7c..7bec57d04a87 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -2046,7 +2046,7 @@ static bool amd_set_max_freq_ratio(void) return false; }

•   highest_perf = perf_caps.highest_perf;
  

•   highest_perf = amd_get_highest_perf();
    nominal_perf = perf_caps.nominal_perf;
  
    if (!highest_perf || !nominal_perf) {
  

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index d1bbc16fba4b..7e7450453714 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -646,7 +646,11 @@ static u64 get_max_boost_ratio(unsigned int cpu) return 0; }

•   highest_perf = perf_caps.highest_perf;
  

•   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
  

•           highest_perf = amd_get_highest_perf();
  

•   else
  

•           highest_perf = perf_caps.highest_perf;
  

•   nominal_perf = perf_caps.nominal_perf;
  
    if (!highest_perf || !nominal_perf) {
  

-- 2.25.1

The following commit has been merged into the sched/urgent branch of tip:

Commit-ID: 337fb3130c29ef5ea3bbcd45e6589b7be6deeb4d Gitweb: https://git.kernel.org/tip/337fb3130c29ef5ea3bbcd45e6589b7be6deeb4d Author: Huang Rui ray.huang@amd.com AuthorDate: Sun, 25 Apr 2021 15:34:51 +08:00 Committer: Ingo Molnar mingo@kernel.org CommitterDate: Wed, 12 May 2021 21:14:08 +02:00

x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations

Some AMD Ryzen generations has different calculation method on maximum performance. 255 is not for all ASICs, some specific generations should use 166 as the maximum performance. Otherwise, it will report incorrect frequency value like below:

~ → lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000

[ mingo: Tidied up whitespace use. ]

Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Reported-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Reviewed-by: Rafael J. Wysocki rafael.j.wysocki@intel.com Signed-off-by: Huang Rui ray.huang@amd.com Signed-off-by: Ingo Molnar mingo@kernel.org Tested-by: Jason Bagavatsingham jason.bagavatsingham@gmail.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210425073451.2557394-1-ray.huang@amd.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791 --- arch/x86/include/asm/processor.h | 2 ++ arch/x86/kernel/cpu/amd.c | 16 ++++++++++++++++ arch/x86/kernel/smpboot.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 6 +++++- 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 154321d..556b2b1 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -787,8 +787,10 @@ DECLARE_PER_CPU(u64, msr_misc_features_shadow);

#ifdef CONFIG_CPU_SUP_AMD extern u32 amd_get_nodes_per_socket(void); +extern u32 amd_get_highest_perf(void); #else static inline u32 amd_get_nodes_per_socket(void) { return 0; } +static inline u32 amd_get_highest_perf(void) { return 0; } #endif

static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 2d11384..109d2c7 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1165,3 +1165,19 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } } + +u32 amd_get_highest_perf(void) +{ + struct cpuinfo_x86 *c = &boot_cpu_data; + + if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) || + (c->x86_model >= 0x70 && c->x86_model < 0x80))) + return 166; + + if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) || + (c->x86_model >= 0x40 && c->x86_model < 0x70))) + return 166; + + return 225; +} +EXPORT_SYMBOL_GPL(amd_get_highest_perf); diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 0ad5214..7770245 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -2043,7 +2043,7 @@ static bool amd_set_max_freq_ratio(void) return false; }

- highest_perf = perf_caps.highest_perf; + highest_perf = amd_get_highest_perf(); nominal_perf = perf_caps.nominal_perf;

if (!highest_perf || !nominal_perf) { diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index d1bbc16..7e74504 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -646,7 +646,11 @@ static u64 get_max_boost_ratio(unsigned int cpu) return 0; }

- highest_perf = perf_caps.highest_perf; + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) + highest_perf = amd_get_highest_perf(); + else + highest_perf = perf_caps.highest_perf; + nominal_perf = perf_caps.nominal_perf;

if (!highest_perf || !nominal_perf) {

* Alexander Monakov amonakov@ispras.ru wrote:

On Sun, 25 Apr 2021, Huang Rui wrote:

...

Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:

The commit message says '255', but the code:

...

--- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }

+u32 amd_get_highest_perf(void) +{

• struct cpuinfo_x86 *c = &boot_cpu_data;
• if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||

• 	       (c->x86_model >= 0x70 && c->x86_model < 0x80)))
  

•    return 166;
  

• if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||

• 	       (c->x86_model >= 0x40 && c->x86_model < 0x70)))
  

•    return 166;
  

• return 225;

+}

says 225? This is probably a typo? In any case they are out of sync.

Alexander

Ugh - that's indeed a good question ...

Thanks,

Ingo

* Huang Rui ray.huang@amd.com wrote:

On Thu, May 13, 2021 at 06:59:02AM +0800, Ingo Molnar wrote:

...

• Alexander Monakov amonakov@ispras.ru wrote:

...

On Sun, 25 Apr 2021, Huang Rui wrote:

...

Some AMD Ryzen generations has different calculation method on maximum perf. 255 is not for all asics, some specific generations should use 166 as the maximum perf. Otherwise, it will report incorrect frequency value like below:

The commit message says '255', but the code:

...

--- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1170,3 +1170,19 @@ void set_dr_addr_mask(unsigned long mask, int dr) break; } }

+u32 amd_get_highest_perf(void) +{

• struct cpuinfo_x86 *c = &boot_cpu_data;
• if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||

• 	       (c->x86_model >= 0x70 && c->x86_model < 0x80)))
  

•    return 166;
  

• if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||

• 	       (c->x86_model >= 0x40 && c->x86_model < 0x70)))
  

•    return 166;
  

• return 225;

+}

says 225? This is probably a typo? In any case they are out of sync.

Alexander

Ugh - that's indeed a good question ...

Ah sorry! It's my typo. It should be 255 (confirmed in the ucode).

Alexander, thanks a lot to catch this!

Ingo, would you mind to update it from 225 -> 255 while you apply this patch or let me know if you want me to send v5?

No need to send v5, done!

I have a system that appears to be affected by this bug:

kepler:~> lscpu | grep -i mhz CPU MHz: 4000.000 CPU max MHz: 7140.6250 CPU min MHz: 2200.0000

So I should be able to confirm after a reboot.

Thanks,

Ingo