To answer my own message: On 09.01.2018 18:58, Binarus wrote: > The Seabios boot screen hangs for about a minute or so. Then the OS > (W2K8 R2 server 64 bit) hangs forever at the first screen which shows > the progress bar. By booting into safe mode, I have found out that this > happens when it tries to load the classpnp.sys driver. > > In some cases, when starting the VM, there was a message on the console > saying it was disabling IRQ 16. > > This is the point where I am lost (again). It seems I have got it to work. I have added the option "x-no-kvm-intx=on" to the device definition. My command line is now: /usr/bin/qemu-system-x86_64 -machine q35,accel=kvm -cpu host -smp cores=2,threads=2,sockets=1 -rtc base=localtime,clock=host,driftfix=none -drive file=/vm-image/dax.img,format=raw,if=virtio,cache=writeback,index=0 -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1 -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,x-no-kvm-intx=on -boot c -pidfile /root/qemu-kvm/qemu-dax.pid -m 12288 -k de -daemonize -usb -usbdevice "tablet" -name dax -device virtio-net-pci,vlan=0,mac=02:01:01:01:02:01 -net tap,vlan=0,name=dax,ifname=dax0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -vnc :2 This command line makes the Seabios hang for between 30 and 60 seconds (it seems the time it takes is not always the same) during the boot process, but then boots up the W2K8 R2 server without any issue. Within the VM, I have installed the Marvell Windows drivers for the controller's chipset. Great! And as desired, I can now cleanly "eject" the disks connected to that controller without leaving the VM, i.e. without visiting the host's console. Remaining questions: - What could make the Seabios hang for such a long time upon every boot? - Could you please shortly explain what the option "x-no-kvm-intx=on" does and why I need it in this case? - Could you please shortly explain what exactly it wants to tell me when it says that it disables INT xx, and notable if this is a bad thing I should take care of? - What about the "x-no-kvm-msi" and "x-no-kvm-msix" options? Would it be better to use them as well? I couldn't find any sound information about what exactly they do (Note: Initially, I had all three of those "x-no..." options active, which made the VM boot the first time, and later out of curiosity found out that "x-no-kvm-intx" is the essential one. Without this one, the VM won't boot; the other two don't seem to change anything in my case). - Could we expect your patch to go into upstream (perhaps after the above issues / questions have been investigated)? I will try to convince the Debian people to include the patch into 4.9; if they refuse, I will have to compile a new kernel each time they release one, which happens quite often (probably security fixes) since some time ... Thank you very much again, Binarus
