On 09/19/2011 06:09 PM, Avi Kivity wrote:
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.
I guess we have to change kvm_inject_nmi to run in vcpu context, where
it has access to more stuff.
--
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
