E-20
GUIDELINES FOR WRITING FPU EXCEPTIONS HANDLERS
E.3.4.Need for Storing State of IGNNE# Circuit If Using FPU and
SMM
The recommended circuit (refer to Figure E-1) for MS-DOS compatibility FPU exception han-
dling for Intel486 processors and beyond contains two flip flops. When the FPU exception
handler accesses I/O port 0F0H it clears the IRQ13 interrupt request output from Flip Flop #1
and also clocks out the IGNNE# signal (active) from Flip Flop #2. The assertion of IGNNE#
may be used by the handler if needed to execute any FPU instruction while ignoring the pending
FPU errors. The problem here is that the state of Flip Flop #2 is effectively an additional (but
hidden) status bit that can affect processor behavior, and so ideally should be saved upon enter-
ing SMM, and restored before resuming to normal operation. If this is not done, and also the
SMM code saves the FPU state, AND an FPU error handler is being used which relies on
IGNNE# assertion, then (very rarely) the FPU handler will nest inside itself and malfunction.
The following example shows how this can happen.
Suppose that the FPU exception handler includes the following sequence:
FNSTSWsave_sw ; save the FPU status word
; using a no-wait FPU instruction
OUT0F0H, AL; clears IRQ13 & activates IGNNE#
. . . .
FLDCW new_cw; loads new CW ignoring FPU errors,
; since IGNNE# is assumed active; or any
; other FPU instruction that is not a no-wait
; type will cause the same problem
. . . .
FCLEX; clear the FPU error conditions & thus turn off FERR# & reset the IGNNE# FF
The problem will only occur if the processor enters SMM between the OUT and the FLDCW
instructions. But if that happens, AND the SMM code saves the FPU state using FNSAVE, then
the IGNNE# Flip Flop will be cleared (because FNSAVE clears the FPU errors and thus de-as-
serts FERR#). When the processor returns from SMM it will restore the FPU state with FR-
STOR, which will re-assert FERR#, but the IGNNE# Flip Flop will not get set. Then when the
FPU error handler executes the FLDCW instruction, the active error condition will cause the
processor to re-enter the FPU error handler from the beginning. This may cause the handler to
malfunction.
To avoid this problem, Intel recommends two measures:
1.Do not use the FPU for calculations inside SMM code. (The normal power management,
and sometimes security, functions provided by SMM have no need for FPU calculations; if
they are needed for some special case, use scaling or emulation instead.) This eliminates
the need to do FNSAVE/FRSTOR inside SMM code, except when going into a 0 V
suspend state (in which, in order to save power, the CPU is turned off completely, requiring
its complete state to be saved.)
2.The system should not call upon SMM code to put the processor into 0 V suspend while
the processor is running FPU calculations, or just after an interrupt has occurred. Normal
power management protocol avoids this by going into power down states only after timed
intervals in which no system activity occurs.
