From: Paolo Bonzini <pbonzini@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>,
Michal Privoznik <mprivozn@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>
Cc: "Song, Jike" <jike.song@intel.com>,
"cjia@nvidia.com" <cjia@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"libvir-list@redhat.com" <libvir-list@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kraxel@redhat.com" <kraxel@redhat.com>,
Laine Stump <laine@redhat.com>,
"bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support
Date: Fri, 2 Sep 2016 12:05:01 +0200 [thread overview]
Message-ID: <8682faeb-0331-f014-c13e-03c20f3f2bdf@redhat.com> (raw)
In-Reply-To: <98bbdbbf-c388-9120-3306-64f0cfb820a7@nvidia.com>
On 02/09/2016 07:21, Kirti Wankhede wrote:
> On 9/2/2016 10:18 AM, Michal Privoznik wrote:
> > Okay, maybe I'm misunderstanding something. I just thought that users
> > will consult libvirt's nodedev driver (e.g. virsh nodedev-list && virsh
> > nodedev-dumpxml $id) to fetch vGPU capabilities and then use that info
> > to construct domain XML.
>
> I'm not familiar with libvirt code, curious how libvirt's nodedev driver
> enumerates devices in the system?
It looks at sysfs and/or the udev database and transforms what it finds
there to XML.
I think people would consult the nodedev driver to fetch vGPU
capabilities, use "virsh nodedev-create" to create the vGPU device on
the host, and then somehow refer to the nodedev in the domain XML.
There isn't very much documentation on nodedev-create, but it's used
mostly for NPIV (virtual fibre channel adapter) and the XML looks like this:
<device>
<name>scsi_host6</name>
<parent>scsi_host5</parent>
<capability type='scsi_host'>
<capability type='fc_host'>
<wwnn>2001001b32a9da5e</wwnn>
<wwpn>2101001b32a9da5e</wwpn>
</capability>
</capability>
</device>
so I suppose for vGPU it would look like this:
<device>
<name>my-vgpu</name>
<parent>pci_0000_86_00_0</parent>
<capability type='mdev'>
<type id='11'/>
<uuid>0695d332-7831-493f-9e71-1c85c8911a08</uuid>
</capability>
</device>
while the parent would have:
<device>
<name>pci_0000_86_00_0</name>
<capability type='pci'>
<domain>0</domain>
<bus>134</bus>
<slot>0</slot>
<function>0</function>
<capability type='mdev'>
<!-- one type element per sysfs directory -->
<type id='11'>
<!-- one element per sysfs file roughly -->
<name>GRID M60-0B</name>
<attribute name='num_heads'>2</attribute>
<attribute name='frl_config'>45</attribute>
<attribute name='framebuffer'>524288</attribute>
<attribute name='hres'>2560</attribute>
<attribute name='vres'>1600</attribute>
</type>
</capability>
<product id='...'>GRID M60</product>
<vendor id='0x10de'>NVIDIA</vendor>
</capability>
</device>
After creating the vGPU, if required by the host driver, all the other
type ids would disappear from "virsh nodedev-dumpxml pci_0000_86_00_0" too.
When dumping the mdev with nodedev-dumpxml, it could show more complete
info, again taken from sysfs:
<device>
<name>my-vgpu</name>
<parent>pci_0000_86_00_0</parent>
<capability type='mdev'>
<uuid>0695d332-7831-493f-9e71-1c85c8911a08</uuid>
<!-- only the chosen type -->
<type id='11'>
<name>GRID M60-0B</name>
<attribute name='num_heads'>2</attribute>
<attribute name='frl_config'>45</attribute>
<attribute name='framebuffer'>524288</attribute>
<attribute name='hres'>2560</attribute>
<attribute name='vres'>1600</attribute>
</type>
<capability type='pci'>
<!-- no domain/bus/slot/function of course -->
<!-- could show whatever PCI IDs are seen by the guest: -->
<product id='...'>...</product>
<vendor id='0x10de'>NVIDIA</vendor>
</capability>
</capability>
</device>
Notice how the parent has mdev inside pci; the vGPU, if it has to have
pci at all, would have it inside mdev. This represents the difference
between the mdev provider and the mdev device.
Random proposal for the domain XML too:
<hostdev mode='subsystem' type='pci'>
<source type='mdev'>
<!-- possible alternative to uuid: <name>my-vgpu</name> ?!? -->
<uuid>0695d332-7831-493f-9e71-1c85c8911a08</uuid>
</source>
<address type='pci' bus='0' slot='2' function='0'/>
</hostdev>
Paolo
next prev parent reply other threads:[~2016-09-02 10:05 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-25 3:53 [PATCH v7 0/4] Add Mediated device support Kirti Wankhede
2016-08-25 3:53 ` [PATCH v7 1/4] vfio: Mediated device Core driver Kirti Wankhede
2016-09-08 8:09 ` Jike Song
2016-09-08 9:38 ` Neo Jia
2016-09-09 6:26 ` Jike Song
2016-09-09 17:48 ` Kirti Wankhede
2016-09-09 18:42 ` Alex Williamson
2016-09-09 19:55 ` Kirti Wankhede
2016-09-12 5:10 ` Jike Song
2016-09-12 7:49 ` Kirti Wankhede
2016-09-12 15:53 ` Alex Williamson
2016-09-19 7:08 ` Jike Song
2016-09-19 17:29 ` Kirti Wankhede
2016-09-19 18:11 ` Alex Williamson
2016-09-19 20:09 ` Kirti Wankhede
2016-09-19 20:59 ` [Qemu-devel] " Alex Williamson
2016-09-20 12:48 ` Jike Song
2016-08-25 3:53 ` [PATCH v7 2/4] vfio: VFIO driver for mediated devices Kirti Wankhede
2016-08-25 9:22 ` Dong Jia
2016-08-26 14:13 ` Kirti Wankhede
2016-09-08 2:38 ` Jike Song
2016-09-19 18:22 ` [Qemu-devel] " Kirti Wankhede
2016-09-19 18:36 ` Alex Williamson
2016-09-19 19:13 ` Kirti Wankhede
2016-09-19 20:03 ` Alex Williamson
2016-09-20 2:50 ` Jike Song
2016-09-20 16:24 ` Alex Williamson
2016-09-21 3:19 ` Jike Song
2016-09-21 4:51 ` Alex Williamson
2016-09-21 5:02 ` Jike Song
2016-09-08 2:45 ` Jike Song
2016-09-13 2:35 ` Jike Song
2016-09-20 5:48 ` Dong Jia Shi
[not found] ` <20160920054851.GA2186@bjsdjshi@linux.vnet.ibm.com>
2016-09-20 6:37 ` Jike Song
2016-09-20 12:53 ` Jike Song
2016-08-25 3:53 ` [PATCH v7 3/4] vfio iommu: Add support " Kirti Wankhede
2016-08-25 7:29 ` Dong Jia
2016-08-26 13:50 ` Kirti Wankhede
2016-09-29 2:17 ` Jike Song
2016-09-29 15:06 ` Kirti Wankhede
2016-09-30 2:58 ` Jike Song
2016-09-30 3:10 ` Jike Song
2016-09-30 11:44 ` Kirti Wankhede
2016-10-08 7:09 ` Jike Song
2016-08-25 3:53 ` [PATCH v7 4/4] docs: Add Documentation for Mediated devices Kirti Wankhede
2016-09-03 16:40 ` Kirti Wankhede
2016-08-30 16:16 ` [PATCH v7 0/4] Add Mediated device support Alex Williamson
2016-08-31 6:12 ` Tian, Kevin
2016-08-31 7:04 ` Jike Song
2016-08-31 15:48 ` Alex Williamson
2016-09-01 4:09 ` Tian, Kevin
2016-09-01 4:10 ` Tian, Kevin
2016-09-01 18:22 ` Kirti Wankhede
2016-09-01 20:01 ` Alex Williamson
2016-09-02 6:17 ` Kirti Wankhede
2016-09-01 16:47 ` [Qemu-devel] " Michal Privoznik
2016-09-01 16:59 ` Alex Williamson
2016-09-02 4:48 ` [Qemu-devel] " Michal Privoznik
2016-09-02 5:21 ` Kirti Wankhede
2016-09-02 10:05 ` Paolo Bonzini [this message]
2016-09-02 17:15 ` Kirti Wankhede
2016-09-02 17:25 ` Paolo Bonzini
2016-09-02 18:33 ` Kirti Wankhede
2016-09-02 20:29 ` [libvirt] " John Ferlan
2016-09-03 16:31 ` [libvirt] " Kirti Wankhede
2016-09-06 17:54 ` [libvirt] [Qemu-devel] " Alex Williamson
2016-09-02 21:48 ` Paolo Bonzini
2016-09-03 11:56 ` [libvirt] " John Ferlan
2016-09-03 13:07 ` Paolo Bonzini
2016-09-03 17:47 ` [libvirt] " Kirti Wankhede
2016-09-03 16:34 ` [Qemu-devel] " Kirti Wankhede
2016-09-06 17:40 ` Alex Williamson
2016-09-06 19:35 ` Kirti Wankhede
2016-09-06 21:28 ` Alex Williamson
2016-09-07 8:22 ` Tian, Kevin
2016-09-07 16:00 ` Alex Williamson
2016-09-07 16:15 ` Kirti Wankhede
2016-09-07 16:44 ` Alex Williamson
2016-09-07 18:06 ` Kirti Wankhede
2016-09-07 22:13 ` Alex Williamson
2016-09-08 18:48 ` Kirti Wankhede
2016-09-08 20:51 ` Alex Williamson
2016-09-07 18:17 ` Neo Jia
2016-09-07 18:27 ` Daniel P. Berrange
2016-09-07 18:32 ` Neo Jia
2016-09-07 6:48 ` Tian, Kevin
2016-09-02 20:19 ` [libvirt] " John Ferlan
2016-09-02 21:44 ` Paolo Bonzini
2016-09-02 23:57 ` Laine Stump
2016-09-03 16:49 ` Kirti Wankhede
2016-09-05 7:52 ` Paolo Bonzini
2016-09-03 11:57 ` John Ferlan
2016-09-05 7:54 ` Paolo Bonzini
2016-09-02 17:55 ` Laine Stump
2016-09-02 19:15 ` [libvirt] " Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8682faeb-0331-f014-c13e-03c20f3f2bdf@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=cjia@nvidia.com \
--cc=jike.song@intel.com \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=laine@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mprivozn@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).