Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.03.2026 11:17, Roger Pau Monné wrote:
> On Thu, Mar 05, 2026 at 10:20:02AM +0100, Jan Beulich wrote:
>> On 05.03.2026 09:50, Roger Pau Monné wrote:
>>> Since we have the parsing of the ACPI related data done from dom0 it's
>>> not only Xen that needs to support the feature, but dom0 also needs to
>>> know how to parse it.  Or we just assume the driver in dom0 must
>>> strictly know how to parse data from the features enabled by Xen.
>>>
>>> Maybe Xen supported bits should be & with the dom0 ones?  So dom0
>>> would set what it can parse, and Xen would AND that with what the
>>> cpufreq drivers support?  However that would be an ABI change.
>>
>> What cpufreq drivers are you talking about here?
> 
> I was talking about the Xen cpufreq driver, sorry the context was
> confusing.
> 
>> When Xen handles P-
>> state transitions, the drivers in Dom0 would preferably not even be
>> loaded. That's what the forward-port did. Upstream they may be loaded,
>> but they then can't actually do anything (and they may exit early).
> 
> Well, yes, on FreeBSD I simply overtake the native ACPI Processor
> driver with a Xen specific one that has higher priority.  So the
> native ACPI Processor driver doesn't even attach.  I think Linux is
> slightly different in that it allows the native driver to do the
> fetching of the information, and then the Xen driver only does the
> uploading.
> 
>> Coordination is necessary only with the ACPI driver(s), and that's what
>> this function is about.
> 
> I think Xen also needs coordination with the driver in dom0 that
> fetches the information from ACPI?

That's what I meant with "ACPI driver(s)".

>  It's not only Xen that needs to
> report what the cpufreq driver support, but also dom0 would need to
> expose what it can correctly parse.

Hmm, yes, strictly speaking we should tie setting of respective bits to
Dom0 having uploaded corresponding data. The order of these operations
may, however, be at best undefined (and possibly be well defined in the
unhelpful - for us - order). I don't think I see anything we can do
about this.

Jan