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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Mar 05, 2026 at 01:40:23PM +0100, Jan Beulich wrote:
> 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 ...

Possibly, I'm just a bit hesitant because I'm unsure about what CPPC
requires to be set in the _PDC.  Right now we would allow any
P-related bits set by dom0 to be propagated into _PDC when using CPPC
driver.  With this change we would mask any P-related bits from _PDC
when using CPPC.

I think this is likely fine, but would like to get confirmation from
AMD.  Maybe I'm overthinking it.

Penny, Jason, Alejandro, Stefano: do you know which/if there's any
_PDC/_OSC bits defined on AMD Processor Objects, or is it just
supposed to be always empty?  It would be good to get some
clarification there about which bits if any are supposed to be
meaningful when using CPPC.

Also, on a related tangent, \_SB._OSC seems to also define some
vendor-agnostic bits related to CPPC [0].  Should the CPPC cpufreq
driver force any of those to be set?  "CPPC {2} Support" bits seem
like they should be set when Xen is using the CPPC cpufreq driver?

Thanks, Roger.

[0] 
https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration.html#osc-operating-system-capabilities