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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]