Re: [GIT PULL] Native Linux KVM tool for 3.1

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/25/2011 07:59 AM, Paolo Bonzini wrote:
> On 07/25/2011 09:50 AM, Sasha Levin wrote:
>> Anthony had a talk on last years KVM forum regarding the QEMU threading
>> model (slide:
>> http://www.linux-kvm.org/wiki/images/7/70/2010-forum-threading-qemu.pdf)
>> .
>>
>> It was suggested that the KVM part of QEMU is having a hard time
>> achieving the ideal threading model due to its need to support TCG -
>> something which has nothing to do with KVM itself.
>
> No, it is not having a hard time. The "foot in the door" that Anthony
> mentions has been part of QEMU and qemu-kvm for a long time
> (multi-threading is necessary to support SMP!) and works quite well.
>
>
> Historically, there were three main loops:
>
> 1) QEMU single-threaded;
>
> 2) QEMU multi-threaded; clean, but buggy, untested and bitrotting;
>
> 3) qemu-kvm multi-threaded, forked from (1), ugly but robust and widely
> deployed.
>
> In 0.15 the two multi-threaded versions have been unified by Jan Kiszka.
> I have even ported (2) to Windows with little or no pain; porting to Mac
> OS X interestingly is harder than Windows, because non-portable Linux
> assumptions about signal handling have crept in the code (to preempt the
> objections: they weren't just non-portabilities, they were latent bugs).
> Windows just does not have signals. :)
>
> So, right now, the only difference is that QEMU is still defaulting to
> the single-threaded main loop, while qemu-kvm enables multi-threading by
> default. In some time even QEMU will switch.
>
> Yes, this is of course worse than getting it right in the first place;
> Nobody is saying the opposite.

In all fairness, the fact that TCG requires signals to break execution 
does complicate the QEMU code a fair bit.  But that's because signals 
are tricky to get right, not that the model is fundamentally complicated.

Regards,

Anthony Liguori

>
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html