RE: NMI handling rework

From: Heater, Daniel (IndSys, GEFanuc, VMIC) (Daniel.Heater@gefanuc.com)
Date: Fri Nov 08 2002 - 10:00:16 EST


-- Snipped from the patch --

If the handler actually handles the NMI, it should return NOTIFY_OK.
If it did not handle the NMI, it should return NOTIFY_DONE. It may "or"
on NOTIFY_STOP_MASK to the return value if it does not want other
handlers after it to be notified.

-- End snip --

> It is still possible, though unlikely, that two NMI sources could occur
> at the same time. Maybe that's not worth worrying about, and maybe for
> the APICs it works fine.

Am I reading this correctly? As long as no one passes back NOTIFY_STOP_MASK,
all handlers are run. Assuming that all external NMI sources have a means of
checking whether they were the source, this would work like shared PCI
interrupts.

> Not on the i386 family. Once an NMI is accepted by the CPU, it gets
> internally masked until an iret instruction gets executed. If another NMI
> happens maenwhile, it's latched by the processor internally and dispatched
> as soon as NMIs are unmasked. Further NMIs received when masked are lost.

So... We're running through the handler list servicing an NMI, two more NMIs
come in and we latch one (the other is dropped). It doesn't matter. Either
the
affected handlers have not run yet and will get run on the current pass, or
they will run on the next pass. You may have two handlers run on a single
pass
but you should not drop any. True??

This assumes i386 architecture and all handlers are run. I don't know about
other archs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:15 EST