On Wed, Mar 26, 2025 at 7:26 AM Xin Li (Intel) xin@zytor.com wrote:
During an S4 resume, the system first performs a cold power-on. The kernel image is initially loaded to a random linear address, and the FRED MSRs are initialized. Subsequently, the S4 image is loaded, and the kernel image is relocated to its original address from before the S4 suspend. Due to changes in the kernel text and data mappings, the FRED MSRs must be reinitialized.
To be precise, the above description of the hibernation control flow doesn't exactly match the code.
Yes, a new kernel is booted upon a wakeup from S4, but this is not "a cold power-on", strictly speaking. This kernel is often referred to as the restore kernel and yes, it initializes the FRED MSRs as appropriate from its perspective.
Yes, it loads a hibernation image, including the kernel that was running before hibernation, often referred to as the image kernel, but it does its best to load image pages directly into the page frames occupied by them before hibernation unless those page frames are currently in use. In that case, the given image pages are loaded into currently free page frames, but they may or may not be part of the image kernel (they may as well belong to user space processes that were running before hibernation). Yes, all of these pages need to be moved to their original locations before the last step of restore, which is a jump into a "trampoline" page in the image kernel, but this is sort of irrelevant to the issue at hand.
At this point, the image kernel has control, but the FRED MSRs still contain values written to them by the restore kernel and there is no guarantee that those values are the same as the ones written into them by the image kernel before hibernation. Thus the image kernel must ensure that the values of the FRED MSRs will be the same as they were before hibernation, and because they only depend on the location of the kernel text and data, they may as well be recomputed from scratch.
Reported-by: Xi Pardee xi.pardee@intel.com Reported-and-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 Cc: stable@kernel.org # 6.9+
arch/x86/power/cpu.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c index 63230ff8cf4f..ef3c152c319c 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>
#ifdef CONFIG_X86_32 __visible unsigned long saved_context_ebx; @@ -231,6 +232,21 @@ static void notrace __restore_processor_state(struct saved_context *ctxt) */ #ifdef CONFIG_X86_64 wrmsrl(MSR_GS_BASE, ctxt->kernelmode_gs_base);
/** Restore FRED configs.** FRED configs are completely derived from current kernel text and* data mappings, thus nothing needs to be saved and restored.** As such, simply re-initialize FRED to restore FRED configs.
Instead of the above, I would just say "Reinitialize FRED to ensure that the FRED registers contain the same values as before hibernation."
** Note, FRED RSPs setup needs to access percpu data structures.
And I'm not sure what you wanted to say here? Does this refer to the ordering of the code below or to something else?
*/if (ctxt->cr4 & X86_CR4_FRED) {cpu_init_fred_exceptions();cpu_init_fred_rsps();}#else loadsegment(fs, __KERNEL_PERCPU);
#endif