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 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?

Best Regards,
Huang Ying

> + */
> + if (b2b && __this_cpu_read(swallow_nmi))
> + ;
> + else
> + unknown_nmi_error(reason, regs);
> }
>
> dotraplinkage notrace __kprobes void



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