Hi there, This is another 'BSOD when installing AMD Crimson drivers under Windows' thread, but I've got a workaround for my scenario and I'm wondering how it can be improved as I think it is a bit of a cludge.
HOST ----- Core i5 2500 w/ HD2000 Gigabyte Z77X-UD5H w/ bios F14 OpenSUSE 42.1 kernel 4.1.20-11, booting with UEFI OpenSUSE KVM pattern (via YaST): -libvirt 1.2.18.2 -virt-manager 1.2.1 -QEMU 2.3.1 GUEST ----- Execution via virt-manager i440fx v2.3 based machine Windows 8.1 booting with OVMF (Gerd Hoffmann repo) Radeon R9 290 via vfio-pci <vmport state=off> element removed SCENARIO ----- If you attach the R9 290 and its HDMI audio to the virtual machine via virt-manager, only a limited set of Crimson drivers successfully install under Windows within the VM. Since playing with KVM I'd had success with Crimson 15.12 through to 16.2 beta, but since 16.3+ I've only experienced BSODs upon driver installation via the standard AMD installer. This has also been the case on another test box running kernel 4.5 and QEMU 2.4 but I'll only reference the configuration above. After searching around it appears people have had success (myself included) with the recent drivers, including 16.4.1 hotfix by attaching an ioh3420 pci-express root hub to the virtual machine, then manually assigning the video card to it. This is achieved by one of two methods 1) Use <qemu:commandline> to manually define the ioh3420 over pci and pass through the video card, for example http://serverfault.com/questions/637644/debian-jessie-qemu-kvm-gpu-passthrough-to-windows-virtual-machine-guest-virt-man Seems to work for both i440fx and Q35 2) Manually add the ioh3420 to the domain XML and bind the card to it, as per Stewart's post https://www.redhat.com/archives/vfio-users/2016-January/msg00301.html Seems to work only for Q35, the domain xml fails to validate under i440fx on both my machines. The problem with 1) as Alex has said in other posts is that <qemu:arg> hides assigned devices from libvirt, so security tools such as virt-aa-helper don't know about the definitions and hence block access to say /dev/vfio. This can be worked around by running qemu as root and unconfining the virtual machine, but this is frowned upon. I can get method 1) working under i440fx without having to modify QEMU permissions by assigning *only* the HDMI audio via virt-manager as usual and then assigning the GPU portion via virsh using <qemu:arg>. I'm assuming that this works because the HDMI audio, as it exists in the domain xml grants access to /dev/vfio with the QEMU defined portion piggybacking off it. This seems like an ugly way to solve the problem, first by defining the hardware in two places so that the security tool can allow access to the required block device from virt-manager and secondly, attaching a pci-express root port via a pci port on an i440fx chipset. Is there a neater way to get recent AMD Crimson drivers running under i440fx, assuming that an ioh3420 is required going forward? Regards, Joseph _______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
