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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.03.2026 13:30, Roger Pau Monné wrote:
> On Thu, Mar 05, 2026 at 12:39:51PM +0100, Jan Beulich wrote:
>> 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.
> 
> I'm afraid it's the other way around, you need to first call _PDC, and
> then fetch the data.  As I've learned the hard way while doing the
> FreeBSD driver: you must call _PDC before attempting to fetch the
> data, as ACPI will modulate what gets returned/is present on the
> Processor objects based on what support the OSPM has specified in the
> _PDC bits.

In which case at least for Linux we're okay, as what we need it has always
been capable of parsing.

> Anyway, not sure there's much we can do now about any of this, it's
> too late to change the interface, and what we have seems to kind of
> work on for the purpose.

Which reads almost(?) like an ack-in-disguise to me ...

Jan