On Fri, 28 Feb 2025 at 04:59, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Wed, Feb 19, 2025 at 09:13:24PM -0800, Eric Biggers wrote: > > To comply with the requirements of local_bh_disable and local_bh_enable, > > this change also removes support for kernel-mode FPU in hardirq context > > or with hardirqs disabled. This should not be a problem, though. There > > does not appear to be any use case for kernel-mode FPU in such contexts, > > and notably arm64 and riscv already have these same conditions. > > I found a problem with this assumption: the system suspend and resume code calls > kernel_fpu_begin() and kernel_fpu_end() with hardirqs disabled. See > __save_processor_state() and __restore_processor_state() in > arch/x86/power/cpu.c. That triggers the WARN_ON_FPU(!irq_fpu_usable()). > > I think there are two directions we could go with this: either choose a solution > that keeps kernel_fpu_begin() usable with hardirqs disabled; I still owe you an investigation into how this interoperates with EFI runtime services, but it appears there are cases (efi-pstore on an OOPS) where EFI SetVariable() might be invoked with IRQs disabled. arm64 has a special case for EFI runtime calls made under conditions where SIMD may not be used, and essentially just preserves and restores the entire state. It is rather unfortunate that this is needed, but the UEFI spec permits runtime service implementations to use XMM registers so there is no way around this AFAIK. > or change > __save_processor_state() and __restore_processor_state() to save/restore the FPU > registers directly, e.g. via save_fpregs_to_fpstate() and > restore_fpregs_from_fpstate(). (Kernel-mode FPU isn't actually being used in > this case, so a more direct save/restore might make sense here.) > > - Eric
