ia-32_volume1_basic-arch

Should be inserted before the value is modified this

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: IRETD REENTRANT ENDP D.3.5 Need for Storing State of IGNNE# Circuit If Using x87 FPU and SMM The recommended circuit (see Figure D-1) for MS-DOS compatibility x87 FPU exception handling for Intel486 processors and beyond contains two flip flops. When the x87 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 x87 FPU instruction while ignoring the pending x87 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 entering SMM, and restored before resuming to normal operation. If this is not done, and also the SMM code saves the x87 FPU state, AND an x87 FPU error handler is being used which relies on IGNNE# assertion, then (very rarely) the x87 FPU handler will nest inside itself and malfunction. The following example shows how this can happen. Suppose that the x87 FPU exception handler includes the following sequence: FNSTSW save_sw OUT0F0H, AL .... FLDCW new_cw ; save the x87 FPU status word ; using a no-wait x87 FPU instruction ; clears IRQ13 & activates IGNNE# ; loads new CW ignoring x87 FPU errors, ; since IGNNE# is assumed active; or any ; other x87 FPU instruction that is not a no-wait D-22 Vol. 1 GUIDELINES FOR WRITING X87 FPU EXCEPTION HANDLERS ; type will cause the same problem .... FCLEX ; clear the x87 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 x87 FPU state using FNSAVE, then the IGNNE# Flip Flop will be cleared (because FNSAVE clears the x87 FPU errors and thus de-asserts FERR#). When the processor returns from SMM it will restore the x87 FPU state with FRSTOR, which will re-assert FERR#, but the IGNNE# Flip Flop will not get set. Then when the x87 FPU error handler executes the FLDCW instruction, the active error condition will cause the processor to re-enter the x87 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 x87 FPU for calculations inside SMM code. (The normal power management, and sometimes security, functions provided by SMM have no need for x87 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 x87 FPU calculations, or just after an interrupt has occ...
View Full Document

Ask a homework question - tutors are online