From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2 Date: Thu, 17 Feb 2011 13:41:04 +0200 Message-ID: <20110217114104.GA24753@redhat.com> References: <201102171144.34169.hahn@univention.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Philipp Hahn , kvm@vger.kernel.org, Vadim Rozenfeld To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40087 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752352Ab1BQLlL convert rfc822-to-8bit (ORCPT ); Thu, 17 Feb 2011 06:41:11 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Feb 17, 2011 at 11:30:25AM +0000, Stefan Hajnoczi wrote: > On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn w= rote: > > Hello, > > > > I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 o= n an Debian > > based system using AMD64 CPUs. During the install, the system froze= (progress > > bar didn't advance) and kvm was slowly eating CPU cycles on the hos= t. > > > > $ dpkg-query -W libvirt0 qemu-kvm linux-image-`uname -r` > > libvirt0 =9A =9A =9A =9A0.8.7-1.48.201102031226 > > linux-image-2.6.32-ucs37-amd64 =9A2.6.32-30.37.201102031101 > > qemu-kvm =9A =9A =9A =9A0.12.4+dfsg-1~bpo50+1.3.201010011432 > > > > It was started using virsh, which generated the following command l= ine: > > /usr/bin/kvm.bin -S \ > > =9A-M pc-0.12 \ > > =9A-enable-kvm \ > > =9A-m 768 \ > > =9A-smp 1,sockets=3D1,cores=3D1,threads=3D1 \ > > =9A-name 7-Professional_amd64 \ > > =9A-uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ > > =9A-nodefaults \ > > =9A-chardev > > socket,id=3Dmonitor,path=3D/var/lib/libvirt/qemu/7-Professional_amd= 64.monitor,server,nowait > > \ > > =9A-mon chardev=3Dmonitor,mode=3Dreadline \ > > =9A-rtc base=3Dutc \ > > =9A-boot dc \ > > =9A-drive > > file=3D/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=3Dnone= ,id=3Ddrive-virtio-disk0,boot=3Don,format=3Dqcow2 > > -device > > virtio-blk-pci,bus=3Dpci.0,addr=3D0x5,drive=3Ddrive-virtio-disk0,id= =3Dvirtio-disk0 \ > > =9A-drive > > file=3D/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=3Dn= one,media=3Dcdrom,id=3Ddrive-ide0-0-1,readonly=3Don,format=3Draw > > -device ide-drive,bus=3Dide.0,unit=3D1,drive=3Ddrive-ide0-0-1,id=3D= ide0-0-1 \ > > =9A-drive > > file=3D/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=3D= none,media=3Dcdrom,id=3Ddrive-ide0-1-0,readonly=3Don,format=3Draw > > -device ide-drive,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3D= ide0-1-0 \ > > =9A-device > > virtio-net-pci,vlan=3D0,id=3Dnet0,mac=3D52:54:00:f7:da:b5,bus=3Dpci= =2E0,addr=3D0x3 > > \ > > =9A-net tap,fd=3D20,vlan=3D0,name=3Dhostnet0 \ > > =9A-usb \ > > =9A-device usb-tablet,id=3Dinput0 \ > > =9A-vnc 0.0.0.0:0 \ > > =9A-k de \ > > =9A-vga cirrus \ > > =9A-incoming exec:cat \ > > =9A-device virtio-balloon-pci,id=3Dballoon0,bus=3Dpci.0,addr=3D0x4 = \ > > =9A-no-kvm-irqchip > > > > The "-no-kvm-irqchip"-Option was added, because we experienced shut= down/resume > > problems with other machines, which either received no interrupts a= nymore or > > where caught in their interrupt service routine, never being able t= o > > acknowledge the interrupts. Adding that option solved that problem,= but might > > be causing other problems now. > > > > Using gdb I was able to track down Windows hanging in the following= routine, > > which look like some spin-lock / semaphore aquire() implementation: > > (gdb) x/20i 0xfffff8000c485a80 > > 0xfffff8000c485a80: =9A =9A mov =9A =9A%rbx,0x8(%rsp) > > 0xfffff8000c485a85: =9A =9A push =9A %rdi > > 0xfffff8000c485a86: =9A =9A sub =9A =9A$0x20,%rsp > > 0xfffff8000c485a8a: =9A =9A mov =9A =9A%rcx,%rdi > > 0xfffff8000c485a8d: =9A =9A xor =9A =9A%ebx,%ebx > > 0xfffff8000c485a8f: =9A =9A nop > > 0xfffff8000c485a90: =9A =9A inc =9A =9A%ebx > > 0xfffff8000c485a92: =9A =9A test =9A %ebx,0x274834(%rip) =9A =9A =9A= =9A# 0xfffff8000c6fa2cc > > 0xfffff8000c485a98: =9A =9A je =9A =9A 0xfffff8000c48adad > > 0xfffff8000c485a9e: =9A =9A pause > > 0xfffff8000c485aa0: =9A =9A mov =9A =9A(%rdi),%rcx > > 0xfffff8000c485aa3: =9A =9A test =9A %rcx,%rcx > > 0xfffff8000c485aa6: =9A =9A jne =9A =9A0xfffff8000c485a90 > > 0xfffff8000c485aa8: =9A =9A lock btsq $0x0,(%rdi) > > 0xfffff8000c485aae: =9A =9A jb =9A =9A 0xfffff8000c485a90 > > 0xfffff8000c485ab0: =9A =9A mov =9A =9A%ebx,%eax > > 0xfffff8000c485ab2: =9A =9A mov =9A =9A0x30(%rsp),%rbx > > 0xfffff8000c485ab7: =9A =9A add =9A =9A$0x20,%rsp > > 0xfffff8000c485abb: =9A =9A pop =9A =9A%rdi > > 0xfffff8000c485abc: =9A =9A retq > > (gdb) x/w 0xfffff8000c6fa2cc > > 0xfffff8000c6fa2cc: =9A =9A 0xffffffff > > (gdb) x/w $rdi > > 0xfffffa800131f600: =9A =9A 0x00000001 > > > > Did someone experience similar problems or does somebody know if th= ere was a > > fix for such a problem in newer kvm- or Linux-kernel versions? > > > > We also encountered problems with some Windows Versions when using = VirtIO with > > Qcow2 images, which were using backing-files for copy-on-write: the= y just > > crashed with a blue-screen. Just changing from the CoW-qcow2 to the > > master-qcow2 file "fixed" the problem, but this isn't satisfactory,= since we > > would like to use the CoW-functionality. Not using VirtIO also fixe= d the > > problem, but has performance penalties. >=20 > Vadim: Any suggestions for extracting more relevant information in th= ese cases? >=20 > One option may might be to set up the Windows debugger in order to > closely monitor what the guest is doing when it hangs or BSODs: > http://etherboot.org/wiki/sanboot/winnt_iscsi_debug >=20 Why is is linked to virtio? Does install on ide work? Does install work without -no-kvm-irqchip (which had pretty serious problem till now)? Adding -no-kvm-irqchip usually does not solve problems, but just exchange one set of bugs to the other (and reduces performance drastically). -- Gleb.