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.