[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 1/5] xen/acpi: upload power and performance related data from a PVH dom0
On Thu, Mar 06, 2025 at 07:08:20PM +0800, Penny Zheng wrote: > From: Roger Pau Monne <roger.pau@xxxxxxxxxx> > > When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to > report the correct numbers of vCPUs that dom0 has, so the host MADT is > not provided to dom0. This creates issues when parsing the power and > performance related data from ACPI dynamic tables, as the ACPI > Processor UIDs found on the dynamic code are likely to not match the > ones crafted by Xen in the dom0 MADT. > > Xen would rely on Linux having filled at least the power and > performance related data of the vCPUs on the system, and would clone > that information in order to setup the remaining pCPUs on the system > if dom0 vCPUs < pCPUs. However when running as PVH dom0 it's likely > that none of dom0 CPUs will have the power and performance data > filled, and hence the Xen ACPI Processor driver needs to fetch that > information by itself. > > In order to do so correctly, introduce a new helper to fetch the _CST > data without taking into account the system capabilities from the > CPUID output, as the capabilities reported to dom0 in CPUID might be > different from the ones on the host. > > Note that the newly introduced code will only fetch the _CST, _PSS, > _PPC and _PCT from a single CPU, and clone that information for all the > other Processors. This won't work on an heterogeneous system with > Processors having different power and performance related data between > them. I'm unsure whether the above description is inaccurate versus what I've seen being a distinct issue. This also effects PV domain 0 and isn't limited to AMD processors. In particular if domain 0 is PV, C-states will only be uploaded for processors which domain 0 has a corresponding vCPU. xen-acpi-processor uploads C/P-states in two passes. The first pass being for processors which domain 0 has a vCPU. The second pass being for all physical processors. In a PV domain 0, xen-acpi-processor is unable to upload C-states during the second pass. Snippet from pass 1: xen_acpi_processor: ACPI CPU0 - C-states uploaded. xen_acpi_processor: C1: ACPI HLT 1 uS xen_acpi_processor: C2: ACPI IOPORT 0x414 18 uS xen_acpi_processor: C3: ACPI IOPORT 0x415 350 uS xen_acpi_processor: ACPI CPU0 - P-states uploaded. xen_acpi_processor: *P0: 4500 MHz, 5625 mW, 0 uS xen_acpi_processor: P1: 3000 MHz, 2550 mW, 0 uS xen_acpi_processor: ACPI CPU2 - C-states uploaded. xen_acpi_processor: C1: ACPI HLT 1 uS xen_acpi_processor: C2: ACPI IOPORT 0x414 18 uS xen_acpi_processor: C3: ACPI IOPORT 0x415 350 uS xen_acpi_processor: ACPI CPU2 - P-states uploaded. xen_acpi_processor: *P0: 4500 MHz, 5625 mW, 0 uS xen_acpi_processor: P1: 3000 MHz, 2550 mW, 0 uS Intermediate: xen_acpi_processor: ACPI CPU0 w/ PBLK:0x0 xen_acpi_processor: ACPI CPU0 w/ PST:coord_type = 254 domain = 0 xen_acpi_processor: ACPI CPU1 w/ PBLK:0x0 xen_acpi_processor: ACPI CPU1 w/ PST:coord_type = 254 domain = 0 xen_acpi_processor: ACPI CPU2 w/ PBLK:0x0 xen_acpi_processor: ACPI CPU2 w/ PST:coord_type = 254 domain = 1 xen_acpi_processor: ACPI CPU3 w/ PBLK:0x0 xen_acpi_processor: ACPI CPU3 w/ PST:coord_type = 254 domain = 1 Snippet from pass 2: xen_acpi_processor: ACPI CPU1 - P-states uploaded. xen_acpi_processor: *P0: 4500 MHz, 5625 mW, 0 uS xen_acpi_processor: P1: 3000 MHz, 2550 mW, 0 uS xen_acpi_processor: ACPI CPU3 - P-states uploaded. xen_acpi_processor: *P0: 4500 MHz, 5625 mW, 0 uS xen_acpi_processor: P1: 3000 MHz, 2550 mW, 0 uS Come to think of it, I've been wondering about the mapping between Xen CPU numbers and ACPI CPU numbers... -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@xxxxxxx PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |