Description of problem:
After attach and detach device with managed=yes, the pci device can not be auto reassigned to host
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. prepare a guest and start it
2. # virsh nodedev-list --tree
| +- net_eth0_b8_ac_6f_3b_0b_bc
# virsh nodedev-dumpxml pci_0000_00_19_0
<product id='0x10de'>82567LM-3 Gigabit Network Connection</product>
<vendor id='0x8086'>Intel Corporation</vendor>
# cat nodedev.xml
<hostdev mode='subsystem' type='pci' managed='yes'>
<address bus='0' slot='25' function='0'/>
# modprobe -r kvm_intel
# modprobe -r kvm
# modprobe kvm allow_unsafe_assigned_interrupts=1
# modprobe kvm_intel
# virsh attach-device guest nodedev.xml
3. virsh detach-device guest nodedev.xml
after step3, the eth0 can not be find on # ifconfig -a
and # service network restart can not start network
the eth0 device can be auto reassigned
on version libvirt-0.8.7-18.el6.x86_64, the eth0 device can be auto reassigned after detach with managed=yes, so it is a regression bug
IMHO, "ifconfig -a" and "service network start" are not sufficient to check if the device is reassigned to host. As for a network device, there might be some other reasons which will cause "ifconfig -a" won't list the device, and "service network start" fail. For example, the network config file "ifcfg-eth0" can't be found.
The sufficient way in my opinion is checking if the device is still bound to the pci-stub driver. E.g.
# ls /sys/devices/pci0000:00/0000:00:00.0 -l
The symbol link "driver" will point to the current driver for the device.
And actually what libvirt does for "detach with managed" is unbind the device from pci-stub driver first, and bind it to the original driver then.
So if you find it's still bound to pci-stub, it's bug indeed, if it's bound to the original driver, it's not bug.
(In reply to comment #3)
> The sufficient way in my opinion is checking if the device is still bound to
> the pci-stub driver. E.g.
> # ls /sys/devices/pci0000:00/0000:00:00.0 -l
> The symbol link "driver" will point to the current driver for the device.
> And actually what libvirt does for "detach with managed" is unbind the device
> from pci-stub driver first, and bind it to the original driver then.
> So if you find it's still bound to pci-stub, it's bug indeed, if it's bound to
> the original driver, it's not bug.
I check after detach-device with "managed=yes" from guest and do
# ls /sys/devices/pci0000\:00/0000\:00\:19.0 -l
find that the driver still bound to pci-stub
lrwxrwxrwx. 1 root root 0 Aug 16 02:04 driver -> ../../../bus/pci/drivers/pci-stub, so it's bug indeed.
Author: Osier Yang <firstname.lastname@example.org>
Date: Wed Aug 17 20:58:33 2011 +0800
qemu: Init reattaching related members of pciDevice before reattach
Otherwise the device will still be bound to pci-stub driver even
it's set as "managed=yes" when do detaching. Of course, it won't
triger any driver reprobing too.
Patch pushed to upstream,
Patch sent internally, move to MODIFIED.
POST not modified, until 0.9.4-6 is built.
verify pass on
after detach device from guest with "managed='yes'", the host can auto reattach the device again
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.