lkml.org 
[lkml]   [2011]   [Sep]   [25]   [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/21/2011 07:54 PM, Robert Richter wrote:
> On 21.09.11 12:24:54, Avi Kivity wrote:
> > On 09/21/2011 07:13 PM, Don Zickus wrote:
> > > On Wed, Sep 21, 2011 at 05:18:30PM +0200, Robert Richter wrote:
> > > > On 21.09.11 10:04:32, Don Zickus wrote:
>
> > > > But in rare cases there is the following:
> > > >
> > > > 1. The cpu executes some microcode or SMM code.
> > > > 2. HW triggers the first NMI, an NMI is pending.
> > > > 3. HW triggers a second NMI, the NMI is still pending.
> > > > 4. The cpu finished microcode or SMM code.
> > > > 5. NMI handler is called, no NMI pending anymore.
> > > > 6. Return from NMI handler.
> > > >
> > > > In this case the handler is called only once and the second nmi
> > > > remains unhandled with you implementation.
> > > >
> > > > I don't see a way how this could be catched without serving all
> > > > handlers the first time. But as said, in favor of the optimization I
> > > > think we can live with losing some NMIs.
>
> I have to revise this after thinking more about this. We may not lose
> an nmi for sources where the nmi handler must always reenable the nmi,
> e.g. IBS. Losing one nmi means for IBS that sample generation gets
> stuck.
>

Well, that pretty much kills the whole idea. This thing has to be reliable.

I'll ask Intel if they can guarantee a length 2 queue on their
processors (or maybe Andi you can find this out).

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



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