From nobody Tue Mar 3 03:25:37 2026 Received: from mail-06.mail-europe.com (mail-06.mail-europe.com [85.9.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EFE037646A for ; Mon, 23 Feb 2026 19:56:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.9.210.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771876590; cv=none; b=M/YGVI/X8+4iUN9zOuOLe4TTGpbL5n2GlREmXtrWaSYUBxSW9TkC3GO5TUrKTRrTmvT3pwAd9ogT4Jj+g4u8t8rNCsRHGjcSda2TwxnRgYOFdjvjmZagBSa54s/xukg5a1t4PzS+2SxdgwtW2v1dG0fYHmQUk6KOqQtoUDo6k7I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771876590; c=relaxed/simple; bh=FC1oBOhuZpUKRYw5lx0dBf68onwW79KH3ApPc2koKCI=; h=Date:To:From:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=iFeecWTS/k+pJVBspqtg9YbyieQ7B0q072eelxghgW0T6BZUR8iMCgp7c89T1ZZ8a8+0kJQSdCig8VqYocPOZ+f2EAXX+aXE9SqEesDrPkaGwuoq43FhxF4Z3J5y7LVp0hnDeJtOph7Yd00dbLn9FyDQ+6QBxsr5a0OiV2PqMSw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=linux-mail.net; spf=pass smtp.mailfrom=linux-mail.net; dkim=pass (2048-bit key) header.d=linux-mail.net header.i=@linux-mail.net header.b=Zyyw9Kg5; arc=none smtp.client-ip=85.9.210.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=linux-mail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux-mail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux-mail.net header.i=@linux-mail.net header.b="Zyyw9Kg5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-mail.net; s=protonmail; t=1771876572; x=1772135772; bh=FC1oBOhuZpUKRYw5lx0dBf68onwW79KH3ApPc2koKCI=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Zyyw9Kg5CFJ0af86va6+BcEVFZSXG6UvzTTKPOrW8JOIog+azGfiCBkl6IHQLApgg mi/WqF78jhHDOCYy9xd6Yz4m5+kK9RA3L70bu0hMfeb72i2S7XjnB7adJ3jV8pF141 6wT3iQ0aG6EZiesL6nx0iWTfQeP3seFpptnSJBO2Vk7fjwO0Rd7jB4RJVQxJsscZ5C gknfH26jLVXSB1ZlkZd+VfzLWSuCJ+pHdORd33hhw+p3nwwwomrLqqIEQAJvCxU83q KPniOChXjpfJhE7iz53s/icndqW90Ubc0o6c3qvD65x/3t2WhxsE4Az3g/JXVZMS8q X17DiYxypc/tA== Date: Mon, 23 Feb 2026 19:56:07 +0000 To: jgross@suse.com From: David Thomson Cc: boris.ostrovsky@oracle.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, David Thomson Subject: [PATCH] xen/acpi-processor: fix _CST detection using undersized evaluation buffer Message-ID: <20260223195602.17122-1-dt@linux-mail.net> Feedback-ID: 176297775:user:proton X-Pm-Message-ID: daf5c815bc2d790a7f192f23fabc62b9ff00444f Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=3D2 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 --- drivers/xen/xen-acpi-processor.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-proces= sor.c index 2967039..67a4afc 100644 --- a/drivers/xen/xen-acpi-processor.c +++ b/drivers/xen/xen-acpi-processor.c @@ -379,11 +379,8 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *contex= t, void **rv) acpi_psd[acpi_id].domain); } =20 - status =3D acpi_evaluate_object(handle, "_CST", NULL, &buffer); - if (ACPI_FAILURE(status)) { - if (!pblk) - return AE_OK; - } + if (!acpi_has_method(handle, "_CST") && !pblk) + return AE_OK; /* .. and it has a C-state */ __set_bit(acpi_id, acpi_id_cst_present); =20 --=20 2.34.1