[vfio-users] "Device or Resource Busy"

[Bryan Jacobs]

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 at gmail.com> wrote:

> On Wed, Mar 16, 2016 at 6:42 AM, Bryan Jacobs <bryanrj at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160317/db84f500/attachment.htm>