lkml.org 
[lkml]   [2011]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [V5][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs
On Wed, Sep 21, 2011 at 01:43:57PM +0800, Huang Ying wrote:
> On 09/20/2011 10:43 PM, Don Zickus wrote:
> [snip]
> > @@ -313,7 +359,31 @@ static notrace __kprobes void default_do_nmi(struct pt_regs *regs)
> > }
> > raw_spin_unlock(&nmi_reason_lock);
> >
> > - unknown_nmi_error(reason, regs);
> > + /*
> > + * Only one NMI can be latched at a time. To handle
> > + * this we may process multiple nmi handlers at once to
> > + * cover the case where an NMI is dropped. The downside
> > + * to this approach is we may process an NMI prematurely,
> > + * while its real NMI is sitting latched. This will cause
> > + * an unknown NMI on the next run of the NMI processing.
> > + *
> > + * We tried to flag that condition above, by setting the
> > + * swallow_nmi flag when we process more than one event.
> > + * This condition is also only present on the second half
> > + * of a back-to-back NMI, so we flag that condition too.
> > + *
> > + * If both are true, we assume we already processed this
> > + * NMI previously and we swallow it. Otherwise we reset
> > + * the logic.
> > + *
> > + * I am sure there are scenarios where we accidentally
> > + * swallow a real 'unknown' NMI. But this is the best
> > + * we can do for now.
>
> Why not describe a scenario where we swallow a real 'unknown' NMI? So
> that someone working on the code in the future will know the challenge?

I can add a couple of lines of comment for that.

Thanks,
Don


\
 
 \ /
  Last update: 2011-09-21 16:01    [W:0.134 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site