On Sun, 18 May 2025 at 08:34, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > * Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > > Alternatively we could set in_kernel_fpu during CPU bootstrap, and > > > clear it once we know the FPU is usable? This is only a relatively > > > short early boot period, with no scheduling, right? > > > > Yes, if there isn't agreement on this approach we can do that > > instead. Say: > > > > - Replace in_kernel_fpu with kernel_fpu_supported, with the opposite > > meaning (so that the initial value of false means "unsupported") > > I'm not against simplifying the x86 FPU model to exclude IRQs-off > context (especially if it also micro-optimizes some of the key runtime > kernel-FPU primitives), but it has to be a full solution and we'll have > to see how complicated the EFI changes get. > > Ie. without seeing the full cost-benefit balance it's hard to call this > in advance. Mind sending a full series that addresses the EFI case too? > EFI services are only called with IRQs disabled in exceptional cases, so it would be unfortunate if it prevents us from make meaningful improvements here. In ordinary cases, they are called from a workqueue, and I'd prefer it if we can address this without calling all EFI services with interrupts disabled either. AIUI, the reason we cannot tolerate IRQs being disabled is because re-enabling softirqs will complain if IRQs are disabled, due to the fact that handling softirqs should not be attempted at that point? I don't know the history here, but I wonder if that isn't overly pedantic? Disabling softirqs could be avoided entirely when IRQs are off, given that they are disabled implicitly already. But why then is it not permitted to disable and re-enable softirqs under this condition, given that it makes no difference? Or perhaps I'm missing something here. A good way to trigger such an exceptional case is running a kernel with efi-pstore and lkdtm built-in under QEMU with OVMF, and do # echo PANIC > /sys/kernel/debug/provoke-crash/DIRECT Another case that likely executes with IRQs disabled (but I haven't double checked) is reset_system(), which may return with an error, or reboot/poweroff the machine and never return.
