From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-08.mail-europe.com (mail-08.mail-europe.com [57.129.93.249]) (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 54621369988 for ; Tue, 24 Feb 2026 09:37:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=57.129.93.249 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771925850; cv=none; b=cFuZyFMllyUIhhmoqYX3Ekm/CBUTUDboyu9kAYb2980MstJZtMlxu3aZxGLc5hU83XfdLCIN29gDjhDcRgCttGDjnAYmuAIoCAf6OvwDD/f4/8eRvQAxxCawLZUp/FlGqEjpAtL7PBDBsb1J8cvgI1DyKbd8QoEa48X9xYm73oA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771925850; c=relaxed/simple; bh=hafCjbL+NxP/5iAfBi6UdIDCLlM5EPk5c2RnWupYogw=; h=Date:To:From:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=jKlXTgSrVBrLwVCM8f09Y0RAd2RmH+Ak426vYyqlUVITtVLjb0d4Uy/Zq5RkoXYrJODYqNTwK589qIRn/5ztVIzhov8bI7XnBiudgP+cWv//djUOoan+qeLn+35dv+rvDjLPTNQeRHU9hYviKfqeYylgQkAtspvEW4l/wE5xSbk= 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=PdbCfxjg; arc=none smtp.client-ip=57.129.93.249 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="PdbCfxjg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-mail.net; s=protonmail; t=1771925836; x=1772185036; bh=r2rda/g/vi5GF2WIAeDs3b+9hmolyVwJOyarSdmFE8g=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=PdbCfxjgi4SN+YiE7S7My63gVIe+v7WfKxKYiVcHAJn1xeEhgc51bgJw5IKRv+Bw1 lDQbJDgT0bVu/pleb1j+Shb53j22elBWGu31j2wz5WZL530qDOHK+RQp6BMB1i8K4C YbRoMzpzRiTMPGu2DFXOLccv0Nld/ILIuVIBJ7pNlzzQKfR1rMjuAng5wAlofSTUP8 3TljrwVbQa0vurfh2Kkrg/9d9RzTb1t9EfhEUSWSEYFTV7pqdOS/IJiMt9Dywu8MFm IJF52z60NgxooMKNSUoQaY0VUWOt7/EAfJsrxrFQGy6R0KB79/JqCs3z+r+IaVK1xE XAHCtI8O4pv4g== Date: Tue, 24 Feb 2026 09:37:11 +0000 To: jgross@suse.com From: David Thomson Cc: boris.ostrovsky@oracle.com, olekstysh@gmail.com, tglx@linutronix.de, jbeulich@suse.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, David Thomson Subject: [PATCH v2] xen/acpi-processor: fix _CST detection using undersized evaluation buffer Message-ID: <20260224093707.19679-1-dt@linux-mail.net> Feedback-ID: 176297775:user:proton X-Pm-Message-ID: 6d863196dc75b80c244bf456ca669156f4bdc168 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 --- Changes in v2: - Check pblk first to avoid unnecessary acpi_has_method() call when pblk is zero (Jan Beulich) 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) =09=09=09 acpi_psd[acpi_id].domain); =09} -=09status =3D acpi_evaluate_object(handle, "_CST", NULL, &buffer); -=09if (ACPI_FAILURE(status)) { -=09=09if (!pblk) -=09=09=09return AE_OK; -=09} +=09if (!pblk && !acpi_has_method(handle, "_CST")) +=09=09return AE_OK; =09/* .. and it has a C-state */ =09__set_bit(acpi_id, acpi_id_cst_present); -- 2.34.1