From owner-freebsd-amd64@FreeBSD.ORG Sat Jul 19 17:58:35 2014 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09942120; Sat, 19 Jul 2014 17:58:35 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A7392FA3; Sat, 19 Jul 2014 17:58:33 +0000 (UTC) Received: from [172.29.5.30] ([66.129.239.11]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s6JHwOUU023109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 19 Jul 2014 10:58:26 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_332A8ACD-E11F-490C-B854-38BF11F64932"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: KDB entry on NMI From: Marcel Moolenaar In-Reply-To: <20140718160708.GO93733@kib.kiev.ua> Date: Sat, 19 Jul 2014 10:58:18 -0700 Message-Id: References: <20140718160708.GO93733@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1878.6) Cc: amd64@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 17:58:35 -0000 --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 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--