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

[Tian, Kevin]

> From: Alex Williamson [mailto:address@hidden
> Sent: Wednesday, February 03, 2016 1:11 AM
> 
> On Tue, 2016-02-02 at 00:31 -0800, Neo Jia wrote:
> > On Tue, Feb 02, 2016 at 08:18:44AM +0000, Tian, Kevin wrote:
> > > > From: Neo Jia [mailto:address@hidden
> > > > Sent: Tuesday, February 02, 2016 4:13 PM
> > > >
> > > > On Tue, Feb 02, 2016 at 09:00:43AM +0100, Gerd Hoffmann wrote:
> > > > >   Hi,
> > > > >
> > > > > > And for UUID, I remember Alex had a concern on using it in kernel.
> > > > > > Honestly speaking I don't have a good idea here. In Xen side there 
> > > > > > is a VM ID
> > > > > > which can be easily used as the index. But for KVM, what would be 
> > > > > > the best
> > > > > > identifier to associate with a VM?
> > > > >
> > > > > The vgpu code doesn't need to associate the vgpu device with a vm in 
> > > > > the
> > > > > first place.  You get all guest address space information from qemu, 
> > > > > via
> > > > > vfio iommu interface.
> > > > >
> > > > > When qemu does't use kvm (tcg mode), things should still work fine.
> > > > > Using vfio-based vgpu devices with non-qemu apps (some kind of test
> > > > > suite for example) should work fine too.
> > > >
> > > > Hi Gerd and Kevin,
> > > >
> > > > I thought Alex had agreed with the UUID as long as it is not tied with 
> > > > VM,
> > > > probably it is just his comment gets lost in our previous long email 
> > > > thread.
> > > >
> > >
> > > I think the point is... what is the value to introduce a UUID here? If
> > > what Gerd describes is enough, we can simply invent a vgpu ID which
> > > is returned at vgpu_create, and then used as the index for other
> > > interfaces.
> > >
> >
> > Hi Kevin,
> >
> > It can just be a plain UUID, and the meaning of the UUID is up to upper 
> > layer SW, for
> > example with libvirt, you can create a new "vgpu group" object representing 
> > a
> > list of vgpu device. so the UUID will be the input on vgpu_create instead of
> > return value.
> 
> Jumping in at th end, but yes, this was my thinking.  A UUID is a
> perfectly fine name for a vgpu, but it should be user policy whether
> than UUID matches a VM definition or is simply an arbitrary grouping of
> vgpus.
> 

well I'm still trying to understand the necessity here. Is there any requirement
that vgpu driver needs to use UUID itself? If not, we can still invent any
simple format in vgpu driver itself, as Gerd mentioned, w/o dependency
on an user input. Then libvirt can maintain UUID->vgpu ID internally.

Actually I have a long puzzle in this area. Definitely libvirt will use UUID to
mark a VM. And obviously UUID is not recorded within KVM. Then how does
libvirt talk to KVM based on UUID? It could be a good reference to this design.

Thanks
Kevin