From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755574Ab1INHIf (ORCPT ); Wed, 14 Sep 2011 03:08:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29111 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755208Ab1INHIe (ORCPT ); Wed, 14 Sep 2011 03:08:34 -0400 Message-ID: <4E7052DD.8080305@redhat.com> Date: Wed, 14 Sep 2011 10:08:13 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 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> In-Reply-To: <1315947509-6429-5-git-send-email-dzickus@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/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. > @@ -278,19 +294,49 @@ unknown_nmi_error(unsigned char reason, struct pt_regs *regs) > pr_emerg("Dazed and confused, but trying to continue\n"); > } > > +DEFINE_PER_CPU(bool, swallow_nmi); > +DEFINE_PER_CPU(unsigned long, save_rip); 'static'. Also need a better name for save_rip (suggest last_nmi_rip). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.