[libvirt] [PATCH v3 2/2] nodedev: Expose PCI header type

[Martin Kletzander]

On Thu, Mar 17, 2016 at 12:30:48PM -0400, John Ferlan wrote:
>
>
>On 03/17/2016 12:18 PM, Martin Kletzander wrote:
>> If we expose this information, which is one byte in every PCI config
>> file, we let all mgmt apps know whether the device itself is an endpoint
>> or not so it's easier for them to decide whether such device can be
>> passed through into a VM (endpoint) or not (*-bridge).
>>
>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531
>>
>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> ---
>>  docs/schemas/nodedev.rng                           | 11 ++++++++
>>  src/conf/node_device_conf.c                        | 20 +++++++++++++
>>  src/conf/node_device_conf.h                        |  1 +
>>  src/libvirt_private.syms                           |  3 ++
>>  src/node_device/node_device_udev.c                 |  3 ++
>>  src/util/virpci.c                                  | 33 ++++++++++++++++++++++
>>  src/util/virpci.h                                  | 12 ++++++++
>>  .../pci_0000_00_02_0_header_type.xml               | 15 ++++++++++
>>  .../pci_0000_00_1c_0_header_type.xml               | 20 +++++++++++++
>>  tests/nodedevxml2xmltest.c                         |  2 ++
>>  10 files changed, 120 insertions(+)
>>  create mode 100644 tests/nodedevschemadata/pci_0000_00_02_0_header_type.xml
>>  create mode 100644 tests/nodedevschemadata/pci_0000_00_1c_0_header_type.xml
>>
>
>Will there be an adjustment to formatnode.html.in too? To explain how to
>use...
>

Oh, thanks for reminding me of that.  Would squashing something similar
to this suffice or should I rather repost this as v4?

diff --git i/docs/formatnode.html.in w/docs/formatnode.html.in
index 6c12227b8952..e7b11400cbeb 100644
--- i/docs/formatnode.html.in
+++ w/docs/formatnode.html.in
@@ -97,27 +97,38 @@
               <dd>
                 This optional element can occur multiple times. If it
                 exists, it has a mandatory <code>type</code> attribute
-                which will be set to
-                either <code>physical_function</code>
-                or <code>virtual_functions</code>. If the type
-                is <code>physical_function</code>, there will be a
-                single <code>address</code> subelement which contains
-                the PCI address of the SRIOV Physical Function (PF)
-                that is the parent of this device (and this device is,
-                by implication, an SRIOV Virtual Function (VF)). If
-                the type is <code>virtual_functions</code>, then this
-                device is an SRIOV PF, and the capability element will
-                have a list of <code>address</code> subelements, one
-                for each VF on this PF. If the host system supports
-                reporting it (via the "sriov_maxvfs" file in the
-                device's sysfs directory) the capability element will
-                also have an attribute named <code>maxCount</code>
-                which is the maximum number of SRIOV VFs supported by
-                this device, which could be higher than the number of
-                VFs that are curently active <span class="since">since
-                1.3.0</span>; in this case, even if there are
-                currently no active VFs the virtual_functions
-                capabililty will still be shown.
+                which will be set to:
+                <dl>
+                  <dt><code>physical_function</code></dt>
+                  <dd>
+                    That means there will be a single <code>address</code>
+                    subelement which contains the PCI address of the SRIOV
+                    Physical Function (PF) that is the parent of this device
+                    (and this device is, by implication, an SRIOV Virtual
+                    Function (VF)).
+                  </dd>
+                  <dt><code>virtual_function</code></dt>
+                  <dd>
+                    In this case this device is an SRIOV PF, and the capability
+                    element will have a list of <code>address</code>
+                    subelements, one for each VF on this PF. If the host system
+                    supports reporting it (via the "sriov_maxvfs" file in the
+                    device's sysfs directory) the capability element will also
+                    have an attribute named <code>maxCount</code> which is the
+                    maximum number of SRIOV VFs supported by this device, which
+                    could be higher than the number of VFs that are curently
+                    active <span class="since">since 1.3.0</span>; in this case,
+                    even if there are currently no active VFs the
+                    virtual_functions capabililty will still be shown.
+                  </dd>
+                  <dt><code>pci-bridge</code> or <code>cardbus-bridge</code></dt>
+                  <dd>
+                    This shows merely that the lower 7 bits of PCI header type
+                    have either value of 1 or 2 respectively.  Usually this
+                    means such device cannot be used for PCI passthrough.
+                    <span class="since">Since 1.3.3</span>
+                  </dd>
+                </dl>
               </dd>
               <dt><code>numa</code></dt>
               <dd>
--

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160318/97492261/attachment-0001.sig>