External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 13:45:38 +00:00
Code Issues Packages Projects Releases Wiki Activity
79f738c510
libvirt/docs/formatnode.html.in

658 lines
30 KiB
HTML
Raw Normal View History

Fix multiple formatting problems in HTML docs The rule generating the HTML docs passing the --html flag to xsltproc. This makes it use the legacy HTML parser, which either ignores or tries to fix all sorts of broken XML tags. There's no reason why we should be writing broken XML in the first place, so removing --html and adding the XHTML doctype to all files forces us to create good XML. This adds the XHTML doc type and fixes many, many XML tag problems it exposes. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-03 14:25:37 +00:00
<?xml version="1.0" encoding="UTF-8"?>
docs: switch to using HTML5 doctype declaration The HTML5 doctype is simply <!DOCTYPE html> no DTD is present because HTML5 is no longer defined as an extension of SGML. XSL has no way to natively output a doctype without a public or system identifier, so we have to use an <xsl:text> hack instead. See also https://dev.w3.org/html5/html-author/#doctype-declaration Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 17:01:25 +00:00
<!DOCTYPE html>
Fix multiple formatting problems in HTML docs The rule generating the HTML docs passing the --html flag to xsltproc. This makes it use the legacy HTML parser, which either ignores or tries to fix all sorts of broken XML tags. There's no reason why we should be writing broken XML in the first place, so removing --html and adding the XHTML doctype to all files forces us to create good XML. This adds the XHTML doc type and fixes many, many XML tag problems it exposes. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-03 14:25:37 +00:00
<html xmlns="http://www.w3.org/1999/xhtml">
Split website out into one file per page. APply new layout and styling
2008-04-23 17:08:31 +00:00
<body>
<h1>Node devices XML format</h1>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<ul id="toc"></ul>
docs: switch to using 'id' attribute instead of 'name' for links The 'name' attribute on <a...> elements is deprecated in favour of the 'id' attribute which is allowed on any element. HTML5 drops 'name' support entirely. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 14:52:42 +00:00
<h2><a id="NodedevAttributes">Node Device XML</a></h2>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<p>
There are several libvirt functions, all with the
prefix <code>virNodeDevice</code>, which deal with management of
host devices that can be handed to guests via passthrough as
&lt;hostdev&gt; elements
doc: Fix reference to #elementsUSB aae0fc2a922b3e31dae7648c547fca2ac2587625 removed the #elementsUSB anchor but did not update the links to point to the new section #elementsHostDev. Signed-off-by: Philipp Hahn <hahn@univention.de>
2013-06-28 17:06:30 +00:00
in <a href="formatdomain.html#elementsHostDev">the domain XML</a>.
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
These devices are represented as a hierarchy, where a device on
a bus has a parent of the bus controller device; the root of the
hierarchy is the node named "computer".
</p>
<p>
When represented in XML, a node device uses the
top-level <code>device</code> element, with the following
elements present according to the type of device:
</p>
<dl>
<dt><code>name</code></dt>
<dd>The name for this device. The name will be alphanumeric,
with words separated by underscore. For many devices, the
name is just the bus type and address, as in
"pci_0000_00_02_1" or "usb_1_5_3", but some devices are able
to provide more specific names, such as
docs: note node device fields that are read-only As noted by Erik Skultety, we use the same XML schema to report existing devices and to define new devices. However, some schema elements are "read-only". In other words, they are used to report information from the node device driver and cannot be used to define a new device. Note these in the documentation. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-18 21:06:04 +00:00
"net_eth1_00_27_13_6a_fe_00". This is a read-only field that is
reported by the device driver. If this element is set when defining a
new device, it will be ignored.
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
</dd>
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
<dt><code>path</code></dt>
<dd>
docs: note node device fields that are read-only As noted by Erik Skultety, we use the same XML schema to report existing devices and to define new devices. However, some schema elements are "read-only". In other words, they are used to report information from the node device driver and cannot be used to define a new device. Note these in the documentation. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-18 21:06:04 +00:00
Fully qualified sysfs path to the device. This is a read-only field
that is reported by the device driver. If this element is set when
defining a new device, it will be ignored.
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
</dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dt><code>parent</code></dt>
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
<dd>
This element identifies the parent node in the device hierarchy. The
value of the element will correspond with the device parent's
<code>name</code> element or <code>computer</code> if the device does
not have any parent.
</dd>
<dt><code>driver</code></dt>
<dd>
This elements reports the driver in use for this device. The presence
of this element in the output XML depends on whether the underlying
device manager (most likely udev) exposes information about the
driver.
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
</dd>
nodedev: add <devnode> paths Add new <devnode> top-level <device> element, that list the associated /dev files. Distinguish the main /dev name from symlinks with a 'type' attribute of value 'dev' or 'symlink'. Update a test to check XML schema, and actually add it to the test list since it was missing. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-02-14 21:04:10 +00:00
<dt><code>devnode</code></dt>
<dd>This node appears for each associated <code>/dev</code>
special file. A mandatory attribute <code>type</code> specify
the kind of file path, which may be either <code>dev</code> for
the main name, or <code>link</code> for additional symlinks.
</dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dt><code>capability</code></dt>
<dd>This node appears for each capability that libvirt
associates with a node. A mandatory
attribute <code>type</code> lists which category the device
belongs to, and controls which further subelements will be
present to describe the node:
<dl>
<dt><code>system</code></dt>
<dd>Describes the overall host. Sub-elements include:
<dl>
<dt><code>product</code></dt>
<dd>If present, a simple text string giving the product
name of the system.</dd>
<dt><code>hardware</code></dt>
<dd>Describes the hardware of the system, including
sub-elements for <code>vendor</code>, <code>version</code>,
<code>serial</code>, and <code>uuid</code>.</dd>
<dt><code>firmware</code></dt>
<dd>Describes the firmware of the system, including
sub-elements for <code>vendor</code>, <code>version</code>,
and <code>release_date</code>.</dd>
</dl>
</dd>
<dt><code>pci</code></dt>
<dd>Describes a device on the host's PCI bus. Sub-elements
include:
<dl>
xml: nodedev: add class info for pci capability This info can be useful to filter devices visible to mgmt clients so that they won't see devices that unsafe/not meaningful to pass thru. Provide class info the way it is provided by udev or kernel that is as single 6-digit hexadecimal. Class element is not optional. I guess this should not break users that use virNodeDeviceCreateXML because they probably specify only scsi_host capability on input and then node device driver gets other capabilities from udev after device appeared. HAL driver does not get support for the new element in this patch. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-19 12:41:37 +00:00
<dt><code>class</code></dt>
xml: nodedev: make pci capability class element optional Commit 3bd4ed46 introduced this element as required which breaks backcompat for test driver. Let's make the element optional. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
2019-03-21 07:12:40 +00:00
<dd>Optional element for combined class, subclass and
xml: nodedev: add class info for pci capability This info can be useful to filter devices visible to mgmt clients so that they won't see devices that unsafe/not meaningful to pass thru. Provide class info the way it is provided by udev or kernel that is as single 6-digit hexadecimal. Class element is not optional. I guess this should not break users that use virNodeDeviceCreateXML because they probably specify only scsi_host capability on input and then node device driver gets other capabilities from udev after device appeared. HAL driver does not get support for the new element in this patch. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-19 12:41:37 +00:00
programming interface codes as 6-digit hexadecimal number.
<span class="since">Since 5.2.0</span></dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dt><code>domain</code></dt>
<dd>Which domain the device belongs to.</dd>
<dt><code>bus</code></dt>
<dd>Which bus within the domain.</dd>
<dt><code>slot</code></dt>
<dd>Which slot within the bus.</dd>
<dt><code>function</code></dt>
<dd>Which function within the slot.</dd>
<dt><code>product</code></dt>
<dd>Product details from the device ROM, including an
attribute <code>id</code> with the hexadecimal product
id, and an optional text description of that id.</dd>
<dt><code>vendor</code></dt>
<dd>Vendor details from the device ROM, including an
attribute <code>id</code> with the hexadecimal vendor
id, and an optional text name of that vendor.</dd>
nodedev: add iommuGroup to node device object This includes adding it to the nodedev parser and formatter, docs, and test. An example of the new iommuGroup element that is a part of the output from "virsh nodedev-dumpxml" (virNodeDeviceGetXMLDesc()): <device> <name>pci_0000_02_00_1</name> <capability type='pci'> ... <iommuGroup number='12'> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </iommuGroup> </capability> </device>
2013-06-23 18:01:00 +00:00
<dt><code>iommuGroup</code></dt>
<dd>
This optional element describes the "IOMMU group" this
device belongs to. If the element exists, it has a
mandatory <code>number</code> attribute which tells
the group number used for management of the group (all
devices in group "n" will be found in
"/sys/kernel/iommu_groups/n"). It will also have a
list of <code>address</code> subelements, each
containing the PCI address of a device in the same
group. The toplevel device will itself be included in
this list.
</dd>
<dt><code>capability</code></dt>
<dd>
This optional element can occur multiple times. If it
exists, it has a mandatory <code>type</code> attribute
nodedev: Expose PCI header type 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@redhat.com>
2016-03-15 11:22:03 +00:00
which will be set to:
<dl>
docs: Fix names for PF and VF PCI device capabilities The proper name for physical function capability is 'phys_function', not 'physical_function'. Likewise, a virtual function capability is 'virt_functions' rather than 'virtual_function'. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:34 +00:00
<dt><code>phys_function</code></dt>
nodedev: Expose PCI header type 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@redhat.com>
2016-03-15 11:22:03 +00:00
<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>
docs: Fix names for PF and VF PCI device capabilities The proper name for physical function capability is 'phys_function', not 'physical_function'. Likewise, a virtual function capability is 'virt_functions' rather than 'virtual_function'. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:34 +00:00
<dt><code>virt_functions</code></dt>
nodedev: Expose PCI header type 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@redhat.com>
2016-03-15 11:22:03 +00:00
<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
docs: fix name of file containing max number of VFs Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-07-28 09:16:24 +00:00
supports reporting it (via the "sriov_totalvfs" file in the
nodedev: Expose PCI header type 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@redhat.com>
2016-03-15 11:22:03 +00:00
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
docs: fix misc spelling errors reported by codespell Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-10-02 14:07:27 +00:00
could be higher than the number of VFs that are currently
nodedev: Expose PCI header type 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@redhat.com>
2016-03-15 11:22:03 +00:00
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>
docs: rename reference MDEVCap into MDEVTypesCapPCI Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-11-11 12:45:21 +00:00
<dt><code><a id="MDEVTypesCapPCI">mdev_types</a></code></dt>
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
<dd>
docs: refactor mdev_types into new paragraph To prevent copying the mdev_types description multiple times it is refactored into a new paragraph for easy reuse. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-11-11 12:45:20 +00:00
This device is capable of creating mediated devices.
The sub-elements are summarized in
<a href="#MDEVTypesCap">mdev_types capability</a>.
Add PCI VPD Capability Documentation Describes the format of the newly added VPD capability and gives and example for a real-world device. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
2021-10-20 08:30:34 +00:00
</dd>
<dt><code><a id="VPDCapPCI">vpd</a></code></dt>
<dd>
This device exposes a VPD PCI/PCIe capability.
The sub-elements are summarized in
<a href="#VPDCap">vpd capability</a>.
</dd>
nodedev: Expose PCI header type 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@redhat.com>
2016-03-15 11:22:03 +00:00
</dl>
nodedev: add iommuGroup to node device object This includes adding it to the nodedev parser and formatter, docs, and test. An example of the new iommuGroup element that is a part of the output from "virsh nodedev-dumpxml" (virNodeDeviceGetXMLDesc()): <device> <name>pci_0000_02_00_1</name> <capability type='pci'> ... <iommuGroup number='12'> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </iommuGroup> </capability> </device>
2013-06-23 18:01:00 +00:00
</dd>
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
nodedev: Export NUMA node locality for PCI devices A PCI device can be associated with a specific NUMA node. Later, when a guest is pinned to one NUMA node the PCI device can be assigned on different NUMA node. This makes DMA transfers travel across nodes and thus results in suboptimal performance. We should expose the NUMA node locality for PCI devices so management applications can make better decisions. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-05-07 16:07:12 +00:00
<dt><code>numa</code></dt>
<dd>
This optional element contains information on the PCI device
with respect to NUMA. For example, the optional
<code>node</code> attribute tells which NUMA node is the PCI
device associated with.
</dd>
nodedev: Introduce <pci-express/> to PCI devices This new element is there to represent PCI-Express capabilities of a PCI devices, like link speed, number of lanes, etc. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-05-15 08:13:45 +00:00
<dt><code>pci-express</code></dt>
<dd>
This optional element contains information on PCI Express part of
the device. For example, it can contain a child element
<code>link</code> which addresses the PCI Express device's link.
maint: remove incorrect apostrophes from 'its'
2015-06-03 10:10:36 +00:00
While a device has its own capabilities
nodedev: Introduce <pci-express/> to PCI devices This new element is there to represent PCI-Express capabilities of a PCI devices, like link speed, number of lanes, etc. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-05-15 08:13:45 +00:00
(<code>validity='cap'</code>), the actual run time capabilities
are negotiated on the device initialization
(<code>validity='sta'</code>). The <code>link</code> element then
contains three attributes: <code>port</code> which says in which
port is the device plugged in, <code>speed</code> (in
GigaTransfers per second) and <code>width</code> for the number
of lanes used. Since the port can't be negotiated, it's not
exposed in <code>./pci-express/link/[@validity='sta']</code>.
</dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
</dl>
</dd>
<dt><code>usb_device</code></dt>
<dd>Describes a device on the host's USB bus, based on its
location within the bus. Sub-elements include:
<dl>
<dt><code>bus</code></dt>
<dd>Which bus the device belongs to.</dd>
<dt><code>device</code></dt>
<dd>Which device within the bus.</dd>
<dt><code>product</code></dt>
<dd>Product details from the device ROM, including an
attribute <code>id</code> with the hexadecimal product
id, and an optional text description of that id.</dd>
<dt><code>vendor</code></dt>
<dd>Vendor details from the device ROM, including an
attribute <code>id</code> with the hexadecimal vendor
id, and an optional text name of that vendor.</dd>
</dl>
</dd>
<dt><code>usb</code></dt>
<dd>Describes a USB device, based on its advertised driver
interface. Sub-elements include:
<dl>
<dt><code>number</code></dt>
<dd>The device number.</dd>
docs: fix usb node device sub-element names
2013-08-15 09:36:11 +00:00
<dt><code>class</code></dt>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dd>The device class.</dd>
docs: fix usb node device sub-element names
2013-08-15 09:36:11 +00:00
<dt><code>subclass</code></dt>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dd>The device subclass.</dd>
docs: fix usb node device sub-element names
2013-08-15 09:36:11 +00:00
<dt><code>protocol</code></dt>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dd>The device protocol.</dd>
<dt><code>description</code></dt>
<dd>If present, a description of the device.</dd>
</dl>
</dd>
<dt><code>net</code></dt>
<dd>Describes a device capable for use as a network
interface. Sub-elements include:
<dl>
<dt><code>interface</code></dt>
<dd>The interface name tied to this device.</dd>
<dt><code>address</code></dt>
<dd>If present, the MAC address of the device.</dd>
node_device: Expose link state & speed While exposing the info under <interface/> in previous patch works, it may work only in cases where interface is configured on the host. However, orchestrating application may want to know the link state and speed even in that case. That's why we ought to expose this in nodedev XML too: virsh # nodedev-dumpxml net_eth0_f0_de_f1_2b_1b_f3 <device> <name>net_eth0_f0_de_f1_2b_1b_f3</name> <path>/sys/devices/pci0000:00/0000:00:19.0/net/eth0</path> <parent>pci_0000_00_19_0</parent> <capability type='net'> <interface>eth0</interface> <address>f0:de:f1:2b:1b:f3</address> <link speed='1000' state='up'/> <capability type='80203'/> </capability> </device> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 15:36:31 +00:00
<dt><code>link</code></dt>
<dd>Optional to reflect the status of the link. It has
two optional attributes: <code>speed</code> in Mbits per
second and <code>state</code> to tell the state of the
link. So far, the whole element is just for output,
not setting.
</dd>
SRIOV NIC offload feature discovery Adding functionality to libvirt that will allow it query the ethtool interface for the availability of certain NIC HW offload features Here is an example of the feature XML definition: <device> <name>net_eth4_90_e2_ba_5e_a5_45</name> <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/net/eth4</path> <parent>pci_0000_08_00_1</parent> <capability type='net'> <interface>eth4</interface> <address>90:e2:ba:5e:a5:45</address> <link speed='10000' state='up'/> <feature name='rx'/> <feature name='tx'/> <feature name='sg'/> <feature name='tso'/> <feature name='gso'/> <feature name='gro'/> <feature name='rxvlan'/> <feature name='txvlan'/> <feature name='rxhash'/> <capability type='80203'/> </capability> </device> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2015-02-23 15:38:29 +00:00
<dt><code>feature</code></dt>
<dd>If present, the hw offloads supported by this network
interface. Possible features are:
<dl>
<dt><code>rx</code></dt><dd>rx-checksumming</dd>
<dt><code>tx</code></dt><dd>tx-checksumming</dd>
<dt><code>sg</code></dt><dd>scatter-gather</dd>
<dt><code>tso</code></dt><dd>tcp-segmentation-offload</dd>
<dt><code>ufo</code></dt><dd>udp-fragmentation-offload</dd>
<dt><code>gso</code></dt><dd>generic-segmentation-offload</dd>
<dt><code>gro</code></dt><dd>generic-receive-offload</dd>
<dt><code>lro</code></dt><dd>large-receive-offload</dd>
<dt><code>rxvlan</code></dt><dd>rx-vlan-offload</dd>
<dt><code>txvlan</code></dt><dd>tx-vlan-offload</dd>
<dt><code>ntuple</code></dt><dd>ntuple-filters</dd>
<dt><code>rxhash</code></dt><dd>receive-hashing</dd>
nodedev: add RDMA and tx-udp_tnl-segmentation NIC capabilities Adding functionality to libvirt that will allow it query the interface for the availability of RDMA and tx-udp_tnl-segmentation Offloading NIC capabilities Here is an example of the feature XML definition: <device> <name>net_eth4_90_e2_ba_5e_a5_45</name> <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/net/eth4</path> <parent>pci_0000_08_00_1</parent> <capability type='net'> <interface>eth4</interface> <address>90:e2:ba:5e:a5:45</address> <link speed='10000' state='up'/> <feature name='rx'/> <feature name='tx'/> <feature name='sg'/> <feature name='tso'/> <feature name='gso'/> <feature name='gro'/> <feature name='rxvlan'/> <feature name='txvlan'/> <feature name='rxhash'/> <feature name='rdma'/> <feature name='txudptnl'/> <capability type='80203'/> </capability> </device>
2015-07-19 10:11:07 +00:00
<dt><code>rdma</code></dt><dd>remote-direct-memory-access</dd>
<dt><code>txudptnl</code></dt><dd>tx-udp-tunnel-segmentation</dd>
nodedev: add switchdev to NIC capabilities Adding functionality to libvirt that will allow querying the interface for the availability of switchdev Offloading NIC capabilities. The switchdev mode was introduced in kernel 4.8, the iproute2-devlink command to retrieve the switchdev NIC feature with command example: devlink dev eswitch show pci/0000:03:00.0 This feature is needed for Openstack so we can do a scheduling decision if the NIC is in Hardware Offload (switchdev) or regular SR-IOV (legacy) mode. And select the appropriate hypervisors with the requested capability see [1]. [1] - https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/enable-sriov-nic-features.html Reviewed-by: Laine Stump <laine@laine.org> Reviewed-by: John Ferlan <jferlan@redhat.com>
2017-08-21 09:19:53 +00:00
<dt><code>switchdev</code></dt><dd>kernel-forward-plane-offload</dd>
SRIOV NIC offload feature discovery Adding functionality to libvirt that will allow it query the ethtool interface for the availability of certain NIC HW offload features Here is an example of the feature XML definition: <device> <name>net_eth4_90_e2_ba_5e_a5_45</name> <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/net/eth4</path> <parent>pci_0000_08_00_1</parent> <capability type='net'> <interface>eth4</interface> <address>90:e2:ba:5e:a5:45</address> <link speed='10000' state='up'/> <feature name='rx'/> <feature name='tx'/> <feature name='sg'/> <feature name='tso'/> <feature name='gso'/> <feature name='gro'/> <feature name='rxvlan'/> <feature name='txvlan'/> <feature name='rxhash'/> <capability type='80203'/> </capability> </device> Signed-off-by: Ján Tomko <jtomko@redhat.com>
2015-02-23 15:38:29 +00:00
</dl>
</dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dt><code>capability</code></dt>
<dd>A network protocol exposed by the device, where the
attribute <code>type</code> can be "80203" for IEEE
802.3, or "80211" for various flavors of IEEE 802.11.
npiv: Expose fabric_name outside This patch is to expose the fabric_name of fc_host class, which might be useful for users who wants to known which fabric the (v)HBA connects to. The patch also adds the missed capabilities' XML schema of scsi_host, (of course, with fabric_wwn added), and update the documents (docs/formatnode.html.in)
2011-12-06 12:09:03 +00:00
</dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
</dl>
</dd>
<dt><code>scsi_host</code></dt>
<dd>Describes a SCSI host device. Sub-elements include:
<dl>
<dt><code>host</code></dt>
<dd>The SCSI host number.</dd>
Add unique_id to nodedev output Add an optional unique_id parameter to nodedev. Allows for easier lookup and display of the unique_id value in order to document for use with scsi_host code.
2014-06-05 17:17:05 +00:00
<dt><code>unique_id</code></dt>
<dd>On input, this optionally provides the value from the
'unique_id' file found in the scsi_host's directory. To
view the values of all 'unique_id' files, use <code>find -H
/sys/class/scsi_host/host{0..9}/unique_id |
xargs grep '[0-9]'</code>. On output, if the unique_id
file exists, the value from the file will be displayed.
This can be used in order to help uniquely identify the
scsi_host adapter in a <a href="formatstorage.html">
Storage Pool</a>. <span class="since">Since 1.2.7</span>
</dd>
npiv: Expose fabric_name outside This patch is to expose the fabric_name of fc_host class, which might be useful for users who wants to known which fabric the (v)HBA connects to. The patch also adds the missed capabilities' XML schema of scsi_host, (of course, with fabric_wwn added), and update the documents (docs/formatnode.html.in)
2011-12-06 12:09:03 +00:00
<dt><code>capability</code></dt>
<dd>Current capabilities include "vports_ops" (indicates
nodedev: Dump max vports and vports in use for HBA's XML This enrichs HBA's xml by dumping the number of max vports and vports in use. Format is like: <capability type='vport_ops'> <max_vports>164</max_vports> <vports>5</vports> </capability> * docs/formatnode.html.in: (Document the new XML) * docs/schemas/nodedev.rng: (Add the schema) * src/conf/node_device_conf.h: (New member for data.scsi_host) * src/node_device/node_device_linux_sysfs.c: (Collect the value of max_vports and vports)
2013-01-07 17:05:32 +00:00
vport operations are supported) and "fc_host". "vport_ops"
could contain two optional sub-elements: <code>vports</code>,
and <code>max_vports</code>. <code>vports</code> shows the
number of vport in use. <code>max_vports</code> shows the
maximum vports the HBA supports. "fc_host" implies following
sub-elements: <code>wwnn</code>, <code>wwpn</code>, and
nodedev: Fabric name must not be required for fc_host capability fabric_name is one of many fc_host attributes in Linux that is optional and left to the low-level driver to decide if it is implemented. The zfcp device driver does not provide a fabric name for an fcp host. This patch removes the requirement for a fabric name by making it optional. Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2017-01-16 13:27:34 +00:00
optionally <code>fabric_wwn</code>.
npiv: Expose fabric_name outside This patch is to expose the fabric_name of fc_host class, which might be useful for users who wants to known which fabric the (v)HBA connects to. The patch also adds the missed capabilities' XML schema of scsi_host, (of course, with fabric_wwn added), and update the documents (docs/formatnode.html.in)
2011-12-06 12:09:03 +00:00
</dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
</dl>
</dd>
<dt><code>scsi</code></dt>
Fix some typos in messages, docs and comments.
2012-08-22 18:29:18 +00:00
<dd>Describes a SCSI device. Sub-elements include:
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<dl>
<dt><code>host</code></dt>
<dd>The SCSI host containing the device.</dd>
<dt><code>bus</code></dt>
<dd>The bus within the host.</dd>
<dt><code>target</code></dt>
<dd>The target within the bus.</dd>
<dt><code>lun</code></dt>
<dd>The lun within the target.</dd>
<dt><code>type</code></dt>
<dd>The type of SCSI device.</dd>
</dl>
</dd>
<dt><code>storage</code></dt>
<dd>Describes a device usable for storage. Sub-elements
include:
<dl>
<dt><code>block</code></dt>
<dd>A block device file name that accesses the storage
present on the device.</dd>
<dt><code>bus</code></dt>
<dd>If present, the name of the bus the device is found
on.</dd>
<dt><code>drive_type</code></dt>
<dd>The type of the drive, such as "disk" or
"cdrom".</dd>
<dt><code>model</code></dt>
<dd>Any model information available from the
device.</dd>
<dt><code>vendor</code></dt>
<dd>Any vendor information available from the
device.</dd>
<dt><code>serial</code></dt>
<dd>Any serial number information available from the
device.</dd>
<dt><code>size</code></dt>
<dd>For fixed-size storage, the amount of storage
available.</dd>
<dt><code>capability</code></dt>
<dd>If present, an additional capability is listed via
Fix some typos in messages, docs and comments.
2012-08-22 18:29:18 +00:00
the attribute <code>type</code>. Current capabilities
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
include "hotpluggable" and "removable", with the
latter implying the following
sub-elements: <code>media_available</code> (0 or
1), <code>media_size</code>,
and <code>media_label</code>.</dd>
</dl>
</dd>
nodedev: add drm capability Add a new 'drm' capability for Direct Rendering Manager (DRM) devices, providing device type information. Teach the udev backend to populate those devices. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2017-02-14 21:04:12 +00:00
<dt><code>drm</code></dt>
<dd>Describes a Direct Rendering Manager (DRM) device.
Sub-elements include:
<dl>
<dt><code>type</code></dt>
<dd>The type of DRM device. Could be
<code>primary</code>, <code>control</code> or
<code>render</code>.</dd>
</dl>
</dd>
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
<dt><a id="mdev"><code>mdev</code></a></dt>
<dd>Describes a mediated device. <span class="since">Since
3.4.0</span> Sub-elements include:
<dl>
<dt><code>type</code></dt>
<dd>
Describes a mediated device type which acts as an abstract
template defining a resource allocation for instances
of this device type. The element has one attribute
<code>id</code> which holds an official vendor-supplied
identifier for the type.
</dd>
<dt><code>iommuGroup</code></dt>
<dd>
This element supports a single attribute <code>number</code>
nodedev: make iommuGroup optional for mdevs When parsing a nodedev xml file, the iommuGroup element should be optional. This element should be read-only and is determined by the device driver. While this is a change to existing behavior, it doesn't break backwards-compatibility because it makes the parser less strict. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-18 21:05:54 +00:00
which holds the IOMMU group number to which the mediated device
belongs. This is a read-only field that is reported by the
device driver.
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
</dd>
nodedev: add support for mdev attributes Mediated devices support arbitrary vendor-specific attributes that can be attached to a mediated device. These attributes are ordered, and are written to sysfs in order after a device is created. This patch adds support for these attributes to the mdev data types and XML schema. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-18 21:05:56 +00:00
<dt><code>attr</code></dt>
<dd>
This optional element can occur multiple times. It represents a
vendor-specific attribute that is used to configure this
mediated device. It has two required attributes:
nodedev: add docs about mdev attribute order Mention that mdev attribute order is significant. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2021-02-22 19:58:05 +00:00
<code>name</code> and <code>value</code>. Note that the order
in which attributes are set may be important for some devices.
The order that they appear in the xml definition determines the
order that they will be written to the device.
nodedev: add support for mdev attributes Mediated devices support arbitrary vendor-specific attributes that can be attached to a mediated device. These attributes are ordered, and are written to sysfs in order after a device is created. This patch adds support for these attributes to the mdev data types and XML schema. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-18 21:05:56 +00:00
</dd>
docs: nodedev: document mdev uuid property Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-05-14 21:29:01 +00:00
<dt><code>uuid</code></dt>
<dd>
This element represents the UUID of the mediated device.
</dd>
docs: Document full node device xml in formatnode.html.in Some of the node device xml schema was documented in drvnodedev.html.in rather than in formatnode.html.in. Move all of the schema documentation to formatnode.html.in and provide reference links from the drvnodedev.html.in page. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-05-21 20:09:35 +00:00
</dl>
</dd>
virsh: nodedev: ability to filter CCW capabilities Now that the node_device driver is aware of CCW devices, let's hook up virsh so that we can filter them properly. Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
2017-05-22 06:38:23 +00:00
<dt><code>ccw</code></dt>
<dd>Describes a Command Channel Word (CCW) device commonly found on
the S390 architecture. Sub-elements include:
<dl>
virsh: nodedev: ability to filter CSS capabilities Allow to filter for CSS devices. Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
2020-09-14 19:11:45 +00:00
<dt><code>cssid</code></dt>
<dd>The channel subsystem identifier.</dd>
<dt><code>ssid</code></dt>
<dd>The subchannel-set identifier.</dd>
<dt><code>devno</code></dt>
<dd>The device number.</dd>
</dl>
</dd>
<dt><code>css</code></dt>
docs: Clarify the documentation of the <css> elements The channel subsystem elements describe a channel in the I/O subsystem of a s390x machine, and not a normal device (like a disk or network card). Reword the documentation here to make it this a little bit clearer. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1898074 Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2021-01-29 14:37:26 +00:00
<dd>Describes a subchannel in the Channel SubSystem (CSS) commonly
found on the S390 architecture. Sub-elements include:
virsh: nodedev: ability to filter CSS capabilities Allow to filter for CSS devices. Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
2020-09-14 19:11:45 +00:00
<dl>
virsh: nodedev: ability to filter CCW capabilities Now that the node_device driver is aware of CCW devices, let's hook up virsh so that we can filter them properly. Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
2017-05-22 06:38:23 +00:00
<dt><code>cssid</code></dt>
<dd>The channel subsystem identifier.</dd>
<dt><code>ssid</code></dt>
<dd>The subchannel-set identifier.</dd>
<dt><code>devno</code></dt>
docs: Clarify the documentation of the <css> elements The channel subsystem elements describe a channel in the I/O subsystem of a s390x machine, and not a normal device (like a disk or network card). Reword the documentation here to make it this a little bit clearer. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1898074 Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
2021-01-29 14:37:26 +00:00
<dd>The subchannel number.</dd>
node_device: detecting mdev_types capability on CSS devices Add detection of mdev_types capability to channel subsystem devices. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-11-11 12:45:22 +00:00
<dt><code>capability</code></dt>
<dd>
This optional element can occur multiple times. If it
exists, it has a mandatory <code>type</code> attribute
which will be set to:
<dl>
<dt><code><a id="MDEVTypesCapCSS">mdev_types</a></code></dt>
<dd>
<span class="since">Since 6.10.0</span>
This device is capable of creating mediated devices.
The sub-elements are summarized in
<a href="#MDevTypesCap">mdev_types capability</a>.
</dd>
</dl>
</dd>
virsh: nodedev: ability to filter CCW capabilities Now that the node_device driver is aware of CCW devices, let's hook up virsh so that we can filter them properly. Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com> Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
2017-05-22 06:38:23 +00:00
</dl>
</dd>
Include vdpa devices in node device list The current udev node device driver ignores all events related to vdpa devices. Since libvirt now supports vDPA network devices, include these devices in the device list. Example output: virsh # nodedev-list [...ommitted long list of nodedevs...] vdpa_vdpa0 virsh # nodedev-dumpxml vdpa_vdpa0 <device> <name>vdpa_vdpa0</name> <path>/sys/devices/vdpa0</path> <parent>computer</parent> <driver> <name>vhost_vdpa</name> </driver> <capability type='vdpa'> <chardev>/dev/vhost-vdpa-0</chardev> </capability> </device> NOTE: normally the 'parent' would be a PCI device instead of 'computer', but this example output is from the vdpa_sim kernel module, so it doesn't have a normal parent device. Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
2020-10-14 17:08:30 +00:00
<dt><code>vdpa</code></dt>
<dd>Describes a virtual datapath acceleration (vDPA) network device.
<span class="since">Since 6.9.0</span>. Sub-elements include:
<dl>
<dt><code>chardev</code></dt>
<dd>The path to the character device that is used to access the
device.</dd>
</dl>
</dd>
nodedev: detect AP card device Introduce support for the Adjunct Processor (AP) crypto card device. Udev already detects the device, so add support for libvirt nodedev driver. https://www.kernel.org/doc/html/latest/s390/vfio-ap.html#ap-architectural-overview Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-12-03 17:59:33 +00:00
<dt><code>ap_card</code></dt>
<dd>Describes the Adjunct Processor (AP) Card device on a S390 host.
Sub-elements include:
<dl>
<dt><code>ap-adapter</code></dt>
<dd>AP Card identifier.</dd>
</dl>
</dd>
nodedev: detect AP queues Each AP card device can support upto 256 AP queues. AP queues are also detected by udev, so add support for libvirt nodedev driver. https://www.kernel.org/doc/html/latest/s390/vfio-ap.html#ap-architectural-overview Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-12-03 17:59:35 +00:00
<dt><code>ap_queue</code></dt>
<dd>Describes the AP queue on a s390 host. An AP queue is
an AP domain on an AP adapter which is specified by an
adapter identifier and a domain identifier.
Sub-elements include:
<dl>
<dt><code>ap-adapter</code></dt>
<dd>The ap-adapter of an AP queue identifies the AP
card to which this AP queue belongs.</dd>
<dt><code>ap-domain</code></dt>
<dd>The ap-domain of an AP queue identifies the AP
domain to which this AP queue belongs.</dd>
<dd>AP Queue identifier.</dd>
</dl>
</dd>
virsh: nodedev: filter by AP Matrix capability Add support to filter by 'ap_matrix' capability. Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-12-03 17:59:40 +00:00
<dt><code>ap_matrix</code></dt>
<dd>Describes an AP Matrix device on a S390 architecture providing
node_device: detecting mdev_types capability on ap_matrix device Add detection of mdev_types capability to Adjunct Processor Matrix device. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Jonathon Jongsma<jjongsma@redhat.com> Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-12-03 17:59:43 +00:00
cryptographic host resources usable for virtualization.
Sub-elements include:
<dl>
<dt><code>capability</code></dt>
<dd>
This optional element can occur multiple times. If it
exists, it has a mandatory <code>type</code> attribute
which will be set to:
<dl>
<dt><code><a id="MDEVTypesCapAP">mdev_types</a></code></dt>
<dd>
<span class="since">Since 6.10.0</span>
This device is capable of creating mediated devices.
The sub-elements are summarized in
<a href="#MDEVTypesCap">mdev_types capability</a>.
</dd>
</dl>
</dd>
</dl>
</dd>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
</dl>
</dd>
</dl>
docs: refactor mdev_types into new paragraph To prevent copying the mdev_types description multiple times it is refactored into a new paragraph for easy reuse. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-11-11 12:45:20 +00:00
<h3><a id="MDEVTypesCap">mdev_types capability</a></h3>
<p>
node_device: detecting mdev_types capability on ap_matrix device Add detection of mdev_types capability to Adjunct Processor Matrix device. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Jonathon Jongsma<jjongsma@redhat.com> Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-12-03 17:59:43 +00:00
<a href="#MDEVTypesCapPCI">PCI</a>, <a href="#MDEVTypesCapCSS">CSS</a>
and <a href="#MDEVTypesCapAP">AP Matrix</a>
node_device: detecting mdev_types capability on CSS devices Add detection of mdev_types capability to channel subsystem devices. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-11-11 12:45:22 +00:00
devices can be capable of creating mediated devices.
If they indeed are capable, then the parent <code>capability</code>
element for <code>mdev_types</code> type will contain a list of
docs: refactor mdev_types into new paragraph To prevent copying the mdev_types description multiple times it is refactored into a new paragraph for easy reuse. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-11-11 12:45:20 +00:00
<code>type</code> elements, which list all mdev types supported
on the physical device. <span class="since">Since 3.4.0</span>
Each <code>type</code> element has a single <code>id</code>
attribute that holds an official vendor-supplied identifier
for the type. It supports the following sub-elements:
<dl>
<dt><code>name</code></dt>
<dd>
The <code>name</code> element holds a vendor-supplied
code name for the given mediated device type. This is
an optional element.
</dd>
<dt><code>deviceAPI</code></dt>
<dd>
The value of this element describes how an instance of
the given type will be presented to the guest by the
VFIO framework.
</dd>
<dt><code>availableInstances</code></dt>
<dd>
This element reports the current state of resource
allocation. In other words, how many instances of the
given type can still be successfully created on the
physical device.
</dd>
</dl>
</p>
Add PCI VPD Capability Documentation Describes the format of the newly added VPD capability and gives and example for a real-world device. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
2021-10-20 08:30:34 +00:00
<h3><a id="VPDCap">vpd capability</a></h3>
<p>
<a href="#VPDCapPCI">PCI</a> devices can expose a VPD capability which
is optional per PCI Local Bus 2.2+ and PCIe 4.0+ specifications. If
the VPD capability is present, then the parent <code>capability</code>
element with the <code>vpd</code> type will contain a <code>name</code>
element (containing a manufacturer-provided device name) and optionally
one or two <code>fields</code> elements with an <code>access</code>
attribute set to <code>readonly</code> or <code>readwrite</code>.
</p>
<p>
The read-only <code>fields</code> element may contain the following elements:
<dl>
<dt><code>change_level</code></dt>
<dd>An engineering change level for this add-in card.</dd>
<dt><code>manufacture_id</code></dt>
<dd>An extension to the Vendor ID (or Subsystem Vendor ID) in the
Configuration Space header which allows vendors the flexibility to identify
an additional level of detail pertaining to the sourcing of a PCI device.</dd>
<dt><code>part_number</code></dt>
<dd>An extension to the Device ID (or Subsystem ID) in the Configuration
Space header specifying a part number of an add-in card.</dd>
<dt><code>serial_number</code></dt>
<dd>A unique add-in card Serial Number.</dd>
<dt><code>vendor_field</code></dt>
<dd>Zero or many of those elements with an <code>index</code> attribute
(since-character upper-case ASCII alphanumeric indexes). Contents will vary
depending on a vendor.</dd>
</dl>
All fields are optional and are not guaranteed to be present for a generic PCI device.
</p>
<p>
The read-write <code>fields</code> element may contain the following elements:
<dl>
<dt><code>asset_tag</code></dt>
<dd>A system asset identifier provided by the system owner.</dd>
<dt><code>vendor_field</code></dt>
<dd>Zero or many of those elements with an <code>index</code> attribute
(since-character upper-case ASCII alphanumeric indexes). Contents will vary depending
on a vendor.</dd>
<dt><code>system_field</code></dt>
<dd>Zero or many of those elements with an <code>index</code> attribute (since-character
upper-case ASCII alphanumeric indexes, except for letter 'A'). May store system-specific
data related to a PCI device.</dd>
</dl>
All fields are optional and are not guaranteed to be present for a generic PCI device.
Read-write fields are not possible to alter via Libvirt at the time of writing but their
content is refreshed on each invocation in case this is done by means external to Libvirt.
</p>
<p>
The device name and all fields may contain only the following characters:
<code>[0-9a-zA-F -_,.:;=]</code>.
The device name may be as large as 65535 bytes while fields are limited with 255 bytes.
</p>
docs: refactor mdev_types into new paragraph To prevent copying the mdev_types description multiple times it is refactored into a new paragraph for easy reuse. Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-11-11 12:45:20 +00:00
docs: switch to using 'id' attribute instead of 'name' for links The 'name' attribute on <a...> elements is deprecated in favour of the 'id' attribute which is allowed on any element. HTML5 drops 'name' support entirely. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 14:52:42 +00:00
<h2><a id="nodeExample">Examples</a></h2>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
<p>The following are some example node device XML outputs:</p>
<pre>
&lt;device&gt;
&lt;name&gt;computer&lt;/name&gt;
&lt;capability type='system'&gt;
&lt;product&gt;2241B36&lt;/product&gt;
&lt;hardware&gt;
&lt;vendor&gt;LENOVO&lt;/vendor&gt;
&lt;version&gt;ThinkPad T500&lt;/version&gt;
&lt;serial&gt;R89055N&lt;/serial&gt;
&lt;uuid&gt;c9488981-5049-11cb-9c1c-993d0230b4cd&lt;/uuid&gt;
&lt;/hardware&gt;
&lt;firmware&gt;
&lt;vendor&gt;LENOVO&lt;/vendor&gt;
&lt;version&gt;6FET82WW (3.12 )&lt;/version&gt;
&lt;release_date&gt;11/26/2009&lt;/release_date&gt;
&lt;/firmware&gt;
&lt;/capability&gt;
&lt;/device&gt;
&lt;device&gt;
&lt;name&gt;net_eth1_00_27_13_6a_fe_00&lt;/name&gt;
&lt;parent&gt;pci_0000_00_19_0&lt;/parent&gt;
&lt;capability type='net'&gt;
&lt;interface&gt;eth1&lt;/interface&gt;
&lt;address&gt;00:27:13:6a:fe:00&lt;/address&gt;
&lt;capability type='80203'/&gt;
&lt;/capability&gt;
nodedev: add iommuGroup to node device object This includes adding it to the nodedev parser and formatter, docs, and test. An example of the new iommuGroup element that is a part of the output from "virsh nodedev-dumpxml" (virNodeDeviceGetXMLDesc()): <device> <name>pci_0000_02_00_1</name> <capability type='pci'> ... <iommuGroup number='12'> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </iommuGroup> </capability> </device>
2013-06-23 18:01:00 +00:00
&lt;/device&gt;
&lt;device&gt;
&lt;name&gt;pci_0000_02_00_0&lt;/name&gt;
&lt;path&gt;/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0&lt;/path&gt;
&lt;parent&gt;pci_0000_00_04_0&lt;/parent&gt;
&lt;driver&gt;
&lt;name&gt;igb&lt;/name&gt;
&lt;/driver&gt;
&lt;capability type='pci'&gt;
xml: nodedev: add class info for pci capability This info can be useful to filter devices visible to mgmt clients so that they won't see devices that unsafe/not meaningful to pass thru. Provide class info the way it is provided by udev or kernel that is as single 6-digit hexadecimal. Class element is not optional. I guess this should not break users that use virNodeDeviceCreateXML because they probably specify only scsi_host capability on input and then node device driver gets other capabilities from udev after device appeared. HAL driver does not get support for the new element in this patch. Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-19 12:41:37 +00:00
&lt;class&gt;0x020000&lt;/class&gt;
nodedev: add iommuGroup to node device object This includes adding it to the nodedev parser and formatter, docs, and test. An example of the new iommuGroup element that is a part of the output from "virsh nodedev-dumpxml" (virNodeDeviceGetXMLDesc()): <device> <name>pci_0000_02_00_1</name> <capability type='pci'> ... <iommuGroup number='12'> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </iommuGroup> </capability> </device>
2013-06-23 18:01:00 +00:00
&lt;domain&gt;0&lt;/domain&gt;
&lt;bus&gt;2&lt;/bus&gt;
&lt;slot&gt;0&lt;/slot&gt;
&lt;function&gt;0&lt;/function&gt;
&lt;product id='0x10c9'&gt;82576 Gigabit Network Connection&lt;/product&gt;
&lt;vendor id='0x8086'&gt;Intel Corporation&lt;/vendor&gt;
&lt;capability type='virt_functions'&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x0'/&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x2'/&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x4'/&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x10' function='0x6'/&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x11' function='0x0'/&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x11' function='0x2'/&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x11' function='0x4'/&gt;
&lt;/capability&gt;
&lt;iommuGroup number='12'&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/&gt;
&lt;address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/&gt;
&lt;/iommuGroup&gt;
nodedev: Introduce <pci-express/> to PCI devices This new element is there to represent PCI-Express capabilities of a PCI devices, like link speed, number of lanes, etc. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-05-15 08:13:45 +00:00
&lt;pci-express&gt;
&lt;link validity='cap' port='1' speed='2.5' width='1'/&gt;
&lt;link validity='sta' speed='2.5' width='1'/&gt;
&lt;/pci-express&gt;
nodedev: add iommuGroup to node device object This includes adding it to the nodedev parser and formatter, docs, and test. An example of the new iommuGroup element that is a part of the output from "virsh nodedev-dumpxml" (virNodeDeviceGetXMLDesc()): <device> <name>pci_0000_02_00_1</name> <capability type='pci'> ... <iommuGroup number='12'> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </iommuGroup> </capability> </device>
2013-06-23 18:01:00 +00:00
&lt;/capability&gt;
&lt;/device&gt;
</pre>
docs: document node device XML Coupled with the recent virsh nodedev-* doc patch, this should now give a better picture of libvirt node device handling. * docs/formatnode.html.in: Fill in page.
2011-09-27 17:04:52 +00:00
Split website out into one file per page. APply new layout and styling
2008-04-23 17:08:31 +00:00
</body>
</html>
Reference in New Issue Copy Permalink