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@xxxxxxxxxx> --- 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.xmlWill 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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list