Re: [PATCH 1/3] efi/x86: simplify 64-bit EFI firmware call wrapper

[Arvind Sankar <nivedita@alum.mit.edu>]

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@linaro.org> wrote:
> > 
> > On Fri, 27 Dec 2019 at 19:08, Arvind Sankar
> > <nivedita@alum.mit.edu> 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.