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
next prev parent 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).