On 09/02/2016 05:48 PM, Paolo Bonzini wrote: > > > On 02/09/2016 20:33, Kirti Wankhede wrote: >> <Alex> 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. >> </Alex> > >>From the point of view of libvirt, I think I prefer Alex's idea. > <group> could be an additional element in the nodedev-create XML: > > <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> > <group>group1</group> > </capability> > </device> > > (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 <type id='#'> in the XML and performing a single *mdev/create_group is an option. I suppose it all depends on the arguments to create_group and the expected output and how that's expected to be used. That is, what is the "output" from create_group that gets added to the domain XML? How is that found? Also, once the domain is running can a vGPU be added to the group? Removed? What allows/prevents? > > Since John brought up the topic of minimal XML, in this case it will be > like this: > > <device> > <name>my-vgpu</name> > <parent>pci_0000_86_00_0</parent> > <capability type='mdev'> > <type id='11'/> > </capability> > </device> > > The uuid will be autogenerated by libvirt and if there's no <group> (as > is common for VMs with only 1 vGPU) it will be a single-device group. > The <name> 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. John -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
