KDB entry on NMI
kostikbel at gmail.com
Sat Jul 19 20:09:55 UTC 2014
On Sat, Jul 19, 2014 at 12:57:24PM -0700, Marcel Moolenaar wrote:
> On Jul 19, 2014, at 11:29 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> >> One may call kdb_enter on different CPUs at the same time and it's
> >> also possible to call panic on multiple CPUs at the same time (but
> >> we serialize panic() right now). What if we let kdb_enter at al deal
> >> with concurrency, instead of doing it specifically for NMIs?
> > Then, on 80-threads machine I get the 80 ddb sessions on NMI broadcast,
> > like now. With your proposal, it will be somewhat better, since
> > sessions are serialized, so I can do the reboot from the first one.
> There's value to send the NMI to all CPUs: you'll be pretty sure
> that if there's a CPU that can handle it, it will get the NMI.
> Sending it to a single CPU has the downside that if that CPU is
> unable to handle the NMI (corrupted page tables, locked on some
> chipset access, held in reset, powering down, whatever one can
> think of) you're out of luck.
Right, and this is what my patch aim to make useable.
The first CPU which gets the NMI wins the permission to enter kdb,
other CPUs ignore interrupt, if they are interrupted while winner is still
in NMI handler.
> Are we acking the NMI on all CPUs right now?
I am not sure what you are asking about.
There is no any code which ACKs NMI, and possibly there should be, but I
do not know what the ACK could consist of. It might be that the external
signal which initiates the NMI is programmed to level-triggered. and we
need to ack it in chipset ? But I do not know this for sure, and the
action would be definitely chipset-depended.
The NMI is blocked on cpu by internal NMI disable bit upon NMI
delivery, until iret is executed. The bit is not available in the CPU
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the freebsd-amd64