From: Jonathon Jongsma
- The generic format of a host device XML can be seen below.
- To identify a device both within the host and the device tree hierarchy,
- the following elements are used:
+ Details of the XML format of a host device can be found here. Of particular interest is the
+ capability element, which describes features supported by
+ the device. Some specific device types are addressed in more detail
+ below.
namepathparentname element or computer if the device does
- not have any parent.
- drivercapabilitytype the value of which determines
- the type of the device. Currently recognized values for the attribute
- are:
- system,
- pci,
- usb,
- usb_device,
- net,
- scsi,
- scsi_host (Since 0.4.7),
- fc_host,
- vports,
- scsi_target (Since 0.7.3),
- storage (Since 1.0.4),
- scsi_generic (Since 1.0.7),
- drm (Since 3.1.0), and
- mdev (Since 3.4.0).
- This element can be nested in which case it further specifies a
- device's capability. Refer to specific device types to see more values
- for the type attribute which are exclusive.
-
<device>
@@ -191,45 +143,14 @@
A PCI device capable of creating mediated devices will include a nested
capability mdev_types which enumerates all supported mdev
types on the physical device, along with the type attributes available
- through sysfs:
+ through sysfs. A detailed description of the XML format for the
+ mdev_types capability can be found
+ here.
-
- typeid which holds
- an official vendor-supplied identifier for the type.
- Since 3.4.0
- namename element holds a vendor-supplied code name for
- the given mediated device type. This is an optional element.
- Since 3.4.0
- deviceAPIavailableInstances- For a more info about mediated devices, refer to the - paragraph below. + The following example shows how we might represent an NVIDIA GPU device + that supports mediated devices. See below for more + information about mediated devices.
@@ -262,32 +183,11 @@
as multiple separate PCIe devices on the host's PCI bus, mediated devices
only appear on the mdev virtual bus. Therefore, no detach/reattach
procedure from/to the host driver procedure is involved even though
- mediated devices are used in a direct device assignment manner.
+ mediated devices are used in a direct device assignment manner. A
+ detailed description of the XML format for the mdev
+ capability can be found here.
-
- The following sub-elements and attributes are exposed within the
- capability element:
-
-
- typeid which holds
- an official vendor-supplied identifier for the type.
- Since 3.4.0
- iommuGroupnumber which holds
- the IOMMU group number the mediated device belongs to.
- Since 3.4.0
-
<device>
diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in
index 7dcd3638ff..76eae928de 100644
--- a/docs/formatnode.html.in
+++ b/docs/formatnode.html.in
@@ -33,9 +33,23 @@
to provide more specific names, such as
"net_eth1_00_27_13_6a_fe_00".
+ pathparentname element or computer if the device does
+ not have any parent.
+ driverdevnode/dev
@@ -138,8 +152,40 @@
means such device cannot be used for PCI passthrough.
Since 1.3.3
mdev_typestype
+ elements, which list all mdev types supported on the
+ physical device. Since 3.4.0
+ Each type element has a single id
+ attribute that holds an official vendor-supplied identifier
+ for the type. It supports the following sub-elements:
+ namename element holds a vendor-supplied
+ code name for the given mediated device type. This is
+ an optional element.
+ deviceAPIavailableInstancesnumarender.mdevtypeid which holds an official vendor-supplied
+ identifier for the type.
+ iommuGroupnumber
+ which holds the IOMMU group number the mediated device belongs
+ to.
+ ccw