From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59804 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtJGt-0000jm-OJ for qemu-devel@nongnu.org; Sat, 26 Feb 2011 07:29:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtJGo-00052h-Jg for qemu-devel@nongnu.org; Sat, 26 Feb 2011 07:29:15 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:39279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtJGo-00052I-1m for qemu-devel@nongnu.org; Sat, 26 Feb 2011 07:29:10 -0500 Message-ID: <4D68F20D.2020401@web.de> Date: Sat, 26 Feb 2011 13:29:01 +0100 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD119AE96311102765C65D1F" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: kvm crashes with spice while loading qxl List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xming , Gerd Hoffmann Cc: qemu-devel , kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD119AE96311102765C65D1F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-02-26 12:43, xming wrote: > When trying to start X (and it loads qxl driver) the kvm process just c= rashes. >=20 > qemu-kvm 0.14 >=20 > startup line >=20 > /usr/bin/kvm -name spaceball,process=3Dspaceball -m 1024 -kernel > /boot/bzImage-2.6.37.2-guest -append "root=3D/dev/vda ro" -smp 1 -netde= v > type=3Dtap,id=3Dspaceball0,script=3Dkvm-ifup-brloc,vhost=3Don -device > virtio-net-pci,netdev=3Dspaceball0,mac=3D00:16:3e:00:08:01 -drive > file=3D/dev/volume01/G-spaceball,if=3Dvirtio -vga qxl -spice > port=3D5957,disable-ticketing -monitor > telnet:192.168.0.254:10007,server,nowait,nodelay -pidfile > /var/run/kvm/spaceball.pid >=20 > host is running vanilla 2.6.37.1 on amd64. >=20 > Here is the bt >=20 > # gdb /usr/bin/qemu-system-x86_64 > GNU gdb (Gentoo 7.2 p1) 7.2 > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copyi= ng" > and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > For bug reporting instructions, please see: > ... > Reading symbols from /usr/bin/qemu-system-x86_64...done. > (gdb) set args -name spaceball,process=3Dspaceball -m 1024 -kernel > /boot/bzImage-2.6.37.2-guest -append "root=3D/dev/vda ro" -smp 1 -netde= v > type=3Dtap,id=3Dspaceball0,script=3Dkvm-ifup-brloc,vhost=3Don -device > virtio-net-pci,netdev=3Dspaceball0,mac=3D00:16:3e:00:08:01 -drive > file=3D/dev/volume01/G-spaceball,if=3Dvirtio -vga qxl -spice > port=3D5957,disable-ticketing -monitor > telnet:192.168.0.254:10007,server,nowait,nodelay -pidfile > /var/run/kvm/spaceball.pid > (gdb) run > Starting program: /usr/bin/qemu-system-x86_64 -name > spaceball,process=3Dspaceball -m 1024 -kernel > /boot/bzImage-2.6.37.2-guest -append "root=3D/dev/vda ro" -smp 1 -netde= v > type=3Dtap,id=3Dspaceball0,script=3Dkvm-ifup-brloc,vhost=3Don -device > virtio-net-pci,netdev=3Dspaceball0,mac=3D00:16:3e:00:08:01 -drive > file=3D/dev/volume01/G-spaceball,if=3Dvirtio -vga qxl -spice > port=3D5957,disable-ticketing -monitor > telnet:192.168.0.254:10007,server,nowait,nodelay -pidfile > /var/run/kvm/spaceball.pid > [Thread debugging using libthread_db enabled] > do_spice_init: starting 0.6.0 > spice_server_add_interface: SPICE_INTERFACE_KEYBOARD > spice_server_add_interface: SPICE_INTERFACE_MOUSE > [New Thread 0x7ffff4802710 (LWP 30294)] > spice_server_add_interface: SPICE_INTERFACE_QXL > [New Thread 0x7fffaacae710 (LWP 30295)] > red_worker_main: begin > handle_dev_destroy_surfaces: > handle_dev_destroy_surfaces: > handle_dev_input: start > [New Thread 0x7fffaa4ad710 (LWP 30298)] > [New Thread 0x7fffa9cac710 (LWP 30299)] > [New Thread 0x7fffa94ab710 (LWP 30300)] > [New Thread 0x7fffa8caa710 (LWP 30301)] > [New Thread 0x7fffa3fff710 (LWP 30302)] > [New Thread 0x7fffa37fe710 (LWP 30303)] > [New Thread 0x7fffa2ffd710 (LWP 30304)] > [New Thread 0x7fffa27fc710 (LWP 30305)] > [New Thread 0x7fffa1ffb710 (LWP 30306)] > [New Thread 0x7fffa17fa710 (LWP 30307)] > reds_handle_main_link: > reds_show_new_channel: channel 1:0, connected successfully, over Non Se= cure link > reds_main_handle_message: net test: latency 5.636000 ms, bitrate > 11027768 bps (10.516899 Mbps) > reds_show_new_channel: channel 2:0, connected successfully, over Non Se= cure link > red_dispatcher_set_peer: > handle_dev_input: connect > handle_new_display_channel: jpeg disabled > handle_new_display_channel: zlib-over-glz disabled > reds_show_new_channel: channel 4:0, connected successfully, over Non Se= cure link > red_dispatcher_set_cursor_peer: > handle_dev_input: cursor connect > reds_show_new_channel: channel 3:0, connected successfully, over Non Se= cure link > inputs_link: > [New Thread 0x7fffa07f8710 (LWP 30312)] > [New Thread 0x7fff9fff7710 (LWP 30313)] > [New Thread 0x7fff9f7f6710 (LWP 30314)] > [New Thread 0x7fff9eff5710 (LWP 30315)] > [New Thread 0x7fff9e7f4710 (LWP 30316)] > [New Thread 0x7fff9dff3710 (LWP 30317)] > [New Thread 0x7fff9d7f2710 (LWP 30318)] > qemu-system-x86_64: > /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.14.0/qem= u-kvm.c:1724: > kvm_mutex_unlock: Assertion `!cpu_single_env' failed. >=20 > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x7ffff4802710 (LWP 30294)] > 0x00007ffff5daa165 in raise () from /lib/libc.so.6 > (gdb) > (gdb) > (gdb) > (gdb) > (gdb) bt > #0 0x00007ffff5daa165 in raise () from /lib/libc.so.6 > #1 0x00007ffff5dab580 in abort () from /lib/libc.so.6 > #2 0x00007ffff5da3201 in __assert_fail () from /lib/libc.so.6 > #3 0x0000000000436f7e in kvm_mutex_unlock () > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/qemu-kvm.c:1724 > #4 qemu_mutex_unlock_iothread () > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/qemu-kvm.c:1737 > #5 0x00000000005e84ee in qxl_hard_reset (d=3D0x15d3080, loadvm=3D0) > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/hw/qxl.c:665 > #6 0x00000000005e9f9a in ioport_write (opaque=3D0x15d3080, addr=3D optimized out>, val=3D0) > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/hw/qxl.c:979 > #7 0x0000000000439d4e in kvm_handle_io (env=3D0x11a3e00) > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/kvm-all.c:818 > #8 kvm_run (env=3D0x11a3e00) > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/qemu-kvm.c:617 > #9 0x0000000000439f79 in kvm_cpu_exec (env=3D0x764b) > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/qemu-kvm.c:1233 > #10 0x000000000043b2d7 in kvm_main_loop_cpu (_env=3D0x11a3e00) > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/qemu-kvm.c:1419 > #11 ap_main_loop (_env=3D0x11a3e00) > at /var/tmp/portage/app-emulation/qemu-kvm-0.14.0/work/qemu-kvm-0.1= 4.0/qemu-kvm.c:1466 > #12 0x00007ffff77bb944 in start_thread () from /lib/libpthread.so.0 > #13 0x00007ffff5e491dd in clone () from /lib/libc.so.6 > (gdb) That's a spice bug. In fact, there are a lot of qemu_mutex_lock/unlock_iothread in that subsystem. I bet at least a few of them can cause even more subtle problems. Two general issues with dropping the global mutex like this: - The caller of mutex_unlock is responsible for maintaining cpu_single_env across the unlocked phase (that's related to the abort above). - Dropping the lock in the middle of a callback is risky. That may enable re-entrances of code sections that weren't designed for this (I'm skeptic about the side effects of qemu_spice_vm_change_state_handler - why dropping the lock here?). Spice requires a careful review regarding such issues. Or it should pioneer with introducing its own lock so that we can handle at least related I/O activities over the VCPUs without holding the global mutex (but I bet it's not the simplest candidate for such a new scheme). Jan --------------enigBD119AE96311102765C65D1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1o8hIACgkQitSsb3rl5xTguQCgkng/rNv1tOf2WuweWDnS7yxb GwoAniLcK65Esx7yHdwoR7R8ogkMFrw6 =6RYx -----END PGP SIGNATURE----- --------------enigBD119AE96311102765C65D1F--