On 2026-01-26 04:08, Jan Beulich wrote:
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.
Thank you.
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.
HWP doesn't need ACPI data. I wrote the driver according to the SDM,
which is just MSRs. It's Xen that needs ACPI data to initialize and use
cpufreq.
Regardless of that, it looks like the checks for cpu_online() and
performance_pminfo[] would constrain CPU accesses, so:
Reviewed-by: Jason Andryuk <[email protected]>
Thanks,
Jason
