From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQeUA-0007NV-Ca for qemu-devel@nongnu.org; Tue, 02 Feb 2016 12:11:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQeU5-0002WR-Dd for qemu-devel@nongnu.org; Tue, 02 Feb 2016 12:11:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQeU5-0002WN-5e for qemu-devel@nongnu.org; Tue, 02 Feb 2016 12:11:21 -0500 Message-ID: <1454433079.30910.3.camel@redhat.com> From: Alex Williamson Date: Tue, 02 Feb 2016 10:11:19 -0700 In-Reply-To: <20160202083114.GB9895@nvidia.com> References: <56AFD231.3010404@nvidia.com> <56B00AD7.6070103@nvidia.com> <1454400043.9300.31.camel@redhat.com> <20160202081312.GA9895@nvidia.com> <20160202083114.GB9895@nvidia.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Neo Jia , "Tian, Kevin" Cc: "Ruan, Shuai" , "Song, Jike" , "kvm@vger.kernel.org" , qemu-devel , Kirti Wankhede , Gerd Hoffmann , Paolo Bonzini , "Lv, Zhiyuan" 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:cjia@nvidia.com] > > > Sent: Tuesday, February 02, 2016 4:13 PM > > >=C2=A0 > > > On Tue, Feb 02, 2016 at 09:00:43AM +0100, Gerd Hoffmann wrote: > > > > =C2=A0 Hi, > > > >=C2=A0 > > > > > And for UUID, I remember Alex had a concern on using it in kern= el. > > > > > Honestly speaking I don't have a good idea here. In Xen side th= ere 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? > > > >=C2=A0 > > > > The vgpu code doesn't need to associate the vgpu device with a vm= in the > > > > first place.=C2=A0=C2=A0You get all guest address space informati= on from qemu, via > > > > vfio iommu interface. > > > >=C2=A0 > > > > When qemu does't use kvm (tcg mode), things should still work fin= e. > > > > Using vfio-based vgpu devices with non-qemu apps (some kind of te= st > > > > suite for example) should work fine too. > > >=C2=A0 > > > Hi Gerd and Kevin, > > >=C2=A0 > > > I thought Alex had agreed with the UUID as long as it is not tied w= ith VM, > > > probably it is just his comment gets lost in our previous long emai= l thread. > > >=C2=A0 > >=C2=A0 > > I think the point is... what is the value to introduce a UUID here? I= f > > 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. > >=C2=A0 >=C2=A0 > Hi Kevin, >=C2=A0 > 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 represen= ting a > list of vgpu device. so the UUID will be the input on vgpu_create inste= ad of > return value. Jumping in at th end, but yes, this was my thinking.=C2=A0=C2=A0A UUID is= a=C2=A0 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. > For the TCG mode, this should just work as long as libvirt can create t= he proper > internal objects there plus other vfio iommu interface Gerd has called = out, > although the vector->kvm_interrupt part might need some tweaks. Interrupts should be eventfds and whether the eventfd triggers into userspace or into an irqfd in KVM should be completely transparent to the vgpu code, just as is done with vfio today.=C2=A0=C2=A0Thanks, Alex