Bug 1035188

Summary: nodedev-detach still defaults to "kvm" driver, but should now default to "vfio"
Product: Red Hat Enterprise Linux 7 Reporter: Laine Stump <laine>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: acathrow, alex.williamson, dyuan, honzhang, jiahu, laine, lsu, mzhan, xuzhang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-1.1.1-14.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 10:16:12 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:
Embargoed:

Description Laine Stump 2013-11-27 09:16:34 UTC
As outlined in Bug 1001738, libvirt now defaults to using vfio for device assignment when available. For consistency, the virsh nodedev-detach command (and by implication the virNodeDeviceDetachFlags() API) should also default to attaching the vfio-pci driver. As of now, they attach the pci-stub driver (used by legacy KVM device assignment) instead.

Comment 1 Laine Stump 2013-12-03 10:15:15 UTC
A fix for this has been pushed upstream:

commit 47b9aae0ae0652738d3a65d6cdd6b0bb16b3a2ec
Author: Laine Stump <laine>
Date:   Fri Nov 29 13:19:26 2013 +0200

    qemu: default to vfio for nodedev-detach

Comment 4 Xuesong Zhang 2013-12-10 06:12:30 UTC
Test with the latest libvirt build libvirt-1.1.1-14.el7.x86_64, all the test result is as expected, so this bug is fixed, change the bug status to "verified".

Steps:
1. check the interface on the host.
# lspci|grep -i eth
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5764M Gigabit Ethernet PCIe (rev 10)
03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
03:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)

2. check the interface's original driver, then detach it to the default driver, it's vfio as expected.
# virsh nodedev-dumpxml pci_0000_03_10_3|grep driver -A1
  <driver>
    <name>igbvf</name>
  </driver>
  <capability type='pci'>
[root@sriov1 ~]# virsh nodedev-detach pci_0000_03_10_3
Device pci_0000_03_10_3 detached

[root@sriov1 ~]# virsh nodedev-dumpxml pci_0000_03_10_3|grep driver -A1
  <driver>
    <name>vfio-pci</name>
  </driver>
  <capability type='pci'>

3. reattached the driver back to the original driver.
[root@sriov1 ~]# virsh nodedev-reattach pci_0000_03_10_3
Device pci_0000_03_10_3 re-attached

[root@sriov1 ~]# virsh nodedev-dumpxml pci_0000_03_10_3|grep driver -A1
  <driver>
    <name>igbvf</name>
  </driver>
  <capability type='pci'>

4. detach the driver to vfio with flag
[root@sriov1 ~]# virsh nodedev-detach pci_0000_03_10_3 --driver vfio
Device pci_0000_03_10_3 detached

[root@sriov1 ~]# virsh nodedev-dumpxml pci_0000_03_10_3|grep driver -A1
  <driver>
    <name>vfio-pci</name>
  </driver>
  <capability type='pci'>
[root@sriov1 ~]# virsh nodedev-reattach pci_0000_03_10_3
Device pci_0000_03_10_3 re-attached


5. detach the driver to kvm
[root@sriov1 ~]# virsh nodedev-detach pci_0000_03_10_3 --driver kvm
Device pci_0000_03_10_3 detached

[root@sriov1 ~]# virsh nodedev-dumpxml pci_0000_03_10_3|grep driver -A1
  <driver>
    <name>pci-stub</name>
  </driver>
  <capability type='pci'>
[root@sriov1 ~]# virsh nodedev-reattach pci_0000_03_10_3
Device pci_0000_03_10_3 re-attached

[root@sriov1 ~]# virsh nodedev-dumpxml pci_0000_03_10_3|grep driver -A1
  <driver>
    <name>igbvf</name>
  </driver>
  <capability type='pci'>

Comment 5 Luwen Su 2013-12-10 06:23:12 UTC
Hi Laine ,

On one of my machine which don't have vfio but kvm existed ,the function can't 
auto select if omits the --device <string> parameter .

#ls /dev/vfio*
ls: cannot access /dev/vfio*: No such file or directory

#ll /dev/kvm 
crw-rw-rw-. 1 root kvm 10, 232 Dec 10 11:40 /dev/kvm

#virsh nodedev-tree -list
+- pci_0000_00_19_0
  |   |
  |   +- net_enp0s25_1c_6f_65_06_ba_26

#virsh nodedev-detach pci_0000_00_19_0
error: Failed to detach device pci_0000_00_19_0
error: invalid argument: neither VFIO nor kvm device assignment is currently supported on this system


But if add --device kvm , it will success


Does it because 
bool
qemuHostdevHostSupportsPassthroughLegacy
if ((ioctl(kvmfd, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU)) <= 0)  ?

Seems like ioctl return 0 for success normally to my knowledge , is there any changes?

And in my test machine

kvmfd = open("/dev/kvm", O_RDONLY)   returns 3
ioctl(kvmfd, KVM_CHECK_EXTENSION, KVM_CAP_IOMMU  returns 0

Comment 6 Laine Stump 2013-12-10 10:44:15 UTC
My understanding of the KVM_CHECK_EXTENSION ioctl is that it returns < 0 if there was an error, 0 if the queried extension isn't supported, or > 0 if that extension is supported. So the code appears to be correct.

Should we always be saying that legacy assignment isn't available if KVM_CAP_IOMMU isn't available? If so then we need to also check this when someone explicitly says "--driver kvm"; if not, then we should either not do this check (or we're checking the wrong thing at the wrong time).

Comment 7 Alex Williamson 2013-12-10 22:14:37 UTC
(In reply to Laine Stump from comment #6)
> My understanding of the KVM_CHECK_EXTENSION ioctl is that it returns < 0 if
> there was an error, 0 if the queried extension isn't supported, or > 0 if
> that extension is supported. So the code appears to be correct.

That's my understanding as well.

> Should we always be saying that legacy assignment isn't available if
> KVM_CAP_IOMMU isn't available?

Yes, if KVM_IOMMU_CAP returns 0 then either there is no IOMMU present to use or legacy KVM device assignment is disabled via config option.

Comment 8 Luwen Su 2013-12-11 01:52:20 UTC
(In reply to Laine Stump from comment #6)
> My understanding of the KVM_CHECK_EXTENSION ioctl is that it returns < 0 if
> there was an error, 0 if the queried extension isn't supported, or > 0 if
> that extension is supported. So the code appears to be correct.
> 
> Should we always be saying that legacy assignment isn't available if
> KVM_CAP_IOMMU isn't available? If so then we need to also check this when
> someone explicitly says "--driver kvm"; if not, then we should either not do
> this check (or we're checking the wrong thing at the wrong time).

Thanks a lot  , that's make sense enough for me.
I will change our test scripts via the patch.

Comment 9 Hu Jianwei 2014-02-18 09:11:37 UTC
The legacy KVM device assignment is deprecated from kernel-3.10.0-44.el7 version.
(Please refer to Bug 1025880 - Disable CONFIG_KVM_DEVICE_ASSIGNMENT)

Version:
libvirt-1.1.1-23.el7.x86_64
qemu-kvm-rhev-1.5.3-48.el7.x86_64
kernel-3.10.0-88.el7.x86_64

For this change, we'll get below new result with "--driver kvm"

[root@intel-e5530-8-2 ~]# virsh nodedev-detach pci_0000_07_00_1 --driver kvm
error: Failed to detach device pci_0000_07_00_1
error: argument unsupported: KVM device assignment is currently not supported on this system

Other results are same as comment 4.

Comment 10 Ludek Smid 2014-06-13 10:16:12 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.