From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDprM-0006hX-3q for qemu-devel@nongnu.org; Mon, 05 Dec 2016 04:46:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDprI-0005Ch-5p for qemu-devel@nongnu.org; Mon, 05 Dec 2016 04:46:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36382) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cDprH-0005CM-TN for qemu-devel@nongnu.org; Mon, 05 Dec 2016 04:46:52 -0500 Date: Mon, 5 Dec 2016 09:46:46 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20161205094646.GA2508@work-vm> References: <20161202174015.GE15373@work-vm> <1480926783.28320.9.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1480926783.28320.9.camel@redhat.com> Subject: Re: [Qemu-devel] Postcopy+spice crash List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, spice-devel * Gerd Hoffmann (kraxel@redhat.com) wrote: > On Fr, 2016-12-02 at 17:44 +0000, Dr. David Alan Gilbert wrote: > > Hi Gerd, > > I've got a moderately repeatable crash with spice playing > > a video + postcopy. Some of the time I just get a warning > > (that I also get in precopy) but sometimes it turns into > > a backtrace; > >=20 > > This is: > > f24 guest playing youtube fullscreen. > > migration between 2.7.0<->current head (had crash both ways) > >=20 > > The warning I get with precopy most of the time is: > > ./x86_64-softmmu/qemu-system-x86_64:26921): Spice-Warning **: red_mem= slots.c:94:validate_virt: virtual address out of range >=20 > That is in spice-server. Which version do you run? =46rom the bottom of the post; spice-server-devel-0.12.4-19.el7.x86_64 (rhe= l 7) > Adding spice-devel to Cc: >=20 > > virt=3D0x7f5397ed002a+0x2925ff31 slot_id=3D1 group_id=3D1 > > slot=3D0x7f5397c00000-0x7f539bbfe000 delta=3D0x7f5397c00000 >=20 > Base address looks sane. > Size (0x2925ff31) is bogous. >=20 > On a quick glance I'd blame the guest for sending corrupted commands. > Strange though that it happens on migration only, so there could be > a host issue too. Or a timing issue triggered by migration. >=20 > Which migration phase? This is the point at which it switches over in postcopy. > Do you have seamless spice migration enabled? > If so: Does it still reproduce with seamless migration turned off? No I don't think so; I think the command line I was running was: =2E/x86_64-softmmu/qemu-system-x86_64 -vnc :0 -M pc-i440fx-2.7,accel=3Dkvm = -monitor stdio -netdev user,id=3Dunet,hostfwd=3Dtcp::2022-:22,hostfwd=3Dtcp= ::2023-:2022 -device virtio-net-pci,netdev=3Dunet -drive file=3D/home/vms/f= 24.qcow2,cache=3Dnone,id=3Ddisk,if=3Dnone -device virtio-blk-pci,drive=3Dd= isk -device virtio-balloon -vga qxl -device ich9-usb-ehci1 -device usb-tabl= et,id=3Din0 -device virtio-rng-pci -device AC97 -m 8192 -smp 4 -drive file= =3D/home/vms/Fedora-Server-netinst-x86_64-23.iso,cache=3Dnone,id=3Dcd,if=3D= scsi -incoming tcp::4444 > > The crash I've had with postcopy is: > > red_dispatcher_loadvm_commands: > > id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, d= elta 0 > > id 1, group 1, virt start 7fbe83c00000, virt end 7fbe87bfe000, generati= on 0, delta 7fbe83c00000 > > id 2, group 1, virt start 7fbe7fa00000, virt end 7fbe83a00000, generati= on 0, delta 7fbe7fa00000 > > (./x86_64-softmmu/qemu-system-x86_64:22376): Spice-CRITICAL **: red_mem= slots.c:123:get_virt: slot_id 128 too big, addr=3D8000000000000000 > >=20 > > #0 0x00007fc0aa42f49d in read () from /lib64/libpthread.so.0 > > #1 0x00007fc0a8c36c01 in spice_backtrace_gstack () from /lib64/libspic= e-server.so.1 > > #2 0x00007fc0a8c3e4f7 in spice_logv () from /lib64/libspice-server.so.1 > > #3 0x00007fc0a8c3e655 in spice_log () from /lib64/libspice-server.so.1 > > #4 0x00007fc0a8bfc6de in get_virt () from /lib64/libspice-server.so.1 > > #5 0x00007fc0a8bfcb73 in red_get_data_chunks_ptr () from /lib64/libspi= ce-server.so.1 > > #6 0x00007fc0a8bff3fa in red_get_cursor_cmd () from /lib64/libspice-se= rver.so.1 > > #7 0x00007fc0a8c0fd79 in handle_dev_loadvm_commands () from /lib64/lib= spice-server.so.1 > > #8 0x00007fc0a8bf9523 in dispatcher_handle_recv_read () from /lib64/li= bspice-server.so.1 > > #9 0x00007fc0a8c1d5a5 in red_worker_main () from /lib64/libspice-serve= r.so.1 > > #10 0x00007fc0aa428dc5 in start_thread () from /lib64/libpthread.so.0 > > #11 0x00007fc0a61786ed in clone () from /lib64/libc.so.6 >=20 > Spice worker thread ... >=20 > > red_dispatcher_loadvm_commands: > > id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0, d= elta 0 > > id 1, group 1, virt start 7f3b93800000, virt end 7f3b977fe000, generati= on 0, delta 7f3b93800000 > > id 2, group 1, virt start 7f3b8f400000, virt end 7f3b93400000, generati= on 0, delta 7f3b8f400000 > > (/opt/qemu/v2.7.0/bin/qemu-system-x86_64:41053): Spice-CRITICAL **: red= _memslots.c:123:get_virt: slot_id 80 too big, addr=3D5000000000000000 >=20 >=20 > ... trying to decode a invalid qxl address. Yes one observation is that I think a few (all?) of the bad addresses I've seen there have been a single nybble followed by a lot of 0's. > > I'm using: > > spice-server-devel-0.12.4-19.el7.x86_64 >=20 > Ah, RHEL-7.3 host. >=20 > cheers, > Gerd >=20 Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK