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

[Robert Richter <robert.richter@amd.com>]

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.

-Robert

> >
> > Ah, I get it know.  Crap.  Well I think Avi was pushing it to make those
> > ticket_spin_locks work in virt land.  It seems like we should lean towards
> > removing the optimization.  Avi?
> >
> 
> Well, in virt land there are no SMIs, and we can guarantee that the 
> queue length is always two.  So if these rare cases are okay for 
> upstream, it'll be fine for virt.
> 
> -- 
> error compiling committee.c: too many arguments to function
> 
> 

-- 
Advanced Micro Devices, Inc.
Operating System Research Center