From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgAfN-0001PY-2e for qemu-devel@nongnu.org; Sat, 03 Sep 2016 09:07:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgAfI-00052a-2F for qemu-devel@nongnu.org; Sat, 03 Sep 2016 09:07:24 -0400 Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:33649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgAfH-00052U-Ok for qemu-devel@nongnu.org; Sat, 03 Sep 2016 09:07:20 -0400 Received: by mail-wm0-x242.google.com with SMTP id w207so6427584wmw.0 for ; Sat, 03 Sep 2016 06:07:19 -0700 (PDT) Sender: Paolo Bonzini References: <1472097235-6332-1-git-send-email-kwankhede@nvidia.com> <20160830101638.49df467d@t450s.home> <78fedd65-6d62-e849-ff3b-d5105b2da816@redhat.com> <20160901105948.62f750aa@t450s.home> <98bbdbbf-c388-9120-3306-64f0cfb820a7@nvidia.com> <8682faeb-0331-f014-c13e-03c20f3f2bdf@redhat.com> <2a195ed1-f6aa-ffab-3f5c-4121de264d05@redhat.com> From: Paolo Bonzini Message-ID: <3169fcf3-1c1f-38cc-eb6d-3e8b4b8b1dd9@redhat.com> Date: Sat, 3 Sep 2016 15:07:14 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [libvirt] [PATCH v7 0/4] Add Mediated device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Ferlan , Kirti Wankhede , Michal Privoznik , Alex Williamson Cc: "Song, Jike" , "cjia@nvidia.com" , "kvm@vger.kernel.org" , "libvir-list@redhat.com" , "Tian, Kevin" , "qemu-devel@nongnu.org" , "kraxel@redhat.com" , Laine Stump , "bjsdjshi@linux.vnet.ibm.com" On 03/09/2016 13:56, John Ferlan wrote: > On 09/02/2016 05:48 PM, Paolo Bonzini wrote: >> On 02/09/2016 20:33, Kirti Wankhede wrote: >>> We could even do: >>>>> >>>>> echo $UUID1:$GROUPA > create >>>>> >>>>> where $GROUPA is the group ID of a previously created mdev device into >>>>> which $UUID1 is to be created and added to the same group. >>> >> >> >From the point of view of libvirt, I think I prefer Alex's idea. >> could be an additional element in the nodedev-create XML: >> >> >> my-vgpu >> pci_0000_86_00_0 >> >> >> 0695d332-7831-493f-9e71-1c85c8911a08 >> group1 >> >> >> >> (should group also be a UUID?) > > As long as create_group handles all the work and all libvirt does is > call it, get the return status/error, and handle deleting the vGPU on > error, then I guess it's doable. > > Alternatively having multiple in the XML and performing a > single *mdev/create_group is an option. I don't really like the idea of a single nodedev-create creating multiple devices, but that would work too. > That is, what is the "output" from create_group that gets added to the > domain XML? How is that found? A new sysfs path is created, whose name depends on the UUID. The UUID is used in a element in the domain XML and the sysfs path appears in the QEMU command line. Kirti and Neo had examples in their presentation at KVM Forum. If you create multiple devices in the same group, they are added to the same IOMMU group so they must be used by the same VM. However they don't have to be available from the beginning; they could be hotplugged/hot-unplugged later, since from the point of view of the VM those are just another PCI device. > Also, once the domain is running can a > vGPU be added to the group? Removed? What allows/prevents? Kirti?... :) In principle I don't think anything should block vGPUs from different groups being added to the same VM, but I have to defer to Alex and Kirti again on this. >> Since John brought up the topic of minimal XML, in this case it will be >> like this: >> >> >> my-vgpu >> pci_0000_86_00_0 >> >> >> >> >> >> The uuid will be autogenerated by libvirt and if there's no (as >> is common for VMs with only 1 vGPU) it will be a single-device group. > > The could be ignored as it seems existing libvirt code wants to > generate a name via udevGenerateDeviceName for other devices. I haven't > studied it long enough, but I believe that's how those pci_####* names > created. Yeah that makes sense. So we get down to a minimal XML that has just parent, and capability with type in it; additional elements could be name (ignored anyway), and within capability uuid and group. Thanks, Paolo