On Sat, Dec 28, 2019 at 11:25:49AM +0800, Andy Lutomirski wrote: > > > > On Dec 28, 2019, at 2:13 AM, Ard Biesheuvel > > <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > On Fri, 27 Dec 2019 at 19:08, Arvind Sankar > > <nivedita@xxxxxxxxxxxx> wrote: > >> > >>> On Fri, Dec 27, 2019 at 12:51:56PM -0500, Arvind Sankar wrote: > >>> Does kernel_fpu_begin/kernel_fpu_end need to be outside the > >>> efi_switch_mm? > >>> > >>> If there's an error in efi_call_phys_prolog during the old memmap > >>> code, it will call efi_call_phys_epilog without having called > >>> kernel_fpu_begin, which will cause an unbalanced kernel_fpu_end. > >>> Looks like the next step will be a panic anyway though. > >> > >> Do we even need to save/restore the fpu state at this point in > >> boot? The mixed-mode code path doesn't appear to be > >> saving/restoring the XMM registers during SetVirtualAddressMap. > > > > That is an excellent question, and I was hoping Andy or Ingo could > > shed some light on that. > > > > I tested without and it booted fine, and it does seem to me that > > there should be very little to preserve given how early this call > > happens (from efi_enter_virtual_mode() which gets called from > > start_kernel()) > > > Unless you’re somehow calling it from interrupt context, I doubt > saving FP regs is needed. Certainly kernel_fpu_begin() doesn’t do > anything that matters if we’re in the (misnamed) init task. If you’re > calling it really really early, there’s a different potential issue: > FP might not be fully initialized. We could have CR0.TS still set, or > we might not have all the various “OS supports such-and-such regs” > flags set. > > Does the UEFI spec explicitly state what FP state can be used by the > EFI functions? For 32-bit, it requires the following for boot services and runtime services: * Direction flag in EFLAGs clear * 4 KiB, or more, of available stack space * The stack must be 16-byte aligned * Floating-point control word must be initialized to 0x027F (all exceptions masked, double- precision, round-to-nearest) * Multimedia-extensions control word (if supported) must be initialized to 0x1F80 (all exceptions masked, round-to-nearest, flush to zero for masked underflow) * CR0.EM must be zero * CR0.TS must be zero We don't actually align the stack for 32-bit mode before calling, do we? No FP registers are clobbered except the floating point status register. For 64-bit: * Direction flag in EFLAGs clear * 4 KiB, or more, of available stack space * The stack must be 16-byte aligned * Floating-point control word must be initialized to 0x037F (all exceptions masked, double- extended-precision, round-to-nearest) * Multimedia-extensions control word (if supported) must be initialized to 0x1F80 (all exceptions masked, round-to-nearest, flush to zero for masked underflow) * CR0.EM must be zero * CR0.TS must be zero xmm0-5 (and the FP status register) may be clobbered, the rest of the FP registers are preserved.
