Messages in this thread | | | Date | Fri, 16 May 1997 06:31:01 +0200 (METDST) | From | Gabriel Paubert <> | Subject | Re: [PATCH-2] NMI trap revised (was Re: NMI errors in 2.0.30??) (fwd) |
| |
On 16 May 1997, Rik Faith wrote:
> No. Gabriel said DURING THE NMI ROUTINE. This indicates that he is > talking about the code in the NMI handler. I.e., an NMI has been raised, > and we are currently IN THE NMI HANDLER ROUTINE. At this time, until the > handler routine returns with an IRET instruction, NMI is masked BY THE > PROCESSOR. This is exactly what Gabriel said, and he is correct, based on > my i486 manual. (The processor masks NMI during an NMI to prevent stacking > up calls to the interrupt handler.) > Thanks, Rik, up to now you are the only person who understands what I meant!
Actually I answered privately to all the guys who posted telling that I was wrong to minimize noise. AFAIK this feature for preventing nested NMI was introduced by Intel on the 286.
The only potential problem I considered up to now is that newer processors have an SMI (system management interrupt) pin which has higher priority than NMI. This interrupt puts the processor into system management mode (SMM, a real mode with 4Gb segments), which can only be exited by executing the SMM-mode only RSM (resume) instruction.
Interrupts and NMI are disabled when entering SMM mode but can be reenabled provided an IDT for SMM is defined. Do not believe every word of Intel's documentation and have a look at www.x86.org (Dr Dobb's pages if I can remember) for more information. But anyway this will not cause nesting of Linux's NMI handler and thus not be a concern.
BTW: To be completely transparent to OS NMI handlers, there must be an NMI mask bit in the save state map reloaded by RSM, but AFAIK even R.Collins does not (yet) say where it is.
Gabriel
| |