From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754420AbYIDPTR (ORCPT ); Thu, 4 Sep 2008 11:19:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750822AbYIDPTB (ORCPT ); Thu, 4 Sep 2008 11:19:01 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:42747 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752002AbYIDPTA (ORCPT ); Thu, 4 Sep 2008 11:19:00 -0400 Date: Thu, 4 Sep 2008 17:18:32 +0200 From: Ingo Molnar To: "H. Peter Anvin" Cc: Prarit Bhargava , Peter Zijlstra , linux-kernel@vger.kernel.org, arozansk@redhat.com, dzickus@redhat.com, Thomas.Mingarelli@hp.com, ak@linux.intel.com, Alan Cox , Thomas Gleixner , "Maciej W. Rozycki" Subject: Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback Message-ID: <20080904151832.GA7120@elte.hu> References: <20080904130048.31841.3329.sendpatchset@prarit.bos.redhat.com> <1220535463.8609.223.camel@twins> <48BFF0C0.7060208@redhat.com> <20080904145617.GB28095@elte.hu> <48BFFAFB.6060907@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BFFAFB.6060907@zytor.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * H. Peter Anvin wrote: > Ingo Molnar wrote: >> >> i'd much rather attack this general problem from this angle: >> >> static inline unsigned char get_nmi_reason(void) >> { >> return inb(0x61); >> } >> >> that port 61H read is both arcane (on modern chipsets) and broken on >> multiple levels. It's racy and SMP unsafe to begin with, if there's any >> mixture of intentional cross-CPU or CPU self-generated NMIs mixed with >> chipset generated NMIs. >> >> One possible approach would be to get rid of it, and to perhaps >> register a low-priority die notifier on systems where we know port 61 >> reads+writes to be safe and desired. Modern systems will emit MCEs in >> most cases anyway, not NMIs. >> > > I believe we should still do it, but as the lowest priority "nothing > else claimed this". It reflects a system error and not all systems > will generate #MC instead of NMI for all system errors. > > Pretty much what you're saying above. ok. One potential additional concern i can think of is multi-source NMIs: NMIs, when generated by some sort of hardware are edge triggered most of the time, so if in the notifier chain a notifier decides "this was for me, return now", we will lose an event. So i think we should iterate through all notifier entries and call them (even if all of them indicate that they handled it), and determine whether at least one notifier handled something. If nothing handled the NMI _then_ do the port 61H logic as a final fall-back thing. Ingo