After some more digging I found out that qemu also has this very issue,
but it happens a bit differently. In particular, this very same winXP
test guest freezes in upstream qemu with -enable-kvm on _shutdown_, not
on restart. In qemu-kvm it happens on restart but not on shutdown.
And bisecting plain qemu leads to this commit:
commit 12d4536f7d911b6d87a766ad7300482ea663cea2
Author: Anthony Liguori <aligu...@us.ibm.com>
Date: Mon Aug 22 08:24:58 2011 -0500
main: force enabling of I/O thread
As far as I remember, qemu-kvm always had iothread enabled, that's why the bug
initially was only reproducible on qemu-kvm.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/899961
Title:
qemu/kvm locks up when run 32bit userspace with 64bit kernel
Status in QEMU:
New
Status in “qemu-kvm” package in Debian:
Confirmed
Bug description:
Only applies to qemu-kvm 1.0, and only when kernel is 64bit and
userspace is 32bit, on x86. Did not happen with previous released
versions, such as 0.15. Not all guests triggers this issue - so far,
only (32bit) windows 7 guest shows it, but does that quite reliable:
first boot of an old guest with new qemu-kvm, windows finds a new CPU
and suggests rebooting - hit "Reboot" and in a few seconds it will be
locked up (including the monitor), with no CPU usage whatsoever.
Killable only with -9.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/899961/+subscriptions
