On 05.06.2011, at 20:04, Jan Kiszka wrote: > On 2011-06-05 20:00, Alexander Graf wrote: >> >> On 05.06.2011, at 19:56, Jan Kiszka wrote: >> >>> On 2011-06-05 19:54, Alexander Graf wrote: >>>> >>>> On 05.06.2011, at 19:48, Jan Kiszka wrote: >>>> >>>>> On 2011-06-05 19:19, Alexander Graf wrote: >>>>>> >>>>>> On 05.06.2011, at 18:33, Avi Kivity wrote: >>>>>> >>>>>>> On 06/05/2011 07:30 PM, Alexander Graf wrote: >>>>>>>>>> >>>>>>>>>> Could you elaborate what you mean here? I'm not really following. Are >>>>>>>>>> you suggesting a new arch-generic interface? (Pardon my ignorance). >>>>>>>>> >>>>>>>>> Using KVM_IRQ_LINE everywhere except s390, not just in x86 and ARM. >>>>>>>> >>>>>>>> An in-kernel MPIC implementation is coming for PPC, so I don't see any reason to switch from something that works now. >>>>>>> >>>>>>> Right, this is spilled milk. >>>>>>> >>>>>>> Does the ppc qemu implementation raise KVM_INTERRUPT solely from the vcpu thread? >>>>>> >>>>>> Well, without iothread it used to obviously. Now that we have an iothread, it calls ioctl(KVM_INTERRUPT) from a separate thread. The code also doesn't forcefully wake up the vcpu thread, so yes, I think here's a chance for at least delaying interrupt delivery. Chances are pretty slim we don't get out of the vcpu thread at all :). >>>>> >>>>> There are good chances to run into a deadlock when calling a per-vcpu >>>>> IOCTL over a foreign context: calling thread holds qemu_mutex and blocks >>>>> on kvm_mutex inside the kernel, target vcpu is running endless guest >>>>> loop, holding kvm_mutex, all other qemu threads will sooner or later >>>>> block on the global lock. That's at least one pattern you can get on x86 >>>>> (we had a few of such bugs in the past). >>>> >>>> Any recommendations? Should we just signal the main thread when we want to inject an interrupt? >>> >>> Yep. That's also what x86 does (when using user space irqchips). >> >> Hrm, ok :). I guess the main reason we don't see major issues is that >> >> 1) people don't use iothread too often yet - is it even enabled by default? > > Nope (unless you use qemu-kvm.git next). Any plans on finally doing that step? Code that isn't enabled by default is pretty prone to not be tested ;). It's a good way to slowly move code upstream, stabilize it there and then finally have it enabled by default. But I don't think this process should last more than 1/2 year. And IIRC with iothread, we're way past that point. >> 2) the decrementor interrupt happens in-kernel, so timer interrupts still arrive properly > > Means PPC periodically returns to user space? Hrm. No. It stays in kernel space even more. But at least it continues to live without the need for a timer interrupt from user space, so an endless loop doesn't completely stall the guest. I see your point though. With VGA we're good thanks to the dirty bitmap update. So we get quite a good number of exits from guest context. -nographic might be problematic though. I don't see how a new key event or a new packet on the network could easily arrive inside the guest there. Sigh. I'll take a look at it when I get my head around it. Thanks a lot for the insight :). Alex -- 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
