No hardware twiddling. One cpu gets an event which triggers kdb, that
event may or may not be via NMI. kdb on ix86 then uses NMI to get the
attention of the other cpus, even if they are in a disabled spinloop.
ix86 hardware will not deliver another NMI to a cpu until the cpu
issues iret to return from the NMI handler.
Initially all but one cpu is forced into kdb via the NMI handler so no
more NMI events will occur on those cpus. The first cpu may or may not
be receiving NMI, it depends on how kdb was invoked on the first cpu.
To do single stepping of code, kdb allows one cpu out of kdb state so
it can execute one instruction at the point it was interrupted. If the
cpu was entered via NMI then that means exiting from the NMI handler
back to the original code, do single step then back into kdb again.
Having exited the NMI handler, that cpu will start receiving NMI events
again, even though it is still under kdb control. So some cpus will
get NMI, some will not, depending on user actions. kdb uses a software
mechanism to selectively disable the NMI watchdog.
-
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/