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
