lkml.org 
[lkml]   [2021]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: problem in changing from active to passive mode
On Thu, Oct 28, 2021 at 10:18 PM Julia Lawall <julia.lawall@inria.fr> wrote:
>
>
>
> On Thu, 28 Oct 2021, Rafael J. Wysocki wrote:
>
> > On Thu, Oct 28, 2021 at 9:25 PM Julia Lawall <julia.lawall@inria.fr> wrote:

[cut]

> > Attached is a patch to do that, but please note that the 5.9 will need
> > to be patched too to address this issue.
>
> I'm not completely clear on what the new patch is doing and how I should
> test it. If I stay in 5.15, the original patch worked for clearing des
> when going from passive to active.

Sorry for the confusion.

If applied to 5.15-rc alone, the last patch would cause des to be
cleared when switching from passive to active and if applied to both
5.15-rc and 5.9, it would fix the kexec issue as well.

Never mind, though.

The patch attached to this message should cause des to be cleared when
switching from passive to active (because it is based on the previous
patch doing that) and it should prevent nonzero des from being leaked
via the HWP_REQUEST MSR to the new kernel started via kexec. With
this patch applied to 5.15-rc des should be 0 when switching from
passive to active and it should also be 0 after starting another
kernel via kexec while intel_pstate is running in the passive mode.

Can you please verify that it works as expected?
---
drivers/cpufreq/intel_pstate.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -1005,9 +1005,12 @@ static void intel_pstate_hwp_offline(str
*/
value &= ~GENMASK_ULL(31, 24);
value |= HWP_ENERGY_PERF_PREFERENCE(cpu->epp_cached);
- WRITE_ONCE(cpu->hwp_req_cached, value);
}

+ /* Clear the desired perf field in the cached HWP request value. */
+ value &= ~HWP_DESIRED_PERF(~0L);
+ WRITE_ONCE(cpu->hwp_req_cached, value);
+
value &= ~GENMASK_ULL(31, 0);
min_perf = HWP_LOWEST_PERF(READ_ONCE(cpu->hwp_cap_cached));

@@ -3002,6 +3005,27 @@ static int intel_cpufreq_cpu_exit(struct
return intel_pstate_cpu_exit(policy);
}

+static int intel_cpufreq_suspend(struct cpufreq_policy *policy)
+{
+ intel_pstate_suspend(policy);
+
+ if (hwp_active) {
+ struct cpudata *cpu = all_cpu_data[policy->cpu];
+ u64 value = READ_ONCE(cpu->hwp_req_cached);
+
+ /*
+ * Clear the desired perf field in MSR_HWP_REQUEST in case
+ * intel_cpufreq_adjust_perf() is in use and the last value
+ * written by it may not be suitable.
+ */
+ value &= ~HWP_DESIRED_PERF(~0L);
+ wrmsrl_on_cpu(cpu->cpu, MSR_HWP_REQUEST, value);
+ WRITE_ONCE(cpu->hwp_req_cached, value);
+ }
+
+ return 0;
+}
+
static struct cpufreq_driver intel_cpufreq = {
.flags = CPUFREQ_CONST_LOOPS,
.verify = intel_cpufreq_verify_policy,
@@ -3011,7 +3035,7 @@ static struct cpufreq_driver intel_cpufr
.exit = intel_cpufreq_cpu_exit,
.offline = intel_cpufreq_cpu_offline,
.online = intel_pstate_cpu_online,
- .suspend = intel_pstate_suspend,
+ .suspend = intel_cpufreq_suspend,
.resume = intel_pstate_resume,
.update_limits = intel_pstate_update_limits,
.name = "intel_cpufreq",
\
 
 \ /
  Last update: 2021-10-29 17:40    [W:0.074 / U:1.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site