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

["Roger Pau Monné" <roger.pau@citrix.com>]

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.

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.

Thanks, Roger.