On Tue, Nov 19, 2019 at 05:38:54PM +0100, Milan Zamazal wrote:
Hi, when retrieving an mdev device info using `virsh
nodedev-dumpxml' or
the libvirt API, something like the following is returned:
<capability type='mdev_types'>
<type id='nvidia-210'>
<name>GRID M60-2B4</name>
<deviceAPI>vfio-pci</deviceAPI>
<availableInstances>4</availableInstances>
</type>
...
</capability>
Besides device_api, available_instances and (optional) `name',
`description' of the given mdev type may be optionally provided in
/sys/.../mdev_supported_types/... for each of the available mdev types.
I can see in the sources that libvirt doesn't try to retrieve it -- is
it intentionally or is it just an omission? If the latter, could it be
added, please? It looks like a useful piece of information for the user
to get an idea what the given mdev type means.
The reasoning we had about not including the "description" attribute when we
introduced mdevs to libvirt's nodedev driver was that there was no way for
NVIDIA and Intel to agree on the values to be exposed by the attribute -
especially the data NVIDIA puts in there (like you already said) is useful, but
there was also no agreement on extracting the data into a different attribute
(a set of attributes) and make them structured within the XML.
Which brings me to the actual content of the "description" attribute, it
contains unstructured free-form text and we didn't want to expose that kind of
thing in the XML even though it just so happens that NVIDIA put some
interesting data in it - since the attribute is optional and free-form, one
day, you find the useful data you're interested in now, but tomorrow that may
not be the case anymore and can easily change. I've got no problem with the
idea of exposing some kind of description as part of the XML per se, the
problem I see is that someone will try and start parsing the description field
because of the potentially useful data and if it changes and I'm afraid
complaints will head our way even though we cannot guarantee anything wrt to
that specific field (I'm still open to a discussion though).
Regards,
Erik