From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philipp Hahn Subject: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2 Date: Thu, 17 Feb 2011 11:44:33 +0100 Message-ID: <201102171144.34169.hahn@univention.de> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14122420.2pymEUIdKZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from mail.univention.de ([82.198.197.8]:2512 "EHLO mail.univention.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751993Ab1BQKye (ORCPT ); Thu, 17 Feb 2011 05:54:34 -0500 Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id B777467AF03 for ; Thu, 17 Feb 2011 11:44:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by slugis.knut.univention.de (Postfix) with ESMTP id AD28F67AF04 for ; Thu, 17 Feb 2011 11:44:35 +0100 (CET) Received: from mail.univention.de ([127.0.0.1]) by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7mBNhlbtYsT for ; Thu, 17 Feb 2011 11:44:35 +0100 (CET) Received: from stave.knut.univention.de (stave.knut.univention.de [192.168.0.191]) by slugis.knut.univention.de (Postfix) with ESMTPSA id 4854067AF03 for ; Thu, 17 Feb 2011 11:44:35 +0100 (CET) Sender: kvm-owner@vger.kernel.org List-ID: --nextPart14122420.2pymEUIdKZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on an Deb= ian=20 based system using AMD64 CPUs. During the install, the system froze (progre= ss=20 bar didn't advance) and kvm was slowly eating CPU cycles on the host. $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` libvirt0 0.8.7-1.48.201102031226 linux-image-2.6.32-ucs37-amd64 2.6.32-30.37.201102031101 qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432 It was started using virsh, which generated the following command line: /usr/bin/kvm.bin -S \ -M pc-0.12 \ -enable-kvm \ -m 768 \ -smp 1,sockets=3D1,cores=3D1,threads=3D1 \ -name 7-Professional_amd64 \ -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ -nodefaults \ -chardev socket,id=3Dmonitor,path=3D/var/lib/libvirt/qemu/7-Professional_amd64.monit= or,server,nowait \ -mon chardev=3Dmonitor,mode=3Dreadline \ -rtc base=3Dutc \ -boot dc \ -drive file=3D/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=3Dnone,id=3Ddr= ive-virtio-disk0,boot=3Don,format=3Dqcow2 =2Ddevice virtio-blk-pci,bus=3Dpci.0,addr=3D0x5,drive=3Ddrive-virtio-disk0,id=3Dvirti= o-disk0 \ -drive file=3D/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=3Dnone,medi= a=3Dcdrom,id=3Ddrive-ide0-0-1,readonly=3Don,format=3Draw =2Ddevice ide-drive,bus=3Dide.0,unit=3D1,drive=3Ddrive-ide0-0-1,id=3Dide0-0= =2D1 \ -drive file=3D/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=3Dnone,med= ia=3Dcdrom,id=3Ddrive-ide0-1-0,readonly=3Don,format=3Draw =2Ddevice ide-drive,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1= =2D0 \ -device=20 virtio-net-pci,vlan=3D0,id=3Dnet0,mac=3D52:54:00:f7:da:b5,bus=3Dpci.0,addr= =3D0x3 \ -net tap,fd=3D20,vlan=3D0,name=3Dhostnet0 \ -usb \ -device usb-tablet,id=3Dinput0 \ -vnc 0.0.0.0:0 \ -k de \ -vga cirrus \ -incoming exec:cat \ -device virtio-balloon-pci,id=3Dballoon0,bus=3Dpci.0,addr=3D0x4 \ -no-kvm-irqchip The "-no-kvm-irqchip"-Option was added, because we experienced shutdown/res= ume=20 problems with other machines, which either received no interrupts anymore o= r=20 where caught in their interrupt service routine, never being able to=20 acknowledge the interrupts. Adding that option solved that problem, but mig= ht=20 be causing other problems now. Using gdb I was able to track down Windows hanging in the following routine= ,=20 which look like some spin-lock / semaphore aquire() implementation: (gdb) x/20i 0xfffff8000c485a80 0xfffff8000c485a80: mov %rbx,0x8(%rsp) 0xfffff8000c485a85: push %rdi 0xfffff8000c485a86: sub $0x20,%rsp 0xfffff8000c485a8a: mov %rcx,%rdi 0xfffff8000c485a8d: xor %ebx,%ebx 0xfffff8000c485a8f: nop 0xfffff8000c485a90: inc %ebx 0xfffff8000c485a92: test %ebx,0x274834(%rip) # 0xfffff8000c6fa= 2cc 0xfffff8000c485a98: je 0xfffff8000c48adad 0xfffff8000c485a9e: pause 0xfffff8000c485aa0: mov (%rdi),%rcx 0xfffff8000c485aa3: test %rcx,%rcx 0xfffff8000c485aa6: jne 0xfffff8000c485a90 0xfffff8000c485aa8: lock btsq $0x0,(%rdi) 0xfffff8000c485aae: jb 0xfffff8000c485a90 0xfffff8000c485ab0: mov %ebx,%eax 0xfffff8000c485ab2: mov 0x30(%rsp),%rbx 0xfffff8000c485ab7: add $0x20,%rsp 0xfffff8000c485abb: pop %rdi 0xfffff8000c485abc: retq (gdb) x/w 0xfffff8000c6fa2cc 0xfffff8000c6fa2cc: 0xffffffff (gdb) x/w $rdi 0xfffffa800131f600: 0x00000001 Did someone experience similar problems or does somebody know if there was = a=20 fix for such a problem in newer kvm- or Linux-kernel versions? We also encountered problems with some Windows Versions when using VirtIO w= ith=20 Qcow2 images, which were using backing-files for copy-on-write: they just=20 crashed with a blue-screen. Just changing from the CoW-qcow2 to the=20 master-qcow2 file "fixed" the problem, but this isn't satisfactory, since w= e=20 would like to use the CoW-functionality. Not using VirtIO also fixed the=20 problem, but has performance penalties. Any help or comment is appreciated. BYtE Philipp =2D-=20 Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ ** Besuchen Sie uns auf der CeBIT in Hannover ** ** Auf dem Univention Stand D36 in Halle 2 ** ** Vom 01. bis 05. M=E4rz 2011 ** --nextPart14122420.2pymEUIdKZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAk1c/BIACgkQYPlgoZpUDjnacwCglsMtuqpQUVpwEzO9dD5V0GUz AdUAoK1jvEMIq2Buq0EhdlE0I5WgMtuy =lKHu -----END PGP SIGNATURE----- --nextPart14122420.2pymEUIdKZ--