Re: [Qemu-devel] KVM: Windows 64-bit troubles with user space irqchip

[Gleb Natapov]

On Wed, Feb 02, 2011 at 05:51:32PM +0100, Jan Kiszka wrote:
> >>>>>> Just did so, and I can no longer reproduce the problem. Hmm...
> >>>>>>
> >>>>> If there is no problem in the logic of this commit (and I do not see
> >>>>> one yet) then we somewhere miss kicking vcpu when interrupt, that 
> >>>>> should be
> >>>>> handled, arrives?
> >>>>
> >>>> I'm not yet confident about the logic of the kernel patch: mov to cr8 is
> >>>> serializing. If the guest raises the tpr and then signals this with a
> >>>> succeeding, non vm-exiting instruction to the other vcpus, one of those
> >>>> could inject an interrupt with a higher priority than the previous tpr,
> >>>> but a lower one than current tpr. QEMU user space would accept this
> >>>> interrupt - and would likely surprise the guest. Do I miss something?
> >>>>
> >>> Injection happens by vcpu thread on cpu entry:
> >>> run->request_interrupt_window = kvm_arch_try_push_interrupts(env);
> >>> and tpr is synced on vcpu exit, so I do not yet see how what you describe
> >>> above may happen since during injection vcpu should see correct tpr.
> >>
> >> Hmm, maybe this is the key: Once we call into apic_get_interrupt
> >> (because CPU_INTERRUPT_HARD was set as described above) and we find a
> >> pending irq below the tpr, we inject a spurious vector instead.
> >>
> > That should be easy to verify. I expect Windows to BSOD upon receiving
> > spurious vector though.
> 
> I hacked spurious irq injection away, but the issue remains. At the same
> time, Windows is receiving tons of spurious interrupts without any
> complaints, even without that tpr optimization in the kernel. So this is
> obviously not yet the key.
> 
> Let's try your idea that we miss a wakeup.
> 
That is unlikely too. If vcpu missed wakeup, "info cpus" would solve the
hang since it would kick vcpu out of the kernel and missed interrupt would be
injected on re-entry.

--
                        Gleb.