Date: Sat, 19 Jul 2014 21:29:09 +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: <20140719182909.GU93733@kib.kiev.ua> In-Reply-To: <A26F3461-4654-4749-A719-C2E543F4A126@xcllnt.net> References: <20140718160708.GO93733@kib.kiev.ua> <A26F3461-4654-4749-A719-C2E543F4A126@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Tx24CLeOShJjHgAY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 19, 2014 at 10:58:18AM -0700, Marcel Moolenaar wrote: >=20 > On Jul 18, 2014, at 9:07 AM, Konstantin Belousov <kostikbel@gmail.com> wr= ote: >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > Thought ? >=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. Still, I hope to understand what I am missing to stop NMI from delivering in loop. Then, having only one ddb entry would mean that I should return only once. >=20 > 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. I agree there. >=20 > 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. Me too. I have another half-finished patch which does this, it allows to migrate the ddb from one cpu to another. It worked by signalling a destination cpu that it should activate, while source cpu starts spinning. I do not remember exact problems which were unresolved. I needed this because some state is CPU-local, cannot be accessed =66rom other cores, and is not saved in pcb. I definitely looked at EFER and MISC_FEATURES MSRs, and local apic state. --Tx24CLeOShJjHgAY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTyrj1AAoJEJDCuSvBvK1BodgQAIk2aC6e9so+6O0rLJAizzzz 1SZ3bYLSpNN/MbdPxQM/JudjI4qRuqMXl4vSOdOpN8oUlrKKpZBKBj7YfDyjwA3L aEeyG1iAhBjEMLhF2Rty2wDVXfOxBM/bZiTmPdl69VGbmvsqIchhJFNbUh3tTY1i a4JKQDg32LyUNvkbxvw++wco+Ts2ptIASHVkayI1zM428uaxA2r2DnFajCFFAbot dh/jvWJsXHEiQhHFOCoP1UfrQaLWbl+mTsvBjXW3lSldL4SkAQPSuW8NtUE1+kfY DBVEjMHXFvR2cT9TVJgkOhzosFKQ+Z/hrjd2tyIknaptk2kQPZJUX/qO9KH1Yt1+ UoeTVBKXUySYcfDZX/CzThLmsZwURnfq/7ZjV64P0x44FfWIBe+os5sUA0dKBmS2 62kkOFFkOwi4oSFM6ymm0JJhYLxHfGULIgqTeVa+XEO4RHb8qmU199559R/YSSDK f6nlV8hLaHkbhBSZ2EZAhRmXyuBB+P6l6rOoIEbujTAQGIy3xHvCEUFIHDl3BtN6 6aiFEKXPQJFoEvItYwDW3VSjbvCO9jkyA0+suCaL36isEM8w4Z4OfAQszgBRouqk /SXHoI6KIe/14z0JZohYYavPSC3q51/WeHYO1k7q50IIEiwhKUNwkyRAv0DJPIf2 WwSwITcNPpypeeamVfaB =qos5 -----END PGP SIGNATURE----- --Tx24CLeOShJjHgAY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140719182909.GU93733>