This post originated from an RSS feed registered with Java Buzz by Weiqi Gao. Original Post: QENU: The Open Source Virtualizer Feed Title: Weiqi Gao's Weblog Feed URL: http://www.weiqigao.com/blog/rss.xml Feed Description: Sharing My Experience... Latest Java Buzz Posts Latest Java Buzz Posts by Weiqi Gao Latest Posts From Weiqi Gao's Weblog

According to its home page, "QEMU is a generic and open source machine emulator and virtualizer."

I started playing with QEMU 695 days ago, and have made three posts about QEMU:

• QEMU: The Open Source Processor Emulator (648 days ago)
• QEMU: Just How Fast Is It? (577 days ago)
• QEMU: Gentoo Guest Performance (558 days ago)

Unlike treating it like many of the other technologies that I took a look and then forgot about, I kept on using it as an emulator to run some of my non-GNU/Linux software. The software I want to run were pretty old, so they run at a reasonable speed even in emulator mode (1/20 native speed). I wrote WQGHLT along the way, which you can find here under GPLv2.

To run QEMU in virtualizer mode would require a piece of software called the KQEMU host driver, which was not available in open source form at the time. So I did not experiment. Another option for QEMU acceleration is through the kvm feature of a recent Linux kernel. But that requires a CPU that has hardware support for virtualization, which my AMD64 does not have.

KQEMU version 1.3.0pre11 was released under the GPLv2 on February 6, 2007. And it turns out that it is possible to have a QEMU/KQEMU combination running (and the guest running at 76% native speed according to the dhry2 benchmark) under Debian 4.0 x86_64. However, as everything Debian, the complete information for getting this setup working is scattered around the internet, and I have to do some digging and carbon-dating.

The good news is that both QEMU and KQEMU are available in Debian 4.0 Etch (QEMU 0.8.2/KQEMU 1.3.0pre9) and unstable (QEMU 0.9.0 and/KQEMU 1.3.0pre11). The bad news is that the packaged combination does not work; I saw the kernel panic in the guest OS when I tried. The compromise is to use the KQEMU from Debian unstable repository and the source release from QEMU website.

My recipe follows.

Preperations

I outlined how I changed my APT settings in the Getting Sun Java 6 On Debian 4.0 With APT Pinning post that I made 26 days ago. I did not change any of the settings this time.

Installing KQEMU

There are numerous web pages that describes how to install a kernel module using the module-assistant (aka m-a) command. I adapted the instructions in this page:

[root@gao-2006]# feta install qemu-common/unstable
[root@gao-2006]# feta install qemu-source/unstable
[root@gao-2006]# m-a prepare
[root@gao-2006]# m-a build kqemu-source
[root@gao-2006]# m-a install kqemu-source
[root@gao-2006]# modprobe kqemu
[root@gao-2006]# echo kqemu >> /etc/modules

Note that I used the feta command to do the work of apt-get, as Jonathan excellently suggested 164 days ago.

I did not include the output from the above commands. Let me just say that the outputs are long, informative, upbeat, and colorful. When everything is done, I have a kqemu-modules-2.6.18-5-amd64 package built and installed, with the kqemu kernel module installed at /lib/modules/2.6.18-5-amd64/misc/kqemu.ko. A /dev/kqemu entry is created with the following characteristics:

crw-rw-rw- 1 root root 10, 62 2007-11-28 09:11 /dev/kqemu

The output of the "lsmod | grep kqemu" command indicates that the KQEMU kernal module is indeed loaded, but is not currently being used by any programs.

Downloading and compiling QEMU

I downloaded QEMU 0.9.0 source from the QEMU download page. It has the standard ./configure, make, make install installation sequence. The only peculiarity is that QEMU requires GCC 3.x and SDL library to build. This is easily fixed by installing the gcc-3.4 and libsdl-console-dev packages and their dependencies.

The configure process informs me that kqemu support is enabled.

The build process produces the following set of executables:

[root@gao /opt/qemu-0.9.0/bin]# ls
qemu        qemu-img     qemu-ppc          qemu-system-mipsel
qemu-arm    qemu-m68k    qemu-sparc        qemu-system-ppc
qemu-armeb  qemu-mips    qemu-system-arm   qemu-system-sparc
qemu-i386   qemu-mipsel  qemu-system-mips  qemu-system-x86_64

I also needed to install the texlive package and its dependencies to make the documentation.

Running QEMU in virtualizer mode

On the x86_64 platform, the kqemu module can only be activated by the qemu-system-x86_64 program. There are two command line arguments for qemu-system-x86_64 that control its behavior:

• (no argument): Only user code is executed directly; kernel code is dynamically translated
• -kernel-kqemu: Both user code and kernel code are executed directly (full vertualization mode)
• -no-kqemu: Both user code and kernel code are dynamically translated

When qemu-system-x86_64 runs, "lsmod | grep kqemu" shows that the kqemu kernel module is indeed being used:

[root@gao-2006]# lsmod | grep kqemu
kqemu                 170120  1

Benchmarks

I rerun the benchmark program inside a Debian 4.0 i386 guest OS. And the result is captured in this screenshot:

A comparison with my earlier results shows that the result of 219.0 dhrystone for QEMU in full virtualization mode is 18.4 times the 11.9 dhrystone for QEMU in emulator mode. Note that these benchmarks were run on the same physical hardware.

The benchmark result ran in the host OS is 288.6 dhrystone.