Bug 1029720

Summary: libvirt does not properly probe for vfio support
Product: [Fedora] Fedora Reporter: Alex Williamson <alex.williamson>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: berrange, clalancette, crobinso, itamar, jforbes, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-16 23:31:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alex Williamson 2013-11-13 01:35:21 UTC
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 10:42:09 UTC
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 13:42:14 UTC
(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 15:12:15 UTC
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 23:31:48 UTC
(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