Re: [PATCH 2/5] cpufreq/hwp: move driver data into policy

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.01.2026 23:35, Jason Andryuk wrote:
> On 2026-01-22 04:42, Jan Beulich wrote:
>> Share space with the ACPI and powernow drivers, avoiding a separate
>> allocation for each CPU. Except for get_hwp_para() all use sites already
>> have the policy available, and this one function can simply be brought
>> closer to its sibling set_hwp_para().
> 
> Minor, but maybe 's/function/function's signature/'.  The original 
> phrasing made me think it was code movement.

I don't see an issue there, but I've adjusted as you asked for.

>> This then also eliminates the concern over hwp_cpufreq_cpu_init() being
>> called for all CPUs
> 
> We expect hwp_cpufreq_cpu_init() to be called for each CPU, so I am 
> confused by this statement.  The data...

Well, "expect" is the problem. Recall my pointing out of the problem when
having noticed the same pattern in the amd-cppc driver patches. My
recollection from the discussion is that there's no formal statement of
...

>  >, or a CPU going offline that's recorded in> policy->cpu (which would 
> result in accesses of per-CPU data of offline
>> CPUs).
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> hwp_cpufreq_target() still requires policy->cpu to be online, though.
>>
>> --- a/xen/arch/x86/acpi/cpufreq/hwp.c
>> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c
> 
>> -static DEFINE_PER_CPU_READ_MOSTLY(struct hwp_drv_data *, hwp_drv_data);
> 
> ... here is tracked and filled per-CPU.
> 
> Do we need cpufreq_add_cpu() to force hw_all = 1 for HWP (and maybe 
> AMD-CPPC) to ensure that policy is allocated per-CPU?

... this being a correct thing to do, hence our code imo would better be
resilient to it being different somewhere.

> Are we implicitly relying on shared_type == CPUFREQ_SHARED_TYPE_HW to do 
> that for us?

Right now we do, I believe, without - as said above - this being actually
mandated by the spec.

Jan