|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] xen/acpi-processor: fix _CST detection using undersized evaluation buffer
On Tue, Feb 24, 2026 at 09:37:11AM +0000, David Thomson wrote:
>
> On a system with dom0_max_vcpus=2 and 8 physical CPUs, only PCPUs 0-1
> receive C-state data. PCPUs 2-7 are stuck in C0/C1 idle, unable to
> enter C2/C3. This costs measurable wall power (4W observed on an Intel
> Core Ultra 7 265K with Xen 4.20).
>
> The function never uses the _CST return value -- it only needs to know
> whether _CST exists. Replace the broken acpi_evaluate_object() call with
> acpi_has_method(), which correctly detects _CST presence using
> acpi_get_handle() without any buffer allocation. This brings C-state
> detection to parity with the P-state path, which already works correctly
> for Phase 2 CPUs.
>
> Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads
> said data to hypervisor.")
> Signed-off-by: David Thomson <dt@xxxxxxxxxxxxxx>
Tested-by: Elliott Mitchell <ehem+xen@xxxxxxx>
The window of opportunity happened and I confirmed it fixed the issue for
me. I don't know whether this already got in though.
> - status = acpi_evaluate_object(handle, "_CST", NULL, &buffer);
> - if (ACPI_FAILURE(status)) {
> - if (!pblk)
> - return AE_OK;
> - }
> + if (!pblk && !acpi_has_method(handle, "_CST"))
> + return AE_OK;
> /* .. and it has a C-state */
> __set_bit(acpi_id, acpi_id_cst_present);
I had traced the problem to this spot a while back, but I didn't know
what an appropriate change was. Since I had a workaround this wasn't
urgent. I do know this effects many others, I don't know how urgent this
bug is for everyone else.
--
(\___(\___(\______ --=> 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 |