17

I conducted the following benchmark in qemu and qemu-kvm, with the following configuration:

CPU: AMD 4400 process dual core with svm enabled, 2G RAM
Host OS: OpenSUSE 11.3 with latest Patch, running with kde4
Guest OS: FreeDos
Emulated Memory: 256M
Network: Nil
Language: Turbo C 2.0
Benchmark Program: Count from 0000000 to 9999999. Display the counter on the screen
     by direct accessing the screen memory (i.e. 0xb800:xxxx)

It only takes 6 sec when running in qemu.

But it takes 89 sec when running in qemu-kvm.

I ran the benchmark one by one, not in parallel.

I scratched my head the whole night, but still not idea why this happens. Would somebody give me some hints?

shgnInc
  • 2,054
  • 1
  • 23
  • 34
bio2com2
  • 171
  • 1
  • 4
  • This is just my thought, guest OS is FreeDos. According to theory qemu translates every instruction given to the guest OS to an instruction understood by the host OS using TCG. qemu with kvm on the other hand sends instructions to the host OS directly and gets them executed so in theory qemu with kvm must be faster. But i think that also depends on the guest OS that is being used. It may be possible that kvm is trying to send the instructions directly to the host OS to execute but it is not and it is going through the TCG route as if it was plan qemu command. pls update – Vinay Prabhakaran Jan 12 '17 at 12:58

3 Answers3

15

KVM uses qemu as his device simulator, any device operation is simulated by user space QEMU program. When you write to 0xB8000, the graphic display is operated which involves guest's doing a CPU `vmexit' from guest mode and returning to KVM module, who in turn sends device simulation requests to user space QEMU backend.

In contrast, QEMU w/o KVM does all the jobs in unified process except for usual system calls, there's fewer CPU context switches. Meanwhile, your benchmark code is a simple loop which only requires code block translation for just one time. That cost nothing, compared to vmexit and kernel-user communication of every iteration in KVM case.

This should be the most probable cause.

arrowd
  • 33,231
  • 8
  • 79
  • 110
admiring_shannon
  • 904
  • 6
  • 16
1

Your benchmark is an IO-intensive benchmark and all the io-devices are actually the same for qemu and qemu-kvm. In qemu's source code this can be found in hw/*.

This explains that the qemu-kvm must not be very fast compared to qemu. However, I have no particular answer for the slowdown. I have the following explanation for this and I think its correct to a large extent.

"The qemu-kvm module uses the kvm kernel module in linux kernel. This runs the guest in x86 guest mode which causes a trap on every privileged instruction. On the contrary, qemu uses a very efficient TCG which translates the instructions it sees at the first time. I think that the high-cost of trap is showing up in your benchmarks." This ain't true for all io-devices though. Apache benchmark would run better on qemu-kvm because the library does the buffering and uses least number of privileged instructions to do the IO.

prathmesh.kallurkar
  • 5,468
  • 8
  • 39
  • 50
0

The reason is too much VMEXIT take place.

Hardy Feng
  • 459
  • 4
  • 13