From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932696Ab1INNWd (ORCPT ); Wed, 14 Sep 2011 09:22:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20195 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932406Ab1INNWc (ORCPT ); Wed, 14 Sep 2011 09:22:32 -0400 Message-ID: <4E70AA82.5050409@redhat.com> Date: Wed, 14 Sep 2011 16:22:10 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Don Zickus CC: x86@kernel.org, Andi Kleen , Robert Richter , Peter Zijlstra , ying.huang@intel.com, LKML , paulmck@linux.vnet.ibm.com, jeremy@goop.org Subject: Re: [V4][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs References: <1315947509-6429-1-git-send-email-dzickus@redhat.com> <1315947509-6429-5-git-send-email-dzickus@redhat.com> <4E7052DD.8080305@redhat.com> <20110914130027.GU5795@redhat.com> In-Reply-To: <20110914130027.GU5795@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/14/2011 04:00 PM, Don Zickus wrote: > On Wed, Sep 14, 2011 at 10:08:13AM +0300, Avi Kivity wrote: > > On 09/13/2011 11:58 PM, Don Zickus wrote: > > >Previous patches allow the NMI subsystem to process multipe NMI events > > >in one NMI. As previously discussed this can cause issues when an event > > >triggered another NMI but is processed in the current NMI. This causes the > > >next NMI to go unprocessed and become an 'unknown' NMI. > > > > > >To handle this, we first have to flag whether or not the NMI handler handled > > >more than one event or not. If it did, then there exists a chance that > > >the next NMI might be already processed. Once the NMI is flagged as a > > >candidate to be swallowed, we next look for a back-to-back NMI condition. > > > > > >This is determined by looking at the %rip from pt_regs. If it is the same > > >as the previous NMI, it is assumed the cpu did not have a chance to jump > > >back into a non-NMI context and execute code and instead handled another NMI. > > > > > >If both of those conditions are true then we will swallow any unknown NMI. > > > > > >There still exists a chance that we accidentally swallow a real unknown NMI, > > >but for now things seem better. > > > > Patch looks good, but the changelog is outdated. > > Perhaps, but I tried rewriting most of it to reflect the current changes. > Was there something obvious in there that I missed? I re-read it a few > times and can't figure out what part might be outdated (not that I > disagree with you, I just want to update it). > It's not really outdated (I guess I misread it). However it emphasises the nmi swallowing part (which I guess was the focus of the first version) and doesn't really talk about doing just one source in ordinary NMIs and processing all sources in second (and third...) back-to-back NMIs. I'd add something about that. -- error compiling committee.c: too many arguments to function