linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Don Zickus <dzickus@redhat.com>
Cc: x86@kernel.org, Andi Kleen <andi@firstfloor.org>,
	Robert Richter <robert.richter@amd.com>,
	Peter Zijlstra <peterz@infradead.org>,
	ying.huang@intel.com, LKML <linux-kernel@vger.kernel.org>,
	paulmck@linux.vnet.ibm.com, jeremy@goop.org
Subject: Re: [V5][PATCH 4/6] x86, nmi:  add in logic to handle multiple events and unknown NMIs
Date: Tue, 20 Sep 2011 20:23:03 +0300	[thread overview]
Message-ID: <4E78CBF7.4060004@redhat.com> (raw)
In-Reply-To: <1316529792-6560-5-git-send-email-dzickus@redhat.com>

On 09/20/2011 05:43 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.
>
> An optimization has also been added to the nmi notifier rountine.  Because x86
> can latch up to one NMI while currently processing an NMI, we don't have to
> worry about executing _all_ the handlers in a standalone NMI.  The idea is
> if multiple NMIs come in, the second NMI will represent them.  For those
> back-to-back NMI cases, we have the potentail to drop NMIs.  Therefore only
> execute all the handlers in the second half of a detected back-to-back NMI.
>
> V2:
>    - forgot to add the 'read' code for swallow_nmi (went into next patch)
>
> V3:
>    - redesigned the algorithm to utilize Avi's idea of detecting a back-to-back
>      NMI with %rip.
> V4:
>    - clean up fixes, like adding 'static', rename save_rip to last_nmi_rip
>
>

Missing a zeroing of last_nmi_rip in the idle path.  Otherwise, as Andi 
points out, and idle machine will always see NMIs coming in from the 
hlt/mwait address and detect them as back-to-back NMIs.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2011-09-20 17:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-20 14:43 [V5][PATCH 0/6] x86, nmi: new NMI handling routines Don Zickus
2011-09-20 14:43 ` [V5][PATCH 1/6] x86, nmi: split out nmi from traps.c Don Zickus
2011-09-20 14:43 ` [V5][PATCH 2/6] x86, nmi: create new NMI handler routines Don Zickus
2011-09-21  5:36   ` Huang Ying
2011-09-21 13:56     ` Don Zickus
2011-09-20 14:43 ` [V5][PATCH 3/6] x86, nmi: wire up NMI handlers to new routines Don Zickus
2011-09-21  5:41   ` Huang Ying
2011-09-21 10:49     ` Borislav Petkov
2011-09-21 14:06       ` Don Zickus
2011-09-20 14:43 ` [V5][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs Don Zickus
2011-09-20 17:23   ` Avi Kivity [this message]
2011-09-20 20:10     ` Don Zickus
2011-09-21  5:45       ` Avi Kivity
2011-09-21  5:43   ` Huang Ying
2011-09-21 13:57     ` Don Zickus
2011-09-21 10:08   ` Robert Richter
2011-09-21 14:04     ` Don Zickus
2011-09-21 15:18       ` Robert Richter
2011-09-21 15:33         ` Peter Zijlstra
2011-09-21 16:04           ` Robert Richter
2011-09-21 16:40             ` Peter Zijlstra
2011-09-21 16:13         ` Don Zickus
2011-09-21 16:24           ` Avi Kivity
2011-09-21 16:54             ` Robert Richter
2011-09-25 12:54               ` Avi Kivity
2011-09-21 17:10             ` Don Zickus
2011-09-20 14:43 ` [V5][PATCH 5/6] x86, nmi: track NMI usage stats Don Zickus
2011-09-20 14:43 ` [V5][PATCH 6/6] x86, nmi: print out NMI stats in /proc/interrupts Don Zickus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E78CBF7.4060004@redhat.com \
    --to=avi@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=dzickus@redhat.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.com \
    --cc=x86@kernel.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).