LWN: Comments on "Multi-threaded emulation for QEMU"

I'm wondering what this means on a practical level

alex — Tue, 28 Mar 2017 13:18:34 +0000

Userspace translation is a fair bit faster than system emulation as each load/store is a simple offset into the "guest" memory compared to the SoftMMU emulation we need to do for a full system. However we still re-translate all the guest instructions into new host ones via TCG so you always have to pay the cost of the translation overhead.

I'm wondering what this means on a practical level

spotter — Thu, 02 Mar 2017 00:53:49 +0000

I guess I'm wondering why. Going back to old school vmware, cpu bound userspace programs were not much slower than running on the bare metal. I thought the reason was that they only had to emulate the privileged instructions. I'm guessing from your response that QEMU doesn't work that way, it virtualizes and translates the whole cpu, so in practice there is no advantage of x86_64 on x86_64 vs arm on x86_64 in terms of performance. That's not the problem QEMU is trying to solve (and perhaps the answer is if you care about this, just use KVM)

I'm wondering what this means on a practical level

nix — Wed, 01 Mar 2017 22:42:44 +0000

Honestly, TCG performance is going to be pretty dire no matter what you do. Emulating a CPU under another CPU is not going to be anything but vastly slower than the original unless you're emulating something like a 6502. Extra cores will just make it incredibly slow rather than intolerably slow.

I'm wondering what this means on a practical level

spotter — Wed, 01 Mar 2017 19:39:18 +0000

yes, I know KVM. but KVM isn't available everywhere (ex: you want to do something in emulation on AWS, or basically any commercial cloud platform, none, AFAIK right now, support nested virt). There are reasons to run qemu by itself on the cloud, but performance has been terrible and this could help with one of those reasons I'd think.

I'm wondering what this means on a practical level

nix — Wed, 01 Mar 2017 16:57:29 +0000

QEMU has supported multiple cores in KVM mode for ages, including more cores than you actually have. (However, CPU affinity for those cores is only available via the monitor interface, so if you're using the command line to start QEMU you can expect significant thrashing between physical CPUs and a corresponding slowdown even when using fewer virtual cores than physical, unless you use some non-upstreamed patches to add a command-line interface to set this.)

I'm wondering what this means on a practical level

spotter — Wed, 01 Mar 2017 06:36:17 +0000

For instance, I believe (correct me if I'm wrong), that currently in the "old school vmware workstation" type mode of QEMU (i.e. running windows on Linux or vice versa without hardware support) could only operate as a single core machine (or in practice even if it showed multiple virtual cores, it was in practice just using one core). Would this allow it to actually do more of a 1:1 mapping? i.e. you want 4 cores in your virtual windows box, and it will actually make use of 4 cores you have on your linux host? or does it not help in these cases at all?

Multi-threaded emulation for QEMU

alex — Wed, 31 Aug 2016 10:06:30 +0000

You are right, it should be consistency and in fact the project and patch series refer to that. Of course outside of the specific usage coherence is "the quality of being logical and consistent" so it's not completely misleading ;-)

Multi-threaded emulation for QEMU

binkert — Sun, 21 Aug 2016 03:57:11 +0000

Given what you write about, the section titled "Memory Coherency" should be titled "Memory Consistency". Consistency deals with writes to different memory locations and the order the processors observe them. Coherence deals with writes to individual memory locations and how they propagate throughout the system.