xuare

Awesome! I am using OVMF / UEFI. I have to because of i915 Intel graphics for host--otherwise have VGA arbiter issues and need to patch the kernel. No issues to date (that are graphics related anyway). I will also add that my HDMI audio seems more stable under AMD than nVidia, but that may just be perception on my part...

If you go with a NVIDIA card, you accept the risk that nVidia has been trying to force anyone who uses PCI Passthrough with something other than a $1K Quattro is violating their TOS. They have numerous things they have put in their Windows drivers to make it not work (for instance, you can't tell windows to use any of the HyperV extensions that optimize Windows in a VM). What they do in the future is unknown, but combined with Windows 10's mandatory updates, you may not be able to control what that is or when it will affect you. A little headache to avoid that and get better performance with AMD was, for me, worth it. EDIT: AMD is contributing to a completely open source driver which is now in the mainline Linux kernel tree (the AMDGPU driver). Due to this, I would not expect such hi-jinks in the future from AMD. Heck, perhaps they will even get the AMDGPU driver to gracefully release from the host for use in the VM in the future!

Continuation of https://lime-technology.com/forum/index.php?topic=50086.msg508457#msg508457 After a recent emerge libvirt was updated to 2.3 and qemu to 2.7. Once these were in place the VM would no longer show up in virt-manager. I found out that simply setting the machine back to i440fx and switching the pcie-root to pci-root is no longer sufficient. All of the other bridge devices (I had an additional dmi-to-pci bridge and a pci-bridge) had to be removed [these are pcie to pci type devices and a bug was probably fixed so they are not handled or silently ignored under i440fx anymore]. Once this change was made I had to: 1) boot the VM, go into the OVMF SeaBIOS and resave the OVMF configuration (despite making no changes). 2) Reboot the VM and load Windows. Once Windows was up it took some time to rediscover all the pci-passthrough devices (~ 5 min) and find the apply the appropriate drivers (including the RX 480). 3) Once that was done I rebooted once more and everything was back to normal.

Some tidbits that I had with USB: -Make sure that Windows has the correct driver installed. It defaults to using a MS driver. This greatly affected my ASMedia 3.1 USB controller -Passing through a xhci virtual controller affects polling rates and other items in the VM. RedHat says there can be performance gains by doing this (I tried it once but took it out again) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-KVM_guest_virtual_machine_compatibility-USB3.0-Support.html -Make sure any hubs connected to the controller ports are USB 3.0 -Make sure the USB controller is reset-able under the host. I have some that are and some that aren't on the same (Z97) motherboard. -The passthrough USB controllers can become unstable anyway when the VM is restarted over and over again (at least mine was. Using the correct Windows drivers helped this).

FIXED The problem was with using q35 chipset. Changed to i440fx (pc-i440fx-2.7) and made the pcie-root hub a pci-root hub and all works. I did have to reboot once as I believe the first boot was expecting Win8.1 to be on bare hardware again, but after the reboot we're back in business (and without the hypervisor hiding stuff) Note: I'm also using intel_iommu=pt vs intel_iommu=on. There are some discussions about this being better for performance on some chipsets

@jonp: oh, NOW you tell me ;-) -I was able to produce a VBIOS from the card itself--specifying it in libvirt XML config produced no change -I tried using the VBIOS from techpowerup.com (184327/AMD.RX480.8192.160603.rom). This hung the VM at BIOS loadup For the record, the MD5's: 7fd9be65faf6636ac78968d702c30bd6 AMD.RX480.8192.160603.rom (techpowerup's) 82a5ea3730a0b7b62a3e9abbb5206c99 /home/vm/amd-vbios.rom (dumped ROM) -I read there are some issues with AMD cards and version of qemu prior to ~2.3. I am running 2.7, so that shouldn't be an issue -I checked in Win8.1 about the MSI Interrupt mode, which is set to messaging (MSISupported = 0x00000001). Next step are 1) Check for an updated VBIOS / firmware from the manufacturer 2) Trying using the VBIOS from one of the reference RX 480's 2b) Check your wiki 3) Check if setting the card back to signaling interrupt mode helps (read that it can help somewhere) 4) Try using the old VGA way (vs. OVMF+EFI, which is the current). This will require either the vga arbtrator patch for my Haswell (i915) chipset or reinstalling the 760GTX (and burning more electricity) and disabling onboard video.

I have a similar issue to yours. I traded out a NV 760 GTX for a RX 480. Used DDU to clear drivers, and whenever the AMD driver takes during install the screen goes off. I am different in that: -My VM is still functional, as I can VNC into it and SPICE still works for keyboard / mouse control -I am not actually using unRAID (standard qemu/kvm on Gentoo 4.4.6) -I had the borked colors issue (going into TianoCore / OVMF config screen and resaving the device drivers eliminates this color corruption) One possible solution is that the HDMI audio drivers are causing issues. Remove the HDMI audio part of the RX 480 from your VM config to test (http://www.tomshardware.com/forum/381108-33-solved-graphics-error-code). This didn't work for me. I have a whole drive dedicated to Windows 8.1, and as a result can boot my VM directly ("bare metal"). I had no drivers issues when doing this. This tells me that it has something to do with the virtualized environment. While my first attempt at getting the drivers to work was under nVidia settings (kvm=off) the rest were not. I may have to revisit that... My RX 480 is from PowerColor