[Qemu-devel] [Bug 899961] Re: qemu/kvm locks up when run 32bit userspace with 64bit kernel

[Michael Tokarev]

I tried bisecting it today, again.  I think you did mean
145e11e840500e04a4d0a624918bb17596be19e9 as the "M" point (the large
merge), not b195043003d90ea4027ea01cc7a6c974ac915108 (which is the first
commit in that merge) ;)  Actually I did the same already, just didn't
post to the bugreport.  But anyway.

The first bad commit inside the merge which shows the bad behavour is:

commit 68d100e905453ebbeea8e915f4f18a2bd4339fe8
Author: Kevin Wolf <address@hidden>
Date:   Thu Jun 30 17:42:09 2011 +0200

    qcow2: Use coroutines

Note: the issue happens only with qcow2 being in use so far, directly or
indirectly with -snapshot.

Also note that it only happens within kvm tree, ie:

 git checkout 68d100e905453ebbeea8e915f4f18a2bd4339fe8
 git merge --no-commit 145e11e840500e04a4d0a624918bb17596be19e9^  # the 
pre-merge point

I tried to debug it further but without much success.

I'm attaching an strace the above source (with a few debug
fprintf(stderr)s added into qcow2 source around lock/unlock calls)
running winXP guest from point where I hit "Reboot" button and up to the
point where it stalls.  Search for "qcow2: mutex_unlock" from the _end_
of the file.

What I also observed is -- it looks like it merely loses an interrupt
somewere, it is enough to Ctrl+Z/fg it or to attach/detach strace to the
process for it to "unstuck" and continue executing.  Attaching gdb also
makes it unstuck as demonstrated initially.

This qcow2 commit may actually be innocent: it just started using
coroutines, and that's where the bug/problem might be, say, 64bit kernel
gets confused by the process switching stack for example?  I dunno.

Note again that switching to alternative coroutine implementations makes
the issue go away.  Ie, it only happens with mkcontext&Co coroutine
implementation, and the commit which git bisect found to be "guilty" is
the one which makes usage of coroutines.


** Attachment added: "strace of the kvm process before it gets stuck"
   https://bugs.launchpad.net/qemu/+bug/899961/+attachment/2877301/+files/trc

-- 
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