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 <[email protected]> >> --- >> 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
