Preferences

Whether you think it's "slow" for cross-architecture use depends on your standards. It's always going to be slower than using the native CPU, because we have to emulate everything, and even with a JIT that's not going to be fast. Empirically not much effort is being put into trying to make the emulation/JIT faster (and there are serious technical obstacles as well as mere lack of effort/time), but if your target being emulated is a 200MHz embedded dev board then we can probably manage to go as fast as that in software... In any case the QEMU target is often more convenient for debugging or simply more easily available than the real hardware.

It is sometimes a bit disheartening to see so much development effort go toward the virtualization/KVM/Xen side rather than seeing improvements in TCG. I realize that Redhat (and maybe others?) funds a lot of development in that area, so it's natural that that's where most of the improvements are. I mostly use QEMU as a CPU emulator, though, and it's frustrating to see so little activity on the TCG side, especially when it comes to things like bugfixes (Win7 x64 bluescreens under TCG, mipsel loadvm broken, to name two issues that have bitten me).

Still, kudos to the developers for making some things better (TCG actually does seem noticeably faster in 2.0.0) and congratulations on the 2.0.0 release!

pm215 OP
Yes, I think Richard Henderson put in some effort in optimising TCG, which has helped.

My take on the KVM vs TCG split is simply that in the end open source projects are driven by the people who put in the work, and inevitably if there's a set of people whose day job is to work on the project then it's going to tend to improve in the areas those people and companies need. And in general the people working on the emulation side of things seem to be happy enough with the performance levels we currently have: I see plenty of patches to add new ARM boards or fix issues with devices, or to fix bugs in the linux-user emulation code. In comparison, there doesn't really seem to be much interest in TCG performance (and serious improvements in performance, though possible, would be a six month or longer project to achieve).

The particular bugs you note are even further out in the cold since x86 guest TCG in particular is pretty much orphaned and MIPS is not a great deal better (though I have been heartened to see recent contributions from Imagination).

dorfsmay
TCG?
"Tiny Code Generator", the JIT for cross architecture emulation.
doktrin
Thanks. That makes sense. I think I should have phrased that question (#3) differently, since there's a huge difference between relative and absolute speed & performance.

What I had read as implied in the SO answer I linked to was that there was some other means of implementing cross-architecture emulation that was faster than QEMU.

In other words, there's a difference between being "slow" in absolute terms vs. being "slow" relative to other virtualization solutions.

From your answer, I gather that QEMU isn't under-performant relative to other emulation options.

This item has no comments currently.