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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
