Messages in this thread | | | Date | Wed, 21 Sep 2011 13:10:21 -0400 | From | Don Zickus <> | Subject | Re: [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?
Cheers, Don
| |