Date: Sat, 19 Jul 2014 10:58:18 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: amd64@freebsd.org, arch@freebsd.org Subject: Re: KDB entry on NMI Message-ID: <A26F3461-4654-4749-A719-C2E543F4A126@xcllnt.net> In-Reply-To: <20140718160708.GO93733@kib.kiev.ua> References: <20140718160708.GO93733@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_332A8ACD-E11F-490C-B854-38BF11F64932 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jul 18, 2014, at 9:07 AM, Konstantin Belousov <kostikbel@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. FYI, -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_332A8ACD-E11F-490C-B854-38BF11F64932 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPKsboACgkQpgWlLWHuifbE1ACeLhNWhD1eu/5acOCnK+zTedWY uq4AniYoVSg/fF9DIDEWJiDjMIkTAhbS =SCRD -----END PGP SIGNATURE----- --Apple-Mail=_332A8ACD-E11F-490C-B854-38BF11F64932--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A26F3461-4654-4749-A719-C2E543F4A126>