[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [vfio-users] "Device or Resource Busy"



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 <alex l williamson gmail com> wrote:
On Wed, Mar 16, 2016 at 6:42 AM, Bryan Jacobs <bryanrj gmail com> 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. 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]