[Qemu-devel] Crashes while emulating x86_64 with kqemu: details and workaround

[J.P. Larocque]

Hi,

I've seen that this issue has been brought up in the past, with little
discussion on a resolution.  To express that I would be interested in
a resolution, and to provide hopefully-useful details, I'm sharing my
experiences with emulating x86_64 machines running Linux with kqemu.

My host machine runs Debian Etch, with the linux-image-2.6.18-3-amd64
2.6.18-7 kernel package installed.  This kernel was compiled with GCC
4.1.2.

Prior to trying kqemu, I ran several instances of qemu-system-x86_64
simultaneously without a hitch (besides performance).  These were all
running Linux 2.6.

With kqemu, most of the VMs crash.  At least one of them crashed
consistently in the same place in its boot process; I've attached a
boot log, which includes the exact command used to invoke qemu[1], all
standard output and standard error output from qemu, and all console
output from the emulated Linux system.  The boot script in effect at
the point of the crash was modified to echo all commands prior to
execution (set -x).

Other VMs crashed at unrelated points in the boot process; the systems
in these VMs differed greatly in configuration from the reference VM,
though.

Upon the crash of qemu, the host kernel printed the following message,
which seems to be consistent for me whenever qemu crashes under these
circumstances:

--->8--->8---
kqemu: aborting: Unexpected exception 0x0d in monitor space
err=0000 CS:EIP=f180:00000000f0002806 SS:SP=0000:00000000f00c7e60
---8<---8<---

I did notice one VM, running an old kernel, is not affected.  I've
determined that 2.6.15.7 is the latest version of the Linux kernel I
can use on a qemu x86_64 VM running with kqemu; 2.6.16-rc1 and later
will crash qemu.  Therefore, the workaround for those wishing to run
Linux on qemu-system-x86_64 with kqemu is to use 2.6.15.7.

Also attached is a copy of the .config file for one kernel I built and
tried, version 2.6.16.38, in-case it aids in reproducing the problem.

Even with kqemu, things aren't tremendously fast: subjectively, things
seem faster than without kqemu.  I don't have a good benchmark yet,
but I do have a highly anecdotal and unscientific example of how bad
the performance of my current configuration with kqemu is: a network
transfer, received with netcat and written to disk yielded ~800KB/s
throughput for the first couple of minutes, which is when I aborted.
(After shutting down the VM,) a transfer of the same file, from the same
source system, to the same filesystem, with the same tools yielded
about 8MB/s (+/- 1MB/s) through the entire transmission.

I'm happy to help by providing further details or testing certain
configurations or certain patches.  Thanks,

1. QEMU_TMPDIR=/tmp is on the environment (not reflected in the log).
On my host, /tmp is a large tmpfs filesystem.

-- 
J.P. Larocque: <address@hidden>, <address@hidden>

qemu_crash.txt
Description: Text document

config-2.6.16.38.txt
Description: Text document