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). > 2) the decrementor interrupt happens in-kernel, so timer interrupts still arrive properly Means PPC periodically returns to user space? Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : https://lists.cs.columbia.edu/pipermail/android-virt/attachments/20110605/be710676/signature.bin
