2:28 a.m.
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(a)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