Date: Sat, 19 Jul 2014 23:09:48 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: amd64@freebsd.org, arch@freebsd.org Subject: Re: KDB entry on NMI Message-ID: <20140719200948.GW93733@kib.kiev.ua> In-Reply-To: <18C85F15-FC9E-480C-BFB9-4CD0894FD93A@xcllnt.net> References: <20140718160708.GO93733@kib.kiev.ua> <A26F3461-4654-4749-A719-C2E543F4A126@xcllnt.net> <20140719182909.GU93733@kib.kiev.ua> <18C85F15-FC9E-480C-BFB9-4CD0894FD93A@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--/kNZZTualZuJSMMX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 19, 2014 at 12:57:24PM -0700, Marcel Moolenaar wrote: >=20 > On Jul 19, 2014, at 11:29 AM, Konstantin Belousov <kostikbel@gmail.com> w= rote: > >>=20 > >> 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. >=20 > 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. >=20 > 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 architectural state. --/kNZZTualZuJSMMX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTytCMAAoJEJDCuSvBvK1BPBAQAJhX5OO90h5g62cs0VxX3l4c lnyG6vK/oZQBSIJHWPf8evPIGuFhOQH8pULC2FA4z5fwRJmgIoI+s/QVKxotD1nw AjGuBM2MVfwtOzafvfkXq+x/jlL7iJgHBHEGde4HHWxgbCzvkENVQUADDDXftex/ oDLkFzE0vfnVlm8/UAC6si08AmawSeEI5gQ+oss1onrrC/RCKconMqJZ4nlQ/EWJ VMm6QLJb7+HWuWNKWTFznD9n/+FNM6S5n8UTthvbKz7EIZHtfuESpXdIhx9ctt81 USbz7r+GM27MYwoupwkd4c33qetobsTBVZW9L4vuhj2QCmKX+wWU+lozxtG18gF3 T2ZH+AGvr+qLn6ROQq5J51PT7Et/JFkMn4o5fyOvJaEm+9FeGdEa70pp0hRDYWBQ pmVVqANKtqvo4PnspN4bhPY3W3XBCx1vQkI32g4bdgifaZsjW1YLqQVkLqDz50Mh uwXmoB1wFPZ+cwHo+tBsmMynjJtXmatKdnhRXbN56FDz9PEjyOVLhON0OummAftC BsS2txJNy2vyOVYRypU2PqLWTY+wED3Ks092Yjw/Qlu61Xo7/N+U6IQ4jC2Xzm5l S34U+0twBm1vAcEZhO1hV1up3b0DqfKPbvdFMQOA1ojRY+qX7Lte5dAXwhM59KOG qbqOkKDPlTM1Ri9EOTGd =qT// -----END PGP SIGNATURE----- --/kNZZTualZuJSMMX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140719200948.GW93733>