Re: RFH: Windos 7 64 + VirtIO stalls during installation / crashed with qcow2

Stefan Hajnoczi
2011-02-17T14:26:34Z

On Thu, Feb 17, 2011 at 12:45 PM, Vadim Rozenfeld <vrozenfe@redhat.com> 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@univention.de> 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?

Stefan