On 06/05/2011 08:54 PM, 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?
Signal the vcpu thread, of course. There's on_vcpu (or on_cpu, don't know how it's called today) for that.
-- error compiling committee.c: too many arguments to function -- 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
