> From: Neo Jia > Sent: Wednesday, February 17, 2016 3:26 PM > > > > > > Qemu doesn't need to know the relation between virtual/physical devices at > > all. It's just a path regardless of how vgpu name is created (either with your > > UUID proposal or my descriptive string proposal) > > No, with path like above, QEMU needs to know the virtual device is created from > that physical device 0000:00:02.0 right? (you have mentioned this yourself > actually below.) If QEMU doesn't want to know that, then he will transfer the I didn't say anything that Qemu needs to know it. I said "I can immediately know ..." which means a human being. :-) Qemu only needs a path to open. [...] > > > > > This is a typical way how device nodes are created within sysfs, e.g. on my > > platform: > > > > $ ls /sys/class/drm/ > > card0/ card0-DP-2/ card0-HDMI-A-2/ controlD64/ > > card0-DP-1/ card0-HDMI-A-1/ card0-VGA-1/ version > > > > $ ls /sys/bus/pci/devices/ > > 0000:00:00.0 0000:00:14.0 0000:00:1a.0 0000:00:1c.1 0000:00:1f.2 > > 0000:00:02.0 0000:00:16.0 0000:00:1b.0 0000:00:1d.0 0000:00:1f.3 > > 0000:00:03.0 0000:00:19.0 0000:00:1c.0 0000:00:1f.0 0000:02:00.0 > > > > We'd better keep such style when creating vgpu nodes in sysfs. UUID is > > at most anther info suffixed to the default string (or in another file), if > > necessary. > > It doesn't apply here, your above example are all physical devices. > > The reason I want to have UUID is it to match the instance of problem domain > here - VM. It doesn't matter whether it's physical or virtual. Sysfs includes many nodes not physically existing. The point that I don't understand, is why you insist the only way to associate vgpu to a VM is by encoding UUID in vgpu name. libvirt maintains many attributes (including other virtual devices) for a given VM, in its internal database. It's not a problem to reverse find a VM according to a general vgpu name. [...] > > > > I'm fine to have another node to provide more vendor specific information. But > > I don't want to make UUID mandatory when creating a vGPU instance, as > > explained above. Today we can create VMs in KVM w/o using libvirt, and w/o > > the need of allocating any UUID. Same thing should be supported for vgpu > > feature too. > > So, I really don't see any drawback of using UUID as part of the virtual device > directory, it is easy, simple and organically reflecting the relation between > virtual device and the owner. "organically reflecting" only when other database is included (as libvirt is involved), while losing the merit which a descriptive name can bring. > > Each QEMU process is representing a VM, and a UUID is associated with it. The > virtual gpu device is just a virtual device of this owner, so the path is: > > -device vfio-pci,sysfsdev=/sys/devices/virtual/vgpu/$UUID-$vgpu_idx/ > > You can have multiple virtual device per VM and QEMU doesn't need to know which > physical device it comes from, especially it will automatically know which > virtual device it owns, so the -device vfio-pci path will be setup for free. As I commented earlier, Qemu never needs to know that information regardless of how the vgpu is named. > > If your most concern is having this kind of path doesn't provide enough > information of the virtual device, we can add more sysfs attributes within the > directory of /sys/devices/virtual/vgpu/$UUID-$vgpu_idx/ to reflect the > information you want. Like Gerd said, you can have something like this: -device vfio-pci,sysfsdev=/sys/devices/virtual/vgpu/vgpu_idx/UUID > > Even with UUID, you don't need libvirt at all. you can get uuid by running > uuidgen command, I don't need libvirt to code up and test the RFC that I have > sent out early. :-) although simple, it still creates unnecessary user space dependency for kernel resource management... Thanks Kevin -- 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
