[lkml]   [2011]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [V5][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs
On Wed, Sep 21, 2011 at 07:24:54PM +0300, Avi Kivity 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.
> >
> >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.

Actually I was trying to remember what the argument for the optimization
was again? I believe the virt team needed it right?


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