From patchwork Tue Oct 4 03:35:47 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Lane X-Patchwork-Id: 1685753 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=QQTj9udr; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4MhNfR123zz23jT for ; Tue, 4 Oct 2022 14:36:29 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ofYj8-0001Z0-4h; Tue, 04 Oct 2022 03:36:14 +0000 Received: from smtp-relay-canonical-0.internal ([10.131.114.83] helo=smtp-relay-canonical-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1ofYj6-0001Yk-0f for kernel-team@lists.ubuntu.com; Tue, 04 Oct 2022 03:36:12 +0000 Received: from localhost.localdomain (1.general.jlane.us.vpn [10.172.64.160]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id D8C673F158 for ; Tue, 4 Oct 2022 03:36:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1664854571; bh=qUeBWTI4h0FGA83Z5Sn+tLvDcty42c960qCTkFnK8CU=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=QQTj9udrtmAlVtOTKbHIXaAgADIxh9D1nf5xC3wYI04u0L8m09Uw0uNZSNhc2xDJh oz6xCVQ2Il4dNs/KNFxk9K0YPkMjq03wQ8JKnS4DCl5e5zwyxZFmM4v7Xs2n9b7V0X zq/t58FLukqO/OAD9KpxHFF49dusoYOMeflUAkYdk/GTxyLKF9/OQPD3o0nw9g07or bXMo8JCNEZ816OfXUN2sGiykAA4dLDWchdakq7nbQFNwwfD8Mc+aNuUHGrrE8PbY9Q lgmrmMu/8e0YrXUDbCTmFkDF/RvZLoBWu4K2Y98WhumWrJ9miIQPvH6TjTOZQFCad5 /2HtSv7VOpBrg== From: Jeff Lane To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/2] ACPI: processor_idle: Skip dummy wait if kernel is in guest Date: Mon, 3 Oct 2022 23:35:47 -0400 Message-Id: <20221004033548.2508712-2-jeffrey.lane@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221004033548.2508712-1-jeffrey.lane@canonical.com> References: <20221004033548.2508712-1-jeffrey.lane@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Yin Fengwei BugLink: https://bugs.launchpad.net/bugs/1990985 In function acpi_idle_do_entry(), an ioport access is used for dummy wait to guarantee hardware behavior. But it could trigger unnecessary VMexit if kernel is running as guest in virtualization environment. If it's in virtualization environment, the deeper C state enter operation (inb()) will trap to hypervisor. It's not needed to do dummy wait after the inb() call. So we could just remove the dummy io port access to avoid unnecessary VMexit. And keep dummy io port access to maintain timing for native environment. Signed-off-by: Yin Fengwei Signed-off-by: Rafael J. Wysocki (cherry picked from commit fa583f71a99c85e52781ed877c82c8757437b680) Signed-off-by: Jeff Lane --- drivers/acpi/processor_idle.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index 0ea5e677f00e..a1f982a6f882 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -682,6 +682,19 @@ static int acpi_idle_bm_check(void) return bm_status; } +static void wait_for_freeze(void) +{ +#ifdef CONFIG_X86 + /* No delay is needed if we are in guest */ + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + return; +#endif + /* Dummy wait op - must do something useless after P_LVL2 read + because chipsets cannot guarantee that STPCLK# signal + gets asserted in time to freeze execution properly. */ + inl(acpi_gbl_FADT.xpm_timer_block.address); +} + /** * acpi_idle_do_entry - enter idle state using the appropriate method * @cx: cstate data @@ -698,10 +711,7 @@ static void __cpuidle acpi_idle_do_entry(struct acpi_processor_cx *cx) } else { /* IO port based C-state */ inb(cx->address); - /* Dummy wait op - must do something useless after P_LVL2 read - because chipsets cannot guarantee that STPCLK# signal - gets asserted in time to freeze execution properly. */ - inl(acpi_gbl_FADT.xpm_timer_block.address); + wait_for_freeze(); } } @@ -722,8 +732,7 @@ static int acpi_idle_play_dead(struct cpuidle_device *dev, int index) safe_halt(); else if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) { inb(cx->address); - /* See comment in acpi_idle_do_entry() */ - inl(acpi_gbl_FADT.xpm_timer_block.address); + wait_for_freeze(); } else return -ENODEV; } From patchwork Tue Oct 4 03:35:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Lane X-Patchwork-Id: 1685755 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=AI6Fuq0l; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4MhNfR0B9pz1yqn for ; Tue, 4 Oct 2022 14:36:29 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1ofYjB-0001a2-Ac; Tue, 04 Oct 2022 03:36:17 +0000 Received: from smtp-relay-canonical-0.internal ([10.131.114.83] helo=smtp-relay-canonical-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1ofYj9-0001Zh-LM for kernel-team@lists.ubuntu.com; Tue, 04 Oct 2022 03:36:15 +0000 Received: from localhost.localdomain (1.general.jlane.us.vpn [10.172.64.160]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-0.canonical.com (Postfix) with ESMTPSA id 589033F158 for ; Tue, 4 Oct 2022 03:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1664854575; bh=xSYzi4oTER5UCOdi2AUGFbbV6nx3Il8TIPFMZgicrlw=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=AI6Fuq0lewMF4J0QuW1HJQG5WRgwT+20pGxJJSbDgcsXVjUF+JnhcS16yuSThVLJZ Enf2SmO40Os2jLbnx8lRl+xAwhvNoOxC27dK41lzSclgkVd1KwguiZdTWLve9x2FDO zEmvJCwoVLznP8fwFk8LeTWJA9jh9SQLPP1i2WyXQWozYzaJFVUqHroRZ+O4HQiOIA 5AwiXUseLzOuP0A6uRRZ3ccNK4lltUvGKBAPC8ipk185WKa9CR8eOcWy7+VTSiQx95 hTVDaGSTE/rkgHEc3YvHqea4uHkvvsGiLXQ4WrKPUbCi3CtuuBUhdWpaN0p+024shw c5/SAhEnlNxog== From: Jeff Lane To: kernel-team@lists.ubuntu.com Subject: [PATCH 2/2] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems Date: Mon, 3 Oct 2022 23:35:48 -0400 Message-Id: <20221004033548.2508712-3-jeffrey.lane@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221004033548.2508712-1-jeffrey.lane@canonical.com> References: <20221004033548.2508712-1-jeffrey.lane@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Dave Hansen BugLink: https://bugs.launchpad.net/bugs/1990985 Old, circa 2002 chipsets have a bug: they don't go idle when they are supposed to. So, a workaround was added to slow the CPU down and ensure that the CPU waits a bit for the chipset to actually go idle. This workaround is ancient and has been in place in some form since the original kernel ACPI implementation. But, this workaround is very painful on modern systems. The "inl()" can take thousands of cycles (see Link: for some more detailed numbers and some fun kernel archaeology). First and foremost, modern systems should not be using this code. Typical Intel systems have not used it in over a decade because it is horribly inferior to MWAIT-based idle. Despite this, people do seem to be tripping over this workaround on AMD system today. Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD systems from tripping over the workaround. Remotely modern Intel systems use intel_idle instead of this code and will, in practice, remain unaffected by the dummy wait. Reported-by: K Prateek Nayak Suggested-by: Rafael J. Wysocki Signed-off-by: Dave Hansen Reviewed-by: Mario Limonciello Tested-by: K Prateek Nayak Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/ Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com (cherry picked from commit e400ad8b7e6a1b9102123c6240289a811501f7d9) Signed-off-by: Jeff Lane --- drivers/acpi/processor_idle.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index a1f982a6f882..ea22e14fae58 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -688,10 +688,27 @@ static void wait_for_freeze(void) /* No delay is needed if we are in guest */ if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) return; + /* + * Modern (>=Nehalem) Intel systems use ACPI via intel_idle, + * not this code. Assume that any Intel systems using this + * are ancient and may need the dummy wait. This also assumes + * that the motivating chipset issue was Intel-only. + */ + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) + return; #endif - /* Dummy wait op - must do something useless after P_LVL2 read - because chipsets cannot guarantee that STPCLK# signal - gets asserted in time to freeze execution properly. */ + /* + * Dummy wait op - must do something useless after P_LVL2 read + * because chipsets cannot guarantee that STPCLK# signal gets + * asserted in time to freeze execution properly + * + * This workaround has been in place since the original ACPI + * implementation was merged, circa 2002. + * + * If a profile is pointing to this instruction, please first + * consider moving your system to a more modern idle + * mechanism. + */ inl(acpi_gbl_FADT.xpm_timer_block.address); }