Re: [V5][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs

[Avi Kivity <avi@redhat.com>]

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