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? 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
