Re: [Android-virt] [PATCH v3 1/8] ARM: KVM: Initial skeleton to compile KVM support

[Avi Kivity <avi@redhat.com>]

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