linux-kernel - Re: [PATCH v3 01/18] cpufreq/amd-pstate: Invalidate cppc_req

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2644833f-0cf7-4537-ac3a-45ddf1a8f5e7@amd.com>
Date: Wed, 19 Feb 2025 12:07:59 +0530
From: Dhananjay Ugwekar <Dhananjay.Ugwekar@....com>
To: Mario Limonciello <superm1@...nel.org>,
 "Gautham R . Shenoy" <gautham.shenoy@....com>,
 Perry Yuan <perry.yuan@....com>
Cc: "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
 <linux-kernel@...r.kernel.org>,
 "open list:CPU FREQUENCY SCALING FRAMEWORK" <linux-pm@...r.kernel.org>,
 Mario Limonciello <mario.limonciello@....com>,
 Miroslav Pavleski <miroslav@...leski.net>
Subject: Re: [PATCH v3 01/18] cpufreq/amd-pstate: Invalidate cppc_req_cached
 during suspend

On 2/19/2025 11:42 AM, Dhananjay Ugwekar wrote:
> On 2/18/2025 3:36 AM, Mario Limonciello wrote:
>> From: Mario Limonciello <mario.limonciello@....com>
>>
>> During resume it's possible the firmware didn't restore the CPPC request MSR
>> but the kernel thinks the values line up. This leads to incorrect performance
>> after resume from suspend.
>>
>> To fix the issue invalidate the cached value at suspend. During resume use
>> the saved values programmed as cached limits.
>>
>> Reported-by: Miroslav Pavleski <miroslav@...leski.net>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217931
>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>> ---
>>  drivers/cpufreq/amd-pstate.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
>> index f425fb7ec77d7..12fb63169a24c 100644
>> --- a/drivers/cpufreq/amd-pstate.c
>> +++ b/drivers/cpufreq/amd-pstate.c
>> @@ -1611,7 +1611,7 @@ static int amd_pstate_epp_reenable(struct cpufreq_policy *policy)
>>  					  max_perf, policy->boost_enabled);
>>  	}
>>  
>> -	return amd_pstate_update_perf(cpudata, 0, 0, max_perf, cpudata->epp_cached, false);
>> +	return amd_pstate_epp_update_limit(policy);
> 
> Can we also add the check "if (policy->min != cpudata->min_limit_freq || policy->max != cpudata->max_limit_freq)"
> in "amd_pstate_epp_update_limit()" before calling "amd_pstate_update_min_max_limit()". I think it would help in 
> avoiding some unnecessary calls to the update_min_max_limit() function.

You can ignore this, I see that you have handled it in the 3rd patch.

Reviewed-by: Dhananjay Ugwekar <dhananjay.ugwekar@....com>

> 
> Patch looks good to me otherwise.
> 
> Thanks,
> Dhananjay
> 
>>  }
>>  
>>  static int amd_pstate_epp_cpu_online(struct cpufreq_policy *policy)
>> @@ -1660,6 +1660,9 @@ static int amd_pstate_epp_suspend(struct cpufreq_policy *policy)
>>  	if (cppc_state != AMD_PSTATE_ACTIVE)
>>  		return 0;
>>  
>> +	/* invalidate to ensure it's rewritten during resume */
>> +	cpudata->cppc_req_cached = 0;
>> +
>>  	/* set this flag to avoid setting core offline*/
>>  	cpudata->suspended = true;
>>  
>