Description of problem: VF cannot be found via "lspci" inside PV guest after assigning VF.While it can be found both via "xm pci-list" and "Hardware" tab in Virt-manager. Version-Release number of selected component (if applicable): Linux intel-x5550-12-1 2.6.18-194.el5xen #1 SMP Tue Mar 16 22:01:26 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux & xen-3.0.3-105.el5 How reproducible: always Steps to Reproduce: Host: 1.[root@intel-x5550-12-1 ~]# xm pci-list rhel54_32_pv domain bus slot func 0 3 10 0 Guest: 1.# dmesg |grep igb 2.# lspci Actual results: The VF cannot be found via "lspci" inside guest Expected results: The VF can be found via "lspci" inside guest, we should also access the guest via VF link Additional info:
Created attachment 406999 [details] See in "Hardware" , virt-manager
Created attachment 407000 [details] xend.log
The physical pci device can be found in PV guest [root@virtlab-66-85-194 ~]# lspci 00:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
This is a known limitation. At the very least we need this upstream Xen changeset (and it's parent changeset as a prerequisiste): http://xenbits.xen.org/linux-2.6.18-xen.hg?rev/4b0c1a686393 Dexuan Cui has provided more details here: https://bugzilla.redhat.com/show_bug.cgi?id=525577#c66
We'll take a look at getting this backported for 5.6.
*** Bug 621134 has been marked as a duplicate of this bug. ***
Created attachment 436500 [details] backport of c/s 103, 998, 999 From bug #621134: "This patch was provided at the end of February 2010 by Intel to upstream xen. It virtualizes vendor, device and BAR fields in the PCI config space, because they're dummy for a VF's host-level PCI config space. pciback can do so by always extracting the values installed in dom0 kernel's own PCI structures, rather than interrogating the underlying PCI config space directly. It's a backport of upstream changesets 103, 998 and 999. They are backported together because each is basically reverted by the following one. On top of this one may want to backport 1003 too."
Would it be possible for QE to test the patch before they are posted/included, if I gave you a test kernel? Thanks!
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Test kernel are available at http://people.redhat.com/pbonzini/kernel-100804/ Thanks in advance for any testing.
Test passed with the kernel-xen mentioned in comment 10: kernel-xen-2.6.18-210.el5.pbtest.x86_64 kernel-xen-devel-2.6.18-210.el5.pbtest.x86_64 Both "dmesg |grep igb" and "lspci" can get corresponding VF info of the guest.
Created attachment 437543 [details] screenshot for commands output on guest
in kernel-2.6.18-212.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
*** Bug 591764 has been marked as a duplicate of this bug. ***
Test steps: 1. generate VFs on host and unbind a VF 2. create rhel5u5 PV guest with a line pci=["0000:0f:10.5"] in config file 3. [host]#xm pci-list $pv-guest-id 4. see pv guest's hardware by virt-manager 5. [guest]#lspci 6. [guest]# dmesg |grep igb host: rhel5.5, x86_64 guest:rhel5.5 i386 and x86_64 PV (kernel-2.6.18.194.el5xen) Reproduce this bug with:kernel-xen-2.6.18-194.el5,xen-3.0.3-105.el5 [host]# xm pci-list rhel5u5-32-pv domain bus slot func 0 f 10 5 [guest]# dmesg |grep igb [guest]# lspci Verified with: xen-3.0.3-120.el5, kernel-xen-2.6.18-232.el5, rhel5.5 i386 & x86_64 PV guest, pass-through 2 pci devices to guest [host xen]# xm pci-list 6 domain bus slot func 0 f 10 5 0 f 10 3 [guest]# lspci 00:00.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 00:00.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) [guest]# dmesg |grep igb igbvf 0000:00:00.3: PF still in reset state, assigning new address igbvf 0000:00:00.3: PF still resetting igbvf 0000:00:00.3: Intel(R) 82576 Virtual Function igbvf 0000:00:00.3: Address: d2:25:a4:2f:15:eb igbvf 0000:00:00.3: MAC: 1 igbvf 0000:00:00.5: PF still in reset state, assigning new address igbvf 0000:00:00.5: PF still resetting igbvf 0000:00:00.5: Intel(R) 82576 Virtual Function igbvf 0000:00:00.5: Address: 46:01:b0:34:32:99 igbvf 0000:00:00.5: MAC: 1 igbvf 0000:00:00.3: PF still resetting igbvf 0000:00:00.5: PF still resetting [root@dhcp-66-82-191 ~]# According to the result above, set bug status to VERIFIED.
Also verified with kernel-xen-2.6.18-238.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html