On 26.01.2026 21:17, Jason Andryuk wrote: > 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: >>>> --- 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.
Maybe we should see about lifting that restriction then? Becoming independent of Dom0's xen-acpi-processor driver would be quite a meaningful gain, I suppose. See e.g. the thread rooted at https://lists.xen.org/archives/html/xen-devel/2025-12/msg01114.html. > 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. Jan
