qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tian, Kevin
Subject: Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.
Date: Tue, 2 Feb 2016 08:18:44 +0000

> 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.

But I still need to think about whether there's value to have a VM
identifier within vgpu core driver, especially regarding to how this
vgpu core driver connects to KVM hypervisor or other hypervisor.
I saw another long thread about that part. Jike has started his 
vacation now. I'll follow up with it tomorrow.

Thanks
Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]