KDB entry on NMI

Marcel Moolenaar marcel at xcllnt.net
Sat Jul 19 17:58:35 UTC 2014

On Jul 18, 2014, at 9:07 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:

> It was mentioned somewhere recently, that typical BIOS today configures
> NMI delivery on the hardware events as broadcast.  When I developerd
> the dmar(4) busdma backend, I indeed met the problem, and wrote a
> prototype which avoided startup of ddb on all cores.  Instead, the patch
> implements custom spinlock, which allows only one core to win, other
> cores ignore the NMI, by spinning on lock.
> The issue which I see on at least two different machines with different
> Intel chipsets, is that NMI is somehow sticky, i.e. it is re-delivered
> after the handler executes iret.  I am not sure what the problem is,
> whether it is due to hardware needing some ACK, or a bug in code.
> Anyway, even on two-cores machine, having both cores simultaneously
> enter NMI makes the use of ddb impossible, so I believe the patch is
> improvement.  I make measures to ensure that reboot from ddb prompt
> works.
> Thought ?

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?

Also: we may want to do something else than going to the debugger
when we see an NMI. More complexity in the NMI handler and specific
to entering the debugger seems to move us away from doing other
things more easily.

Aside: I've always wanted to have the ability to have the kernel
debugger switch to a different CPU so that you can create DDB
commands that dump hardware resources like TLBs, etc. To support
this, you want the KDB layer to have good CPU handling, which
possibly makes it also a good place to handle concurrent entry
into the debugger from different CPUs.


Marcel Moolenaar
marcel at xcllnt.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20140719/743e29a8/attachment.sig>

More information about the freebsd-amd64 mailing list