On 2011-02-03 08:42, Gleb Natapov wrote: > 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. Yeah, and it wouldn't explain the various BSOFs I'm seeing (you get an even broader spectrum when trying the Windows installations DVDs). We are probably digging at the wrong site. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
