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); }