[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240530192739.172566-3-chang.seok.bae@intel.com>
Date: Thu, 30 May 2024 12:27:38 -0700
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: linux-kernel@...r.kernel.org
Cc: x86@...nel.org,
platform-driver-x86@...r.kernel.org,
tglx@...utronix.de,
mingo@...hat.com,
bp@...en8.de,
dave.hansen@...ux.intel.com,
hdegoede@...hat.com,
ilpo.jarvinen@...ux.intel.com,
tony.luck@...el.com,
ashok.raj@...el.com,
jithu.joseph@...el.com,
sathyanarayanan.kuppuswamy@...ux.intel.com,
chang.seok.bae@...el.com
Subject: [PATCH v3 2/3] x86/fpu: Allow FPU users to initialize FPU state
The In-Field Scan (IFS) test [1] is a destructive process that overwrites
the existing state to test the logic on the fly. As part of this test,
the architectural state should be saved before the test begins and then
restored upon completion.
Unfortunately, AMX state is excluded from the scope of state recovery.
This exclusion prohibits the IFS process from supporting any software
context when running the test. The kernel generally runs with live user
FPU states, including AMX.
Provide fpu_reset_fpregs() for the IFS driver to reset FPU states, which
is much simpler than specifying state components and is affordable in the
non-critical path. This, along with kernel_fpu_begin(), can allow the IFS
test to proceed.
Alternatively, system administrators may attempt to mitigate this IFS
issue by arranging some workloads not to run on CPUs selected for the
tests. But, this approach is disruptive for managing large-scaled
systems.
[1]: https://docs.kernel.org/arch/x86/ifs.html
Suggested-by: Dave Hansen <dave.hansen@...ux.intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@...el.com>
---
V2 -> V3: Switch to a simpler solution and clarify the hardware
problem (Dave Hansen).
V1 -> V2: Revise the changelog (Dave and Ashok)
The IFS Tech Paper [2] elaborates its purpose and the requirements of the
context restoration after the scan test. Additionally, the necessity for
AMX initialization is emphasized in the Intel Software Development Manual
as of March 2024, in Section 18.2 of Vol.1.
[2]: https://www.intel.com/content/www/us/en/content-details/822279/finding-faulty-components-in-a-live-fleet-environment.html
---
arch/x86/include/asm/fpu/api.h | 2 ++
arch/x86/kernel/fpu/core.c | 11 +++++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h
index f86ad3335529..284304171003 100644
--- a/arch/x86/include/asm/fpu/api.h
+++ b/arch/x86/include/asm/fpu/api.h
@@ -179,4 +179,6 @@ extern long fpu_xstate_prctl(int option, unsigned long arg2);
extern void fpu_idle_fpregs(void);
+extern void fpu_reset_fpregs(void);
+
#endif /* _ASM_X86_FPU_API_H */
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 2e6f43dfe98b..51d7689147f4 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -915,3 +915,14 @@ noinstr void fpu_idle_fpregs(void)
__this_cpu_write(fpu_fpregs_owner_ctx, NULL);
}
}
+
+/*
+ * Allow FPU users to initialize the entire user FPU register state. The
+ * caller must invoke kernel_fpu_begin() beforehand.
+ */
+void fpu_reset_fpregs(void)
+{
+ WARN_ON_FPU(!this_cpu_read(in_kernel_fpu));
+ restore_fpregs_from_fpstate(&init_fpstate, XFEATURE_MASK_USER_SUPPORTED);
+}
+EXPORT_SYMBOL_GPL(fpu_reset_fpregs);
--
2.34.1
Powered by blists - more mailing lists