On Thu, 2011-02-17 at 14:26 +0000, Stefan Hajnoczi wrote: > On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld <vrozenfe@xxxxxxxxxx> wrote: > > On Thu, 2011-02-17 at 13:41 +0200, Gleb Natapov wrote: > >> On Thu, Feb 17, 2011 at 11:30:25AM +0000, Stefan Hajnoczi wrote: > >> > On Thu, Feb 17, 2011 at 10:44 AM, Philipp Hahn <hahn@xxxxxxxxxxxxx> wrote: > >> > > Hello, > >> > > > >> > > I tried to install Windows 7 Professional 64 Bit with VirtIO 1.16 on 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 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=1,cores=1,threads=1 \ > >> > > -name 7-Professional_amd64 \ > >> > > -uuid 89c82cf9-0797-3da4-62f4-8767e4f59b7e \ > >> > > -nodefaults \ > >> > > -chardev > >> > > socket,id=monitor,path=/var/lib/libvirt/qemu/7-Professional_amd64.monitor,server,nowait > >> > > \ > >> > > -mon chardev=monitor,mode=readline \ > >> > > -rtc base=utc \ > >> > > -boot dc \ > >> > > -drive > >> > > file=/var/lib/libvirt/images/7-Professional_amd64.qcow2,if=none,id=drive-virtio-disk0,boot=on,format=qcow2 > >> > > -device > >> > > virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ > >> > > -drive > >> > > file=/mnt/omar/vmwares/kvm/iso/windows/win_7_pro_64bit.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw > >> > > -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \ > >> > > -drive > >> > > file=/mnt/omar/vmwares/kvm/iso/others/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw > >> > > -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ > >> > > -device > >> > > virtio-net-pci,vlan=0,id=net0,mac=52:54:00:f7:da:b5,bus=pci.0,addr=0x3 > >> > > \ > >> > > -net tap,fd=20,vlan=0,name=hostnet0 \ > >> > > -usb \ > >> > > -device usb-tablet,id=input0 \ > >> > > -vnc 0.0.0.0:0 \ > >> > > -k de \ > >> > > -vga cirrus \ > >> > > -incoming exec:cat \ > >> > > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \ > >> > > -no-kvm-irqchip > >> > > > >> > > The "-no-kvm-irqchip"-Option was added, because we experienced shutdown/resume > >> > > problems with other machines, which either received no interrupts anymore or > >> > > where caught in their interrupt service routine, never being able to > >> > > 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: 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) # 0xfffff8000c6fa2cc > >> > > 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 > >> > > 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: they 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 fixed the > >> > > problem, but has performance penalties. > >> > > >> > Vadim: Any suggestions for extracting more relevant information in these cases? > > Debugging installation-phase problems on 64-bit platforms is a very > > complicated thing. If the problem is reproducible on x86 platforms, you > > can try printing messages (RhelDbgPrint function) to localize the > > problem. You will need to adjust RhelDbgLevel in virtio_stor.c and build > > checked (debug) version of the driver. > > Is that even possible - I thought these drivers need to be signed on > recent versions of Windows? only 64-bit versions of Windows Vista and later require kernel mode code signing (KMCS) in order to load kernel-mode software. > > Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
