On 2011-06-05 20:12, Alexander Graf wrote: > > 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.
That's getting a bit off-topic for this thread now: The good news is that 'next' will become 'master' fairly soon (unless some regression is found), and then we are using QEMU upstream's iothread code in qemu-kvm. By default. For upstream, we are still facing TCG performance regressions in iothread mode, thus it's still default off. $Someone would have to sort them out, and then we could flip defaults there as well. Jan
signature.asc
Description: OpenPGP digital signature
