[lkml]   [2011]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [V5][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs
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

 \ /
  Last update: 2011-09-20 19:25    [W:0.066 / U:5.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site