From nobody Fri May 9 17:02:18 2025
Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55])
(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 97A8120E703;
Tue, 1 Apr 2025 20:42:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=193.142.43.55
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1743540122; cv=none;
b=rNH+N3M9PTI5gnyHbq1b+Mjjq4Peo5hLTtquhysyx5JC/X06eVp9kS5U7hVuGhHwi9/t26ZiU9qZIfVP+jphtua5uXMxYVAZHAb+GWkLnKCihDLwYIuMNItszI0XpopQJ1zX7lWDLh0Zn1zbnwVZrRUFqEz+OYq6NbmiM4z/JnQ=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1743540122; c=relaxed/simple;
bh=xacZ7hZtYM3xExL/0rXDeFSSRlJ4oJDev80Ooo0au5Y=;
h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version:
Message-ID:Content-Type;
b=RsOn4ZWxOeF1D8mpxqrt0LUj/l+AD4ebWj6Yp8KXpxtPPt/H7imX2aIkkYN+I7uNhMXG4D1BgMA6DX0F+DCpVue8/q/N9wyJKC9yc4frpLHrnB3sYFAlkeg+wjKCDZFE6WAMOHFzmJkbJhqoJ/kP4miVzwTR9pz00mGEVhmyYXc=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=linutronix.de;
spf=pass smtp.mailfrom=linutronix.de;
dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de
header.b=utWRd+Jg;
dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de
header.b=8hI0iQCM; arc=none smtp.client-ip=193.142.43.55
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=linutronix.de
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=linutronix.de
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de
header.b="utWRd+Jg";
dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de
header.b="8hI0iQCM"
Date: Tue, 01 Apr 2025 20:41:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de;
s=2020; t=1743540118;
h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:cc:mime-version:mime-version:
content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=qkuxa8N+ex+n4KSwAdPbU67ZNUHIS3synVFOdTrpslk=;
b=utWRd+Jgt7/ZXzvpp0PKE297VptOTyaMeyOJhpxIKUZ5dCi3QsMfMOG9hE0BibCpWUnTPw
3ea+5ZjVWxNMyq/KmkxbiFllVF9xAPcF1LGlVZQAVgREVjgNGHUJC6WVhZyrmGUuIiWvLy
XxRYNhebL6qGag8ZQGkMmFK/teNGLEYu15kNE4n30o4lPhOGtL4xfy8uZezPUbNWVmeYOk
PjAVeZCH1KFODFwMT2CerN70KPUT08gMq7Fu0H4IUK/tOKACIA2wnC6xHmUd49XkhI80bh
F2eV9v9iEVrc6u0OXyiBm0buoB/pwHHEI3/GLKKHQkFBaQR3ePenFX6H19eXkg==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de;
s=2020e; t=1743540118;
h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:cc:mime-version:mime-version:
content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=qkuxa8N+ex+n4KSwAdPbU67ZNUHIS3synVFOdTrpslk=;
b=8hI0iQCMThODuso15FJ23P3QFnD6Nt8lhxuD5uF1GX0nqbkyfG12dDOUZShmj49olGBtFT
aABxfMVFeF50nhDA==
From: "tip-bot2 for Xin Li (Intel)" <tip-bot2@linutronix.de>
Sender: tip-bot2@linutronix.de
Reply-to: linux-kernel@vger.kernel.org
To: linux-tip-commits@vger.kernel.org
Subject: [tip: x86/urgent] x86/fred: Fix system hang during S4 resume with
FRED enabled
Cc: Xi Pardee <xi.pardee@intel.com>, Todd Brandt <todd.e.brandt@intel.com>,
"H. Peter Anvin (Intel)" <hpa@zytor.com>, "Xin Li (Intel)" <xin@zytor.com>,
Ingo Molnar <mingo@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Andy Lutomirski <luto@kernel.org>, Brian Gerst <brgerst@gmail.com>,
Juergen Gross <jgross@suse.com>,
Linus Torvalds <torvalds@linux-foundation.org>, x86@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20250401075728.3626147-1-xin@zytor.com>
References: <20250401075728.3626147-1-xin@zytor.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Message-ID: <174354011306.14745.425964936388256045.tip-bot2@tip-bot2>
Robot-ID: <tip-bot2@linutronix.de>
Robot-Unsubscribe:
Contact <mailto:tglx@linutronix.de> to get blacklisted from these emails
Precedence: bulk
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e5f1e8af9c9e151ecd665f6d2e36fb25fec3b110
Gitweb: https://git.kernel.org/tip/e5f1e8af9c9e151ecd665f6d2e36fb25f=
ec3b110
Author: Xin Li (Intel) <xin@zytor.com>
AuthorDate: Tue, 01 Apr 2025 00:57:27 -07:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Tue, 01 Apr 2025 22:29:02 +02:00
x86/fred: Fix system hang during S4 resume with FRED enabled
Upon a wakeup from S4, the restore kernel starts and initializes the
FRED MSRs as needed from its perspective. It then loads a hibernation
image, including the image kernel, and attempts to load image pages
directly into their original page frames used before hibernation unless
those frames are currently in use. Once all pages are moved to their
original locations, it jumps to a "trampoline" page in the image kernel.
At this point, the image kernel takes control, but the FRED MSRs still
contain values set by the restore kernel, which may differ from those
set by the image kernel before hibernation. Therefore, the image kernel
must ensure the FRED MSRs have the same values as before hibernation.
Since these values depend only on the location of the kernel text and
data, they can be recomputed from scratch.
Reported-by: Xi Pardee <xi.pardee@intel.com>
Reported-by: Todd Brandt <todd.e.brandt@intel.com>
Tested-by: Todd Brandt <todd.e.brandt@intel.com>
Suggested-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Xin Li (Intel) <xin@zytor.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250401075728.3626147-1-xin@zytor.com
---
arch/x86/power/cpu.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 63230ff..08e76a5 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -27,6 +27,7 @@
#include <asm/mmu_context.h>
#include <asm/cpu_device_id.h>
#include <asm/microcode.h>
+#include <asm/fred.h>
=20
#ifdef CONFIG_X86_32
__visible unsigned long saved_context_ebx;
@@ -231,6 +232,19 @@ static void notrace __restore_processor_state(struct s=
aved_context *ctxt)
*/
#ifdef CONFIG_X86_64
wrmsrl(MSR_GS_BASE, ctxt->kernelmode_gs_base);
+
+ /*
+ * Reinitialize FRED to ensure the FRED MSRs contain the same values
+ * as before hibernation.
+ *
+ * Note, the setup of FRED RSPs requires access to percpu data
+ * structures. Therefore, FRED reinitialization can only occur after
+ * the percpu access pointer (i.e., MSR_GS_BASE) is restored.
+ */
+ if (ctxt->cr4 & X86_CR4_FRED) {
+ cpu_init_fred_exceptions();
+ cpu_init_fred_rsps();
+ }
#else
loadsegment(fs, __KERNEL_PERCPU);
#endif