Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Tian, Kevin]

> 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