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

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'>

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

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).

(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.

(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.

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.

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.