From nobody Thu Apr 25 21:18:22 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) client-ip=207.211.31.120; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1590091797; cv=none; d=zohomail.com; s=zohoarc; b=baNIP+gXXr6rDUFWz5GElk5oderjhFyo6yJxinsnISpyp0KMZw9ZoaWtqy4foQUu9wxuHZLkPkDQEPzpWCDdTXABDc5w4LZUfMOIAVmfk0s4CJnxTyqXL1hKqyIYygPZX1XPxMfDp+9FORqmJgUR7mjXHFLbV0ecWRZHCeJzxBw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1590091797; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=r5I5YQllD03dwgexK7ClWr5WQoQt+aolGwjpgeLhEe4=; b=DExVMpc8DcWmGVa+rwoMWQDlB6IB0YzMKFz3xLNdnWVhugpVf51+b6ilVCfypeBNV4zrPd9iIlpgheyte06vO6IjW5xd8H8ry8RrdITFum+fekCitZ0WaodL44tMEJZ9NEmBfB1Spo8p1r/44yL++60MZuCseThcakQMfxu24nc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by mx.zohomail.com with SMTPS id 1590091797197591.2886575573082; Thu, 21 May 2020 13:09:57 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-491-j1l75nBvNlqMI5q4wJVDrw-1; Thu, 21 May 2020 16:09:54 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4F16E100A61D; Thu, 21 May 2020 20:09:48 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 08AF260C05; Thu, 21 May 2020 20:09:48 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id BE1D654D06; Thu, 21 May 2020 20:09:47 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 04LK9dRD028369 for ; Thu, 21 May 2020 16:09:39 -0400 Received: by smtp.corp.redhat.com (Postfix) id A2AB25632D; Thu, 21 May 2020 20:09:39 +0000 (UTC) Received: from himantopus.redhat.com (ovpn-112-181.phx2.redhat.com [10.3.112.181]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 75E7F56324 for ; Thu, 21 May 2020 20:09:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590091796; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=r5I5YQllD03dwgexK7ClWr5WQoQt+aolGwjpgeLhEe4=; b=HBNESI+EBIJgIyztRHuc+0EUdEioJwOHUIud3WWMrsXgwdPttsK3au2V3SDFAJN/5QBvUX AiJVAB1AIuveIjHe19kLWn2BsqDgS2+OMMLDpwJsIuwEmuVu/7W0kdilwv00MOXFHLi/eU /PCKBTaoc1BhxsZXesgZbR7dCQVWyUo= X-MC-Unique: j1l75nBvNlqMI5q4wJVDrw-1 From: Jonathon Jongsma To: libvir-list@redhat.com Subject: [libvirt PATCH 1/2] docs: Fix names for PF and VF PCI device capabilities Date: Thu, 21 May 2020 15:09:34 -0500 Message-Id: <20200521200935.19237-2-jjongsma@redhat.com> In-Reply-To: <20200521200935.19237-1-jjongsma@redhat.com> References: <20200521200935.19237-1-jjongsma@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" 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 Reviewed-by: Erik Skultety --- docs/formatnode.html.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in index c2a8f8fb7a..7dcd3638ff 100644 --- a/docs/formatnode.html.in +++ b/docs/formatnode.html.in @@ -109,7 +109,7 @@ exists, it has a mandatory type attribute which will be set to:
-
physical_function
+
phys_function
That means there will be a single address subelement which contains the PCI address of the SRIOV @@ -117,7 +117,7 @@ (and this device is, by implication, an SRIOV Virtual Function (VF)).
-
virtual_function
+
virt_functions
In this case this device is an SRIOV PF, and the capab= ility element will have a list of address --=20 2.21.3 From nobody Thu Apr 25 21:18:22 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1590091794; cv=none; d=zohomail.com; s=zohoarc; b=WaScwo53pFNEoPYRNId0K/2mGA0cvyoYRQx2SOkBdhGi9waoRseSw1m2KyhApAlCksiQWxMpFIC8fWr0I7mhTdWLUZVHqKtv8hg73ZVJK1/uS/kraYyZKiETY5w1wchPWhJoy3Mo+uB14aFAc0rrqAfS0YSmxasqpl3NR38Fwnw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1590091794; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=rL8oNXEa4c57bLrbpJlMrhQKcJHeBXUrznT1oeOeU9k=; b=kUtgAFKBPGP2q88RpFl6Md3z0o6s54MiWvlZdkocF+eVyV9LhcH4P0sjiHCbrup7yFAOLOf2nNN11InqLiG8UfQ9ZPRqFlwy8/cvNM+KQGgSaXC8mPFJ/TMTn8/pKrCZ+M0RWxFfO2D04Nfem2Oqsyt7bLKL0pknjHXGU+hGnCo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1590091794427812.2168964892492; Thu, 21 May 2020 13:09:54 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-407-NBSti5ZoMrmI7RTPRORKoQ-1; Thu, 21 May 2020 16:09:51 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B2D671800D42; Thu, 21 May 2020 20:09:45 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 18C6456330; Thu, 21 May 2020 20:09:45 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 1256118095FF; Thu, 21 May 2020 20:09:42 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 04LK9d9P028375 for ; Thu, 21 May 2020 16:09:39 -0400 Received: by smtp.corp.redhat.com (Postfix) id ED93B56324; Thu, 21 May 2020 20:09:39 +0000 (UTC) Received: from himantopus.redhat.com (ovpn-112-181.phx2.redhat.com [10.3.112.181]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BED6156330 for ; Thu, 21 May 2020 20:09:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590091793; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=rL8oNXEa4c57bLrbpJlMrhQKcJHeBXUrznT1oeOeU9k=; b=hd28eC0WT6tisaA/eYayRNS1wjr5Vb1M1iHgImtxtEAv9QHKstM1z88BVtdvzFGpX03JbO JEJGvleCaRCWcfmo/lB9G+IaZbmKGQ7n0JxdxpNAdlHSbLz0YT7b8LsFfAwUFwnX08kAvn kjycZt5pDe9rz7S/dp3K6TJjR4sZdH0= X-MC-Unique: NBSti5ZoMrmI7RTPRORKoQ-1 From: Jonathon Jongsma To: libvir-list@redhat.com Subject: [libvirt PATCH 2/2] docs: Document full node device xml in formatnode.html.in Date: Thu, 21 May 2020 15:09:35 -0500 Message-Id: <20200521200935.19237-3-jjongsma@redhat.com> In-Reply-To: <20200521200935.19237-1-jjongsma@redhat.com> References: <20200521200935.19237-1-jjongsma@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" 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 Reviewed-by: Erik Skultety --- docs/drvnodedev.html.in | 127 ++++------------------------------------ docs/formatnode.html.in | 70 +++++++++++++++++++++- 2 files changed, 81 insertions(+), 116 deletions(-) diff --git a/docs/drvnodedev.html.in b/docs/drvnodedev.html.in index 71a8a57b0c..90af2ea4ff 100644 --- a/docs/drvnodedev.html.in +++ b/docs/drvnodedev.html.in @@ -28,60 +28,12 @@

=20

- The generic format of a host device XML can be seen below. - To identify a device both within the host and the device tree hierar= chy, - 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.

-
-
name
-
- The device's name will be generated by libvirt using the subsyst= em, - like pci and the device's sysfs basename. -
-
path
-
- Fully qualified sysfs path to the device. -
-
parent
-
- This element identifies the parent node in the device hierarchy.= The - value of the element will correspond with the device parent's - name element or computer if the device= does - not have any parent. -
-
driver
-
- This elements reports the driver in use for this device. The pre= sence - of this element in the output XML depends on whether the underly= ing - device manager (most likely udev) exposes information about the - driver. -
-
capability
-
- Describes the device in terms of feature support. The element ha= s one - mandatory attribute type the value of which determi= nes - the type of the device. Currently recognized values for the attr= ibute - 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. -
-
-

Basic structure of a node device

 <device>
@@ -191,45 +143,13 @@
       A PCI device capable of creating mediated devices will include a nes=
ted
       capability mdev_types which enumerates all supported md=
ev
       types on the physical device, along with the type attributes availab=
le
-      through sysfs:
+      through sysfs. A detailed description of the XML format for the mdev
+      capability can be found here.
     

- -
-
type
-
- This element 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 id which h= olds - an official vendor-supplied identifier for the type. - Since 3.4.0 -
- -
name
-
- The name element holds a vendor-supplied code name for - the given mediated device type. This is an optional element. - Since 3.4.0 -
- -
deviceAPI
-
- The value of this element describes how an instance of the given t= ype - will be presented to the guest by the VFIO framework. - Since 3.4.0 -
- -
availableInstances
-
- This element reports the current state of resource allocation. In = other - words, how many instances of the given type can still be successfu= lly - created on the physical device. - Since 3.4.0 -
-
-

- For a more info about mediated devices, refer to the - paragraph below. + The following example shows how we might represent an Nvidia GPU dev= ice + that supports mediated devices. See below for more + information about mediated devices.

=20
@@ -262,32 +182,11 @@
       as multiple separate PCIe devices on the host's PCI bus, mediated de=
vices
       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.
     

=20 -

- The following sub-elements and attributes are exposed within the - capability element: -

- -
-
type
-
- This element 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 id which h= olds - an official vendor-supplied identifier for the type. - Since 3.4.0 -
- -
iommuGroup
-
- This element supports a single attribute number which= holds - the IOMMU group number the mediated device belongs to. - Since 3.4.0 -
-
-

Example of a mediated device

 <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".
       
+
path
+
+ Fully qualified sysfs path to the device. +
parent
-
If this element is present, it names the parent device (that - is, a controller to which this node belongs). +
+ This element identifies the parent node in the device hierarchy. T= he + value of the element will correspond with the device parent's + name element or computer if the device d= oes + not have any parent. +
+
driver
+
+ This elements reports the driver in use for this device. The prese= nce + of this element in the output XML depends on whether the underlying + device manager (most likely udev) exposes information about the + driver.
devnode
This node appears for each associated /dev @@ -138,8 +152,40 @@ means such device cannot be used for PCI passthrough. Since 1.3.3
+
mdev_types
+
+ This device is capable of creating mediated devices, a= nd + the capability will contain a list of type + 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 ident= ifier + for the type. It supports the following sub-elements: +
+
name
+
+ The name element holds a vendor-sup= plied + code name for the given mediated device type. Th= is is + an optional element. +
+
deviceAPI
+
+ The value of this element describes how an instanc= e of + the given type will be presented to the guest by t= he + VFIO framework. +
+
availableInstances
+
+ 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. +
+
+
+
numa
This optional element contains information on the PCI devi= ce @@ -329,6 +375,26 @@ render.
+
mdev
+
Describes a mediated device. Since + 3.4.0 Sub-elements include: +
+
type
+
+ 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 + id which holds an official vendor-supplied + identifier for the type. +
+
iommuGroup
+
+ This element supports a single attribute number + which holds the IOMMU group number the mediated device bel= ongs + to. +
+
+
ccw
Describes a Command Channel Word (CCW) device commonly found= on the S390 architecture. Sub-elements include: --=20 2.21.3