On 09/19/2011 05:54 PM, Marcelo Tosatti wrote:
On Mon, Sep 19, 2011 at 05:30:27PM +0300, Avi Kivity wrote: > On 09/19/2011 04:54 PM, Marcelo Tosatti wrote: > >> >> > >> >> Yes, due to NMI-blocked-by-STI. A really touchy area. > >> >And we don't need the window exit notification then? I don't understand > >> >what nmi_in_progress is supposed to do here. > >> > >> We need the window notification in both cases. If we're recovering > >> from STI, then we don't need to collapse NMIs. If we're completing > >> an NMI handler, then we do need to collapse NMIs (since the queue > >> length is two, and we just completed one). > > > >I don't understand what is the point with nmi_in_progress, and the above > >hunk, either. Can't inject_nmi do: > > > >if (nmi_injected + atomic_read(nmi_pending)< 2) > > atomic_inc(nmi_pending) > > > >Instead of collapsing somewhere else? > > We could. It's not atomic though - two threads executing in > parallel could raise the value to three. Could do a cmpxchg loop > does an increment bounded to two. I guess this is a lot clearer, > thanks. > > >You'd also have to change > >nmi_injected handling in arch code so its value is not "hidden", in > >complete_interrupts(). > > Or maybe make raising nmi_injected not decrement nmi_pending. So: > > nmi_pending: total number of interrupts in queue > nmi_injected: of these, how many are currently being injected > > yes? Yes, at the expense of decrementing on subarch code (which is fine, apparently).
Hm, we have no place to decrement. We need to do that when IRET executes, but we don't want to request an NMI window exit in the common case of nmi_pending = 1.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
