Bug 1029720 - libvirt does not properly probe for vfio support
libvirt does not properly probe for vfio support
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-12 20:35 EST by Alex Williamson
Modified: 2016-04-26 20:09 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-16 19:31:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Williamson 2013-11-12 20:35:21 EST
Description of problem:
qemuHostdevHostSupportsPassthroughVFIO checks for /dev/vfio/vfio, but vfio is built as a module and libvirt makes no attempt to load it.

Version-Release number of selected component (if applicable):
1.1.4-2.fc20 (virt-preview)

How reproducible:
100%


Steps to Reproduce:
1. unload all vfio modules
2. attempt to assign a device, in my case both functions of a two function device
3.

Actual results:
error: Failed to start domain xxxxxxxx
error: internal error: Unable to reset PCI device 0000:04:00.0: internal
error: Active 0000:04:00.1 devices on bus with 0000:04:00.0, not doing bus reset

Expected results:
libvirt loads modules and works

Additional info:
If I 'modprobe vfio' then /dev/vfio/vfio is created and libvirt will load the vfio-pci module, attach devices, and start the domain correctly.
Comment 1 Laine Stump 2013-11-13 05:42:09 EST
What you're requesting isn't just "probing for vfio support", it's modifying the system configuration. If someone wants to specifically disable vfio on their system, that's their choice, not libvirt's, and libvirt shouldn't try to override that choice.

Beyond that, if VFIO is going to be the default on any given version of any distro, then the default system config of that distro should be loading the vfio module.
Comment 2 Alex Williamson 2013-11-13 08:42:14 EST
(In reply to Laine Stump from comment #1)
> What you're requesting isn't just "probing for vfio support", it's modifying
> the system configuration. If someone wants to specifically disable vfio on
> their system, that's their choice, not libvirt's, and libvirt shouldn't try
> to override that choice.
> 
> Beyond that, if VFIO is going to be the default on any given version of any
> distro, then the default system config of that distro should be loading the
> vfio module.

So you would suggest that this is a qemu-kvm issue, that it should include a directive to load vfio just as it already has for kvm and vhost-net?
Comment 3 Jaroslav Reznik 2015-03-03 10:12:15 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 4 Cole Robinson 2016-03-16 19:31:48 EDT
(In reply to Alex Williamson from comment #2)
> (In reply to Laine Stump from comment #1)
> > What you're requesting isn't just "probing for vfio support", it's modifying
> > the system configuration. If someone wants to specifically disable vfio on
> > their system, that's their choice, not libvirt's, and libvirt shouldn't try
> > to override that choice.
> > 
> > Beyond that, if VFIO is going to be the default on any given version of any
> > distro, then the default system config of that distro should be loading the
> > vfio module.
> 
> So you would suggest that this is a qemu-kvm issue, that it should include a
> directive to load vfio just as it already has for kvm and vhost-net?

Not sure if you ever went this route, but it's probably the best thing to do... libvirt doesn't mess with loading modules so it's simplest to stick to that pattern

Note You need to log in before you can comment on or make changes to this bug.