Thanks! That was exactly what was going wrong. efifb had attached to some of the nvidia device's memory.
Since efifb can't be compiled as a module, and I'd rather not turn it off, here's what I did: echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind This completely solves the problem and all is well doing passthrough on my Skylake system. Hopefully now that there's a solution with the right magic words in it on the Internet, others will find their answer here. Thanks again! Bryan Jacobs On Thu, Mar 17, 2016 at 1:29 AM, Alex Williamson < [email protected]> wrote: > On Wed, Mar 16, 2016 at 6:42 AM, Bryan Jacobs <[email protected]> wrote: > >> Hello VFIO users! >> >> Yesterday I was able to boot a Windows VM successfully with OVMF and a >> passed-through graphics card. >> >> I'm not sure what changed, but today I get a libvirt qemu log full of >> these messages: >> >> "qemu-system-x86_64: vfio_region_write(0000:01:00.0:region1+0x240c14, >> 0xffffffff,4) failed: Device or resource busy" >> >> There are hundreds upon hundreds of these - it looks like it's walking a >> large memory space, doing reads and writes, and failing every time. The >> graphics card gives code 43, but the problem doesn't go away even if I >> entirely disable enlightenments. Removing the PCIe passthrough devices gets >> rid of the log entries. >> >> My two passed PCI devices are a GTX 980TI GPU and its HDMI audio >> function. They are in their own IOMMU group with their own pci bridge. The >> CPU is an i5-6600k. >> >> I have verified that the devices are bound to the vfio-pci driver, >> although I don't seem to be able to entirely stop console output from >> appearing on the graphics card on boot (not even with my CSM-free UEFI set >> to use the integrated graphics instead). There's definitely nothing like X >> running, and the nvidia module is unloaded in the host OS. >> >> # virsh --version >> 1.3.2 >> # uname -a >> Linux host 4.4.5-1-ARCH #1 SMP PREEMPT Thu Mar 10 07:38:19 CET 2016 >> x86_64 GNU/Linux >> >> Removing the passed-through device fixes the issue. >> >> What would make the vfio_region_(read|write) calls return EBUSY? I >> figured I'd ask here before diving into the kernel sources :-/. >> > > This is likely due to another driver in the host claiming some of the > resources of the device. Check /proc/iomem to see if there are other > drivers making use of some device regions. > >
_______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
