1317531 – libvirt does not report PCI_HEADER_TYPE in node device XML

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1317531 - libvirt does not report PCI_HEADER_TYPE in node device XML

Summary: libvirt does not report PCI_HEADER_TYPE in node device XML

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	libvirt
Sub Component:
Version:	7.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	high
Severity:	urgent
Target Milestone:	rc
Target Release:	---
Assignee:	Martin Kletzander
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1303160 1331328
TreeView+	depends on / blocked

Reported:	2016-03-14 13:30 UTC by Martin Polednik
Modified:	2016-11-03 18:39 UTC (History)
CC List:	12 users (show)
Fixed In Version:	libvirt-1.3.3-1.el7
Doc Type:	Bug Fix
Doc Text:	Previously, the node device XML did not contain the PCI header type, which caused guest PCI devices to be unavailable for passthrough assignment. With this update, the libvirt service reports the PCI header type properly, and guest PCI devices can be assigned for passthrough as expected.
Clone Of:
Clones:	1331328 (view as bug list)
Environment:
Last Closed:	2016-11-03 18:39:27 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2016:2577	0	normal	SHIPPED_LIVE	Moderate: libvirt security, bug fix, and enhancement update	2016-11-03 12:07:06 UTC

Description Martin Polednik 2016-03-14 13:30:25 UTC

Description of problem:
XML description of node device is missing PCI_HEADER_TYPE. PCI_HEADER_TYPE should be reported as only type 0 devices are suitable for direct assignment.

Version-Release number of selected component (if applicable):
libvirt-daemon-1.2.17-13.el7_2.2.x86_64
libvirt-python-1.2.17-2.el7.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. virsh -r nodedev-list
2. virsh -r nodedev-dumpxml <PCI device>

(or equivalent in API)

Actual results:
There is no field informing of PCI header type.

Expected results:
PCI header type field exists.

Comment 4 Daniel Berrangé 2016-03-14 15:40:59 UTC

Can you explain in more detail just what you want to do with this PCI_HEADER_TYPE information, how it'll be used by applications in particular ?

Comment 5 Martin Polednik 2016-03-14 18:18:15 UTC

It is an easy way of assessing device's availability for direct assignment (e.g. only display devices with PCI_HEADER_TYPE = 0 as available).

Comment 6 Daniel Berrangé 2016-03-14 18:26:00 UTC

It strikes me that it'd be better if libvirt actually reported a higher level "isAssignable" flag rather than exporting low level PCI device details and expecting applications to figure out that header type == 0 means it is assignable.

Comment 7 Michal Skrivanek 2016-03-15 07:15:48 UTC

(In reply to Daniel Berrange from comment #6)
> It strikes me that it'd be better if libvirt actually reported a higher
> level "isAssignable" flag rather than exporting low level PCI device details
> and expecting applications to figure out that header type == 0 means it is
> assignable.

Indeed "isAssignable" makes more sense. Either way is fine for our purpose.

Comment 8 Martin Polednik 2016-03-15 08:24:06 UTC

I don't think isAssignable is better - we already handle IOMMU groups and IOMMU support. I would prefer more fine grained, technical approach. That being said, either is helpful.

Comment 9 Martin Kletzander 2016-03-15 11:14:01 UTC

I would rather expose the type as a string as that's something that's not going to change and we don't need to differentiate whether the device is assignable through different drivers and also for different drivers (vfio, legacy kvm, etc.).  I would suggest something like:

  <capability type='pci'>
    ...
    <header type='endpoint|pci-bridge|cardbus-bridge>
      <multifunction />
    </header>
    ...
  </capability>

But I believe whatever the naming/format will be RHEV will be able to deal with that.  And it's going to be discussed upstream anyway.  Also if we add it to the list of possible filters by which you can filter the devices, then it's even easier for you guys, right?

Comment 10 Martin Polednik 2016-03-15 11:46:56 UTC

I guess string is fine, although in the end it will be kernel int -> libvirt int-to-string -> rhev string-to-int. Doesn't really matter to me though, whatever is preferred upstream is fine.

As for the filtering, not really. We want to report all of the devices (the capability filtering isn't used in the end).

Comment 11 Martin Kletzander 2016-03-15 12:06:08 UTC

(In reply to Martin Polednik from comment #10)
OK, then we don't need to deal with the filtering (for now, others might use it), but at least that's not needed to be back-ported.  As for the translation, you have to bear in mind that rhev is *not* the only consumer of libvirt.  User-readability is very usable even for management applications (e.g. for developers).

Comment 12 Martin Kletzander 2016-03-15 16:24:15 UTC

Patch proposed upstream:

https://www.redhat.com/archives/libvir-list/2016-March/msg00645.html

Comment 13 Martin Kletzander 2016-03-18 16:39:21 UTC

Fixed upstream v1.3.2-219-gd77ffb6876e8:

commit d77ffb6876e87a5c6f4c74c49cf0d89ade4f8326
Author: Martin Kletzander <mkletzan>
Date:   Tue Mar 15 12:22:03 2016 +0100

    nodedev: Expose PCI header type

Comment 16 Mike McCune 2016-03-28 23:07:19 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 20 Jingjing Shao 2016-04-19 05:47:53 UTC

Hi Martin，
I try to verify this issue，but can not get header type in dumpxml
Is there something wrong ?

[root@ibm-x3850x5-05 jishao]# rpm -q libvirt
libvirt-1.3.3-2.el7.x86_64

[root@ibm-x3850x5-05 jishao]# virsh nodedev-dumpxml pci_0000_86_00_0
<device>
  <name>pci_0000_86_00_0</name>
  <path>/sys/devices/pci0000:80/0000:80:01.0/0000:86:00.0</path>
  <parent>pci_0000_80_01_0</parent>
  <driver>
    <name>ixgbe</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>134</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x10fb'>82599ES 10-Gigabit SFI/SFP+ Network Connection</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
    <capability type='virt_functions' maxCount='63'>
      <address domain='0x0000' bus='0x86' slot='0x10' function='0x0'/>
      <address domain='0x0000' bus='0x86' slot='0x10' function='0x2'/>
    </capability>
    <iommuGroup number='27'>
      <address domain='0x0000' bus='0x86' slot='0x00' function='0x0'/>
    </iommuGroup>
    <numa node='1'/>
    <pci-express>
      <link validity='cap' port='0' speed='5' width='8'/>
      <link validity='sta' speed='5' width='4'/>
    </pci-express>
  </capability>
</device>

Comment 21 Martin Kletzander 2016-04-19 12:33:50 UTC

(In reply to Jingjing Shao from comment #20)
Sorry for not disclosing the details here.  After bunch of upstream discussions, we expose the header type if it is different than type='endpoint'.  So for endpoints the XML should not change, but for bridges, ti should look e.g. like this:

<device>
  ...
  <capability type='pci'>
    <capability type='pci-bridge'/>
  </capability>
  ...
</device>

So management should only look for /device/caability[type=pci]/capability/@type.  If it is there and the value is equal to 'pci-bridge' or 'cardbus-bridge', then the device not assignable.

Comment 22 Martin Kletzander 2016-04-20 05:23:30 UTC

Putting back needinfos deleted with previous comment.

Comment 23 Jingjing Shao 2016-04-21 03:28:51 UTC

(In reply to Martin Kletzander from comment #21)
> (In reply to Jingjing Shao from comment #20)
> Sorry for not disclosing the details here.  After bunch of upstream
> discussions, we expose the header type if it is different than
> type='endpoint'.  So for endpoints the XML should not change, but for
> bridges, ti should look e.g. like this:
> 
> <device>
>   ...
>   <capability type='pci'>
>     <capability type='pci-bridge'/>
>   </capability>
>   ...
> </device>
> 
> So management should only look for
> /device/caability[type=pci]/capability/@type.  If it is there and the value
> is equal to 'pci-bridge' or 'cardbus-bridge', then the device not assignable.

Sorry that I can not get the "/device/capability[type=pci]/capability/@type" clearly. Is it not this dir as below, right?  Can you tell more clearly ?
Thank you  in advanced.

e.g
#  virsh nodedev-dumpxml pci_0000_0d_02_0
<device>
  <name>pci_0000_0d_02_0</name>
  <path>/sys/devices/pci0000:00/0000:00:1c.6/0000:0c:00.0/0000:0d:02.0</path>
  <parent>pci_0000_0c_00_0</parent>
  <driver>
    <name>pcieport</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>13</bus>
    <slot>2</slot>
    <function>0</function>
    <product id='0x8018'>PES12N3A PCI Express Switch</product>
    <vendor id='0x111d'>Integrated Device Technology, Inc. [IDT]</vendor>
    <iommuGroup number='24'>
      <address domain='0x0000' bus='0x0d' slot='0x02' function='0x0'/>
      <address domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/>
      <address domain='0x0000' bus='0x0e' slot='0x00' function='0x1'/>
      <address domain='0x0000' bus='0x0f' slot='0x10' function='0x0'/>
      <address domain='0x0000' bus='0x0f' slot='0x10' function='0x1'/>
      <address domain='0x0000' bus='0x0f' slot='0x10' function='0x2'/>
      <address domain='0x0000' bus='0x0f' slot='0x10' function='0x3'/>
    </iommuGroup>
    <capability type='pci-bridge'/>  <=========================== header type
    <pci-express>
      <link validity='cap' port='2' speed='2.5' width='4'/>
      <link validity='sta' speed='2.5' width='4'/>
    </pci-express>
  </capability>
</device>


# ll /sys/bus/pci/devices/0000\:0d\:02.0/ 
total 0
drwxr-xr-x. 3 root root    0 Apr 11 11:00 0000:0d:02.0:pcie28
drwxr-xr-x. 6 root root    0 Apr 11 11:00 0000:0e:00.0
drwxr-xr-x. 6 root root    0 Apr 11 11:00 0000:0e:00.1
drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.0
drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.1
drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.2
drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.3
-rw-r--r--. 1 root root 4.0K Apr 21 11:18 broken_parity_status
-r--r--r--. 1 root root 4.0K Apr 11 11:00 class
-rw-r--r--. 1 root root 4.0K Apr 11 11:00 config
-r--r--r--. 1 root root 4.0K Apr 21 11:18 consistent_dma_mask_bits
-rw-r--r--. 1 root root 4.0K Apr 21 11:18 d3cold_allowed
-r--r--r--. 1 root root 4.0K Apr 11 11:00 device
-r--r--r--. 1 root root 4.0K Apr 21 11:18 dma_mask_bits
lrwxrwxrwx. 1 root root    0 Apr 11 11:00 driver -> ../../../../../bus/pci/drivers/pcieport
-rw-r--r--. 1 root root 4.0K Apr 21 11:18 driver_override
-rw-r--r--. 1 root root 4.0K Apr 21 11:18 enable
lrwxrwxrwx. 1 root root    0 Apr 21 11:18 iommu -> ../../../../virtual/iommu/dmar0
lrwxrwxrwx. 1 root root    0 Apr 11 11:00 iommu_group -> ../../../../../kernel/iommu_groups/24
-r--r--r--. 1 root root 4.0K Apr 18 16:12 irq
-r--r--r--. 1 root root 4.0K Apr 21 11:18 local_cpulist
-r--r--r--. 1 root root 4.0K Apr 11 11:00 local_cpus
-r--r--r--. 1 root root 4.0K Apr 18 16:06 modalias
-rw-r--r--. 1 root root 4.0K Apr 21 11:18 msi_bus
drwxr-xr-x. 2 root root    0 Apr 11 11:00 msi_irqs
-r--r--r--. 1 root root 4.0K Apr 11 11:00 numa_node
drwxr-xr-x. 4 root root    0 Apr 11 11:00 pci_bus
drwxr-xr-x. 2 root root    0 Apr 18 16:06 power
--w--w----. 1 root root 4.0K Apr 21 11:18 remove
--w--w----. 1 root root 4.0K Apr 21 11:18 rescan
-r--r--r--. 1 root root 4.0K Apr 18 16:12 resource
lrwxrwxrwx. 1 root root    0 Apr 11 11:00 subsystem -> ../../../../../bus/pci
-r--r--r--. 1 root root 4.0K Apr 21 11:18 subsystem_device
-r--r--r--. 1 root root 4.0K Apr 21 11:18 subsystem_vendor
-rw-r--r--. 1 root root 4.0K Apr 11 11:00 uevent
-r--r--r--. 1 root root 4.0K Apr 11 11:00 vendor

Comment 24 Jingjing Shao 2016-04-21 06:32:15 UTC

Please ignore the comment 23， I take a mistake about comment 21

(In reply to Jingjing Shao from comment #23)
> (In reply to Martin Kletzander from comment #21)
> > (In reply to Jingjing Shao from comment #20)
> > Sorry for not disclosing the details here.  After bunch of upstream
> > discussions, we expose the header type if it is different than
> > type='endpoint'.  So for endpoints the XML should not change, but for
> > bridges, ti should look e.g. like this:
> > 
> > <device>
> >   ...
> >   <capability type='pci'>
> >     <capability type='pci-bridge'/>
> >   </capability>
> >   ...
> > </device>
> > 
> > So management should only look for
> > /device/caability[type=pci]/capability/@type.  If it is there and the value
> > is equal to 'pci-bridge' or 'cardbus-bridge', then the device not assignable.
> 
> Sorry that I can not get the "/device/capability[type=pci]/capability/@type"
> clearly. Is it not this dir as below, right?  Can you tell more clearly ?
> Thank you  in advanced.
> 
> e.g
> #  virsh nodedev-dumpxml pci_0000_0d_02_0
> <device>
>   <name>pci_0000_0d_02_0</name>
>   <path>/sys/devices/pci0000:00/0000:00:1c.6/0000:0c:00.0/0000:0d:02.0</path>
>   <parent>pci_0000_0c_00_0</parent>
>   <driver>
>     <name>pcieport</name>
>   </driver>
>   <capability type='pci'>
>     <domain>0</domain>
>     <bus>13</bus>
>     <slot>2</slot>
>     <function>0</function>
>     <product id='0x8018'>PES12N3A PCI Express Switch</product>
>     <vendor id='0x111d'>Integrated Device Technology, Inc. [IDT]</vendor>
>     <iommuGroup number='24'>
>       <address domain='0x0000' bus='0x0d' slot='0x02' function='0x0'/>
>       <address domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/>
>       <address domain='0x0000' bus='0x0e' slot='0x00' function='0x1'/>
>       <address domain='0x0000' bus='0x0f' slot='0x10' function='0x0'/>
>       <address domain='0x0000' bus='0x0f' slot='0x10' function='0x1'/>
>       <address domain='0x0000' bus='0x0f' slot='0x10' function='0x2'/>
>       <address domain='0x0000' bus='0x0f' slot='0x10' function='0x3'/>
>     </iommuGroup>
>     <capability type='pci-bridge'/>  <=========================== header type
>     <pci-express>
>       <link validity='cap' port='2' speed='2.5' width='4'/>
>       <link validity='sta' speed='2.5' width='4'/>
>     </pci-express>
>   </capability>
> </device>
> 
> 
> # ll /sys/bus/pci/devices/0000\:0d\:02.0/ 
> total 0
> drwxr-xr-x. 3 root root    0 Apr 11 11:00 0000:0d:02.0:pcie28
> drwxr-xr-x. 6 root root    0 Apr 11 11:00 0000:0e:00.0
> drwxr-xr-x. 6 root root    0 Apr 11 11:00 0000:0e:00.1
> drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.0
> drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.1
> drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.2
> drwxr-xr-x. 5 root root    0 Apr 18 16:13 0000:0f:10.3
> -rw-r--r--. 1 root root 4.0K Apr 21 11:18 broken_parity_status
> -r--r--r--. 1 root root 4.0K Apr 11 11:00 class
> -rw-r--r--. 1 root root 4.0K Apr 11 11:00 config
> -r--r--r--. 1 root root 4.0K Apr 21 11:18 consistent_dma_mask_bits
> -rw-r--r--. 1 root root 4.0K Apr 21 11:18 d3cold_allowed
> -r--r--r--. 1 root root 4.0K Apr 11 11:00 device
> -r--r--r--. 1 root root 4.0K Apr 21 11:18 dma_mask_bits
> lrwxrwxrwx. 1 root root    0 Apr 11 11:00 driver ->
> ../../../../../bus/pci/drivers/pcieport
> -rw-r--r--. 1 root root 4.0K Apr 21 11:18 driver_override
> -rw-r--r--. 1 root root 4.0K Apr 21 11:18 enable
> lrwxrwxrwx. 1 root root    0 Apr 21 11:18 iommu ->
> ../../../../virtual/iommu/dmar0
> lrwxrwxrwx. 1 root root    0 Apr 11 11:00 iommu_group ->
> ../../../../../kernel/iommu_groups/24
> -r--r--r--. 1 root root 4.0K Apr 18 16:12 irq
> -r--r--r--. 1 root root 4.0K Apr 21 11:18 local_cpulist
> -r--r--r--. 1 root root 4.0K Apr 11 11:00 local_cpus
> -r--r--r--. 1 root root 4.0K Apr 18 16:06 modalias
> -rw-r--r--. 1 root root 4.0K Apr 21 11:18 msi_bus
> drwxr-xr-x. 2 root root    0 Apr 11 11:00 msi_irqs
> -r--r--r--. 1 root root 4.0K Apr 11 11:00 numa_node
> drwxr-xr-x. 4 root root    0 Apr 11 11:00 pci_bus
> drwxr-xr-x. 2 root root    0 Apr 18 16:06 power
> --w--w----. 1 root root 4.0K Apr 21 11:18 remove
> --w--w----. 1 root root 4.0K Apr 21 11:18 rescan
> -r--r--r--. 1 root root 4.0K Apr 18 16:12 resource
> lrwxrwxrwx. 1 root root    0 Apr 11 11:00 subsystem -> ../../../../../bus/pci
> -r--r--r--. 1 root root 4.0K Apr 21 11:18 subsystem_device
> -r--r--r--. 1 root root 4.0K Apr 21 11:18 subsystem_vendor
> -rw-r--r--. 1 root root 4.0K Apr 11 11:00 uevent
> -r--r--r--. 1 root root 4.0K Apr 11 11:00 vendor

Comment 25 Jingjing Shao 2016-04-21 09:16:41 UTC

1. About the type pci-bridge, I verify it as below 
(1) # lspci -t
              \-[0000:00]-+-00.0
         ......

             +-1c.6-[0c-11]----00.0-[0d-11]--+-02.0-[0e-0f]--+-[0000:0f]-+-10.0
             |                               |               |           +-10.1
             |                               |               |           +-10.2
             |                               |               |           \-10.3
             |                               |               \-[0000:0e]-+-00.0
             |                               |                           \-00.1
             |                               \-04.0-[10-11]--+-[0000:11]-+-10.0
             |                                               |           +-10.1
             |                                               |           +-10.2
             |                                               |           \-10.3
             |                                               \-[0000:10]-+-00.0
             |                                                           \-00.1
(2) # lspci -vvv

00:1c.6 PCI bridge: Intel Corporation C600/X79 series chipset PCI Express Root Port 3 (rev b5) (prog-if 00 [Normal decode])
............
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
............


0c:00.0 PCI bridge: Integrated Device Technology, Inc. [IDT] PES12N3A PCI Express Switch (rev 0e) (prog-if 00 [Normal decode])
............
Capabilities: [40] Express (v1) Upstream Port, MSI 00
DevCap: MaxPayload 2048 bytes, PhantFunc 0
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ SlotPowerLimit 10.000W
............


0d:02.0 PCI bridge: Integrated Device Technology, Inc. [IDT] PES12N3A PCI Express Switch (rev 0e) (prog-if 00 [Normal decode])
............
Capabilities: [40] Express (v1) Downstream Port (Slot-), MSI 00
DevCap: MaxPayload 2048 bytes, PhantFunc 0
ExtTag+ RBE+
............


0e:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
............
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
............


(3)
# virsh nodedev-dumpxml pci_0000_00_1c_6
    <device>
    <name>pci_0000_00_1c_6</name>
    <path>/sys/devices/pci0000:00/0000:00:1c.6</path>
    <parent>computer</parent>
    <driver>
    <name>pcieport</name>
    </driver>
    <capability type='pci'>
    <domain>0</domain>
    <bus>0</bus>
    <slot>28</slot>
    <function>6</function>
    <product id='0x1d14'>C600/X79 series chipset PCI Express Root Port 3</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
    <iommuGroup number='13'>
    <address domain='0x0000' bus='0x00' slot='0x1c' function='0x6'/>
    </iommuGroup>
    <capability type='pci-bridge'/> <============= get the header type
    <pci-express>
    <link validity='cap' port='3' speed='5' width='1'/>
    <link validity='sta' speed='2.5' width='1'/>
    </pci-express>
    </capability>
    </device>

# virsh nodedev-dumpxml pci_0000_0c_00_0
    <device>
    <name>pci_0000_0c_00_0</name>
    <path>/sys/devices/pci0000:00/0000:00:1c.6/0000:0c:00.0</path>
    <parent>pci_0000_00_1c_6</parent>
    <driver>
    <name>pcieport</name>
    </driver>
    <capability type='pci'>
    <domain>0</domain>
    <bus>12</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x8018'>PES12N3A PCI Express Switch</product>
    <vendor id='0x111d'>Integrated Device Technology, Inc. [IDT]</vendor>
    <iommuGroup number='23'>
    <address domain='0x0000' bus='0x0c' slot='0x00' function='0x0'/>
    </iommuGroup>
    <capability type='pci-bridge'/> <============= get the header type
    <pci-express>
    <link validity='cap' port='0' speed='2.5' width='4'/>
    <link validity='sta' speed='2.5' width='1'/>
    </pci-express>
    </capability>
    </device>

# virsh nodedev-dumpxml pci_0000_0d_02_0
    <device>
    <name>pci_0000_0d_02_0</name>
    <path>/sys/devices/pci0000:00/0000:00:1c.6/0000:0c:00.0/0000:0d:02.0</path>
    <parent>pci_0000_0c_00_0</parent>
    <driver>
    <name>pcieport</name>
    </driver>
    <capability type='pci'>
    <domain>0</domain>
    <bus>13</bus>
    <slot>2</slot>
    <function>0</function>
    <product id='0x8018'>PES12N3A PCI Express Switch</product>
    <vendor id='0x111d'>Integrated Device Technology, Inc. [IDT]</vendor>
    <iommuGroup number='24'>
    <address domain='0x0000' bus='0x0d' slot='0x02' function='0x0'/>
    <address domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/>
    <address domain='0x0000' bus='0x0e' slot='0x00' function='0x1'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x0'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x1'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x2'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x3'/>
    </iommuGroup>
    <capability type='pci-bridge'/> <============= get the header type
    <pci-express>
    <link validity='cap' port='2' speed='2.5' width='4'/>
    <link validity='sta' speed='2.5' width='4'/>
    </pci-express>
    </capability>
    </device>

#  virsh nodedev-dumpxml pci_0000_0e_00_0
    <device>
    <name>pci_0000_0e_00_0</name>
    <path>/sys/devices/pci0000:00/0000:00:1c.6/0000:0c:00.0/0000:0d:02.0/0000:0e:00.0</path>
    <parent>pci_0000_0d_02_0</parent>
    <driver>
    <name>igb</name>
    </driver>
    <capability type='pci'>
    <domain>0</domain>
    <bus>14</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x10e8'>82576 Gigabit Network Connection</product>
    <vendor id='0x8086'>Intel Corporation</vendor>
    <capability type='virt_functions' maxCount='7'>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x0'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x2'/>
    </capability>
    <iommuGroup number='24'>
    <address domain='0x0000' bus='0x0d' slot='0x02' function='0x0'/>
    <address domain='0x0000' bus='0x0e' slot='0x00' function='0x0'/>
    <address domain='0x0000' bus='0x0e' slot='0x00' function='0x1'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x0'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x1'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x2'/>
    <address domain='0x0000' bus='0x0f' slot='0x10' function='0x3'/>
    </iommuGroup>    <=============== can not get header type
    <pci-express>
    <link validity='cap' port='2' speed='2.5' width='4'/>
    <link validity='sta' speed='2.5' width='4'/>
    </pci-express>
    </capability>
    </device>

(4) About the type cardbus-bridge, I will update the info as once as I loan the system with cardbus-bridge

Comment 26 Martin Kletzander 2016-04-21 12:24:19 UTC

(In reply to Jingjing Shao from comment #25)
That's acceptable behaviour.  I think checking for pci-bridge devices ought to be enough.

Comment 27 Jingjing Shao 2016-04-27 00:49:09 UTC

(In reply to Martin Kletzander from comment #26)
> (In reply to Jingjing Shao from comment #25)
> That's acceptable behaviour.  I think checking for pci-bridge devices ought
> to be enough.

For suitable hardware with cardbus-bridge <dell-m4300-01.rhts.bos.redhat.com>  is a non-automated laptop, I can not loan it remotely.

So I think it is all right to change the status to verified

Comment 30 errata-xmlrpc 2016-11-03 18:39:27 UTC

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.

https://rhn.redhat.com/errata/RHSA-2016-2577.html

Note You need to log in before you can comment on or make changes to this bug.