Re: [PATCH v2] xen/acpi-processor: fix _CST detection using undersized evaluation buffer

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.02.2026 10:37, David Thomson wrote:
> read_acpi_id() attempts to evaluate _CST using a stack buffer of
> sizeof(union acpi_object) (48 bytes), but _CST returns a nested Package
> of sub-Packages (one per C-state, each containing a register descriptor,
> type, latency, and power) requiring hundreds of bytes. The evaluation
> always fails with AE_BUFFER_OVERFLOW.
> 
> On modern systems using FFH/MWAIT entry (where pblk is zero), this
> causes the function to return before setting the acpi_id_cst_present
> bit. In check_acpi_ids(), flags.power is then zero for all Phase 2 CPUs
> (physical CPUs beyond dom0's vCPU count), so push_cxx_to_hypervisor() is
> never called for them.
> 
> 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>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>