From eskultet at redhat.com Wed Nov 11 04:35:00 2020 Content-Type: multipart/mixed; boundary="===============7425452514121282204==" MIME-Version: 1.0 From: Erik Skultety To: devel at lists.libvirt.org Subject: Re: [PATCH v2 1/2] docs: refactor mdev_types into new paragraph Date: Wed, 11 Nov 2020 10:34:51 +0100 Message-ID: <20201111093451.GA857537@nautilus> In-Reply-To: 20201110180906.38759-2-fiuczy@linux.ibm.com --===============7425452514121282204== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Nov 10, 2020 at 07:09:05PM +0100, Boris Fiuczynski wrote: > To prevent copying the mdev_types description multiple times > it is refactored into a new paragraph for easy reuse. > = > Signed-off-by: Boris Fiuczynski > --- > docs/formatnode.html.in | 70 ++++++++++++++++++++++++----------------- > 1 file changed, 41 insertions(+), 29 deletions(-) > = > diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in > index 6928bdd69c..bd3112c5a8 100644 > --- a/docs/formatnode.html.in > +++ b/docs/formatnode.html.in > @@ -159,35 +159,10 @@ > >
mdev_types
>
> - This device is capable of creating mediated devices,= and > - 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 ide= ntifier > - for the type. It supports the following sub-elements: > -
> -
name
> -
> - The name element holds a vendor-s= upplied > - code name for the given mediated device type. = This is > - an optional element. > -
> -
deviceAPI
> -
> - The value of this element describes how an insta= nce of > - the given type will be presented to the guest by= the > - VFIO framework. > -
> -
availableInstances
> -
> - This element reports the current state of resour= ce > - allocation. In other words, how many instances o= f the > - given type can still be successfully created on = the > - physical device. > -
> -
> -
> + This device is capable of creating mediated devices. > + The sub-elements are summarized in > + mdev_types capability. > + > > > = > @@ -445,6 +420,43 @@ > > > = > +

mdev_types capability

> + > +

> + PCI devices can be capable of > + creating mediated devices. > + If they are capable the attribute type of the > + element capability is mdev_types. I'd slightly adjust the wording because the first I read it I got confused, not just the rewrite, also by the original (probably mine) text. How about: "If the indeed are capable, then the parent capability element for mdev_types type will contain a list of ...." Reviewed-by: Erik Skultety > + This 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 identifier > + for the type. It supports the following sub-elements: > +

> +
name
> +
> + The name element holds a vendor-supplied > + code name for the given mediated device type. This is > + an optional element. > +
> +
deviceAPI
> +
> + The value of this element describes how an instance of > + the given type will be presented to the guest by the > + 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. > +
> +
> +

> + > + >

Examples

> = >

The following are some example node device XML outputs:

> -- = > 2.26.2 > = --===============7425452514121282204==--