On Tue, Sep 23, 2008 at 05:08:09PM +0800, Yang, Sheng wrote:
> > > >>> We still get here with vmx->soft_vnmi_blocked = 1. Trying to find out
> > > >>> how.
> > > >>
> > > >> We should only come along here with vnmi blocked on reinjection (after
> > > >> a fault on calling the handler).
> > > >
> > > > I see that nmi_injected is never cleared and it is check before calling
> > > > vmx_inject_nmi();
> > >
> > > That should happen in vmx_complete_interrupts, but only if the exit
> > > takes place after the NMI has been successfully delivered to the guest
> > > (which is not the case if invoking the handler raises an exception). So
> > > far for the theory...
> >
> > Okey, I have this one in dmesg:
> > kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9
> >
> Oh... Another task switch issue...
>
> I think it's may not be a issue import by this patchset? Seems need more
> debug...
>
> The patchset is OK for me, except I don't know when we would need that
> timeout
> one (buggy guest?...), and we may also root cause this issue or ensure that
> it's not a regression.
>
Without the patch series kvm doesn't inject NMIs on this machine, so guest
hangs. It's
hard to tell if this message is caused by these patches or not.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
