[PATCH v6 0/2] cpufreq: acpi-cpufreq: fix P-state index mismatch between perf->states[] and freq_table[]

[PATCH v6 0/2] cpufreq: acpi-cpufreq: fix P-state index mismatch between perf->states[] and freq_table[]

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

policy->freq_table is built by filtering out _PSS entries that are not
lower in frequency than the previous one, and the original ACPI P-state
index of each remaining entry is kept in freq_table[].driver_data.  The
index spaces of perf->states[] and freq_table[] therefore differ, and
mixing them up leads to the frequency of one P-state being attributed to
another.

Patch 1/2 has no functional change from v5 and fixes the cached
frequency used by get_cur_freq_on_cpu() to detect a firmware frequency
change behind the OS's back.

Patch 2/2 is reworked.  In v5 it made extract_msr() return 0 for an
unmatched status and had get_cur_freq_on_cpu() set data->resume and
return the cached frequency instead.  As pointed out in the v5 review,
this cannot work: the returned value equals policy->cur, so
cpufreq_verify_current_freq() does not resynchronize policy->cur and
__cpufreq_driver_target() returns early before acpi_cpufreq_target()
can consume data->resume.  It also regressed the case where the OS is at
a lower P-state, which the old freq_table[0] fallback did get the core
to notice.

v6 instead lets extract_msr() look the status up in all of
perf->states[], so ->get() reports the real frequency of a filtered-out
P-state and the cpufreq core detects the mismatch itself.  The
freq_table[0] fallback is kept for a status that matches no _PSS entry,
and get_cur_freq_on_cpu() is left as in 1/2.

v5: <link to v5>

Changes since v5:
 - 1/2: no functional change; drop the changelog paragraph saying the
   extract_msr() fallback is addressed by the next patch.
 - 2/2: look the status up in perf->states[] instead of returning 0
   from extract_msr(); drop the get_cur_freq_on_cpu() change; new
   subject.
 - 2/2: changelog rewritten; drop the incorrect claim that the
   ACPI_ADR_SPACE_SYSTEM_IO path is covered, as ->get() is only
   registered for ACPI_ADR_SPACE_FIXED_HARDWARE.

Li RongQing (2):
  cpufreq: acpi-cpufreq: fix P-state index mismatch in
    get_cur_freq_on_cpu()
  cpufreq: acpi-cpufreq: report filtered-out P-states in extract_msr()

 drivers/cpufreq/acpi-cpufreq.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

-- 
2.9.4

[PATCH v6 1/2] cpufreq: acpi-cpufreq: fix P-state index mismatch in get_cur_freq_on_cpu()

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

get_cur_freq_on_cpu() uses perf->state, which is an index into
perf->states[], to index policy->freq_table[]. However, freq_table[]
is built by filtering _PSS entries that are not lower in frequency
than the previous one, so its index space no longer matches
perf->states[]. The original P-state index for each remaining
freq_table entry is stored in driver_data.

Once an entry has been skipped, using perf->state as an index into
freq_table[] can therefore select the frequency of a different
P-state.

The reported current frequency itself remains correct because it is
obtained from extract_freq(). The mismatch only affects the cached
frequency used by get_cur_freq_on_cpu() to detect a firmware frequency
change behind our back.

If the wrong table entry contains a frequency different from the one
the CPU is actually running at, the check falsely detects a frequency
change and sets data->resume. The next ->target() call then performs a
redundant control-register write even if the requested P-state is
already the current P-state.

Conversely, if the wrong table entry happens to contain the frequency
to which firmware has changed the CPU, the frequency change is missed
and data->resume remains clear. A subsequent ->target() call for the
P-state that the cpufreq core believes to be current can then
short-circuit without rewriting the control register, leaving the CPU
at the firmware-selected frequency until a different P-state is
requested.

Fix this by taking the cached frequency directly from
perf->states[perf->state].core_frequency. perf->state and
perf->states[] use the same P-state index space, and converting
core_frequency to kHz yields the same value stored in the corresponding
freq_table entry during initialization.

Fixes: e56a727b023d ("[CPUFREQ] Make acpi-cpufreq more robust against BIOS freq changes behind our back.")
Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Suggested-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index f64fa37..2d7d147 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -353,6 +353,7 @@ static u32 get_cur_val(const struct cpumask *mask, struct acpi_cpufreq_data *dat
 
 static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
 {
+	struct acpi_processor_performance *perf;
 	struct acpi_cpufreq_data *data;
 	struct cpufreq_policy *policy;
 	unsigned int freq;
@@ -368,7 +369,9 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
 	if (unlikely(!data || !policy->freq_table))
 		return 0;
 
-	cached_freq = policy->freq_table[to_perf_data(data)->state].frequency;
+	perf = to_perf_data(data);
+	cached_freq = perf->states[perf->state].core_frequency * 1000;
+
 	freq = extract_freq(policy, get_cur_val(cpumask_of(cpu), data));
 	if (freq != cached_freq) {
 		/*
-- 
2.9.4

[PATCH v6 2/2] cpufreq: acpi-cpufreq: report filtered-out P-states in extract_msr()

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

extract_msr() maps the status value read from the hardware to a
frequency by walking policy->freq_table.  freq_table[] is built by
filtering out _PSS entries that are not lower in frequency than the
previous one, so firmware may autonomously switch the CPU to a P-state
that has no freq_table entry.  The status of such a P-state cannot be
matched and extract_msr() falls back to freq_table[0].frequency.

get_cur_freq_on_cpu() is the ->get() callback for the
ACPI_ADR_SPACE_FIXED_HARDWARE case.  When firmware has changed the
P-state behind the OS's back, it sets data->resume so that the next
->target() call rewrites the control register even if the requested
P-state equals perf->state.  However, acpi_cpufreq_target() is reached
only if the cpufreq core sees a difference between the requested
frequency and policy->cur, because __cpufreq_driver_target() and
__target_index() return early when target_freq == policy->cur.
policy->cur is resynchronized from the ->get() value by
cpufreq_verify_current_freq(), so the frequency returned by ->get()
has to differ from policy->cur for data->resume to be acted upon in
the ->target_index() path.

If the OS is at the P-state corresponding to freq_table[0] and firmware
switches the CPU to a filtered-out P-state, the fallback makes ->get()
return the same frequency as policy->cur and cached_freq.  data->resume
is left clear, policy->cur is not updated, and the CPU stays at the
firmware-selected P-state while the cpufreq core believes it is at
freq_table[0].

Look the status up in all of perf->states[] instead and return the
frequency of the matching ACPI P-state.  For P-states retained in
freq_table[] this returns the same value as before, because the
frequency of each freq_table entry is perf->states[driver_data]
.core_frequency converted to kHz.  For a filtered-out P-state whose
frequency differs from policy->cur, get_cur_freq_on_cpu() now sets
data->resume and the cpufreq core updates policy->cur through
cpufreq_out_of_sync(), so the next request for the expected P-state
reaches acpi_cpufreq_target() and rewrites the control register.

The fallback to freq_table[0].frequency is kept for a status that
matches no _PSS entry at all, since returning 0 from ->get() makes
cpufreq_online() fail and triggers a warning in cpufreq_update_policy().
A filtered-out P-state with the same frequency as policy->cur is still
not detected through the ->target_index() path, but in that case the
CPU runs at the frequency the cpufreq core expects.

extract_io() is not changed: for ACPI_ADR_SPACE_SYSTEM_IO no ->get()
callback is registered and extract_io() is only used by check_freqs().

Fixes: e56a727b023d ("[CPUFREQ] Make acpi-cpufreq more robust against BIOS freq changes behind our back.")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260910111329.2220-1-lirongqing%40baidu.com
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 drivers/cpufreq/acpi-cpufreq.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 2d7d147..3dc7ee4 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -210,8 +210,8 @@ static unsigned extract_io(struct cpufreq_policy *policy, u32 value)
 static unsigned extract_msr(struct cpufreq_policy *policy, u32 msr)
 {
 	struct acpi_cpufreq_data *data = policy->driver_data;
-	struct cpufreq_frequency_table *pos;
 	struct acpi_processor_performance *perf;
+	unsigned int i;
 
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
 		msr &= AMD_MSR_RANGE;
@@ -222,9 +222,9 @@ static unsigned extract_msr(struct cpufreq_policy *policy, u32 msr)
 
 	perf = to_perf_data(data);
 
-	cpufreq_for_each_entry(pos, policy->freq_table)
-		if (msr == perf->states[pos->driver_data].status)
-			return pos->frequency;
+	for (i = 0; i < perf->state_count; i++)
+		if (msr == perf->states[i].status)
+			return perf->states[i].core_frequency * 1000;
 	return policy->freq_table[0].frequency;
 }
 
-- 
2.9.4