From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Date: Mon, 25 Jan 2016 14:30:26 -0700 Message-ID: <1453757426.32741.614.camel@redhat.com> References: <569C5071.6080004@intel.com> <1453092476.32741.67.camel@redhat.com> <569CA8AD.6070200@intel.com> <1453143919.32741.169.camel@redhat.com> <569F4C86.2070501@intel.com> <56A6083E.10703@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: "Ruan, Shuai" , "Tian, Kevin" , Neo Jia , "kvm@vger.kernel.org" , "igvt-g@lists.01.org" , qemu-devel , Gerd Hoffmann , Paolo Bonzini , "Lv, Zhiyuan" To: Jike Song Return-path: In-Reply-To: <56A6083E.10703@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org [cc +Neo @Nvidia] Hi Jike, On Mon, 2016-01-25 at 19:34 +0800, Jike Song wrote: > On 01/20/2016 05:05 PM, Tian, Kevin wrote: > > I would expect we can spell out next level tasks toward above > > direction, upon which Alex can easily judge whether there are > > some common VFIO framework changes that he can help :-) >=20 > Hi Alex, >=20 > Here is a draft task list after a short discussion w/ Kevin, > would you please have a look? >=20 > Bus Driver >=20 > { in i915/vgt/xxx.c } >=20 > - define a subset of vfio_pci interfaces > - selective pass-through (say aperture) > - trap MMIO: interface w/ QEMU What's included in the subset? =C2=A0Certainly the bus reset ioctls reall= y don't apply, but you'll need to support the full device interface, right? =C2=A0That includes the region info ioctl and access through the v= fio device file descriptor as well as the interrupt info and setup ioctls. > IOMMU >=20 > { in a new vfio_xxx.c } >=20 > - allocate: struct device & IOMMU group It seems like the vgpu instance management would do this. > - map/unmap functions for vgpu > - rb-tree to maintain iova/hpa mappings Yep, pretty much what type1 does now, but without mapping through the IOMMU API. =C2=A0Essentially just a database of the current userspace mappings that can be accessed for page pinning and IOVA->HPA translation. > - interacts with kvmgt.c >=20 >=20 > vgpu instance management >=20 > { in i915 } >=20 > - path, create/destroy >=20 Yes, and since you're creating and destroying the vgpu here, this is where I'd expect a struct device to be created and added to an IOMMU group. =C2=A0The lifecycle management should really include links between the vGPU and physical GPU, which would be much, much easier to do with struct devices create here rather than at the point where we start doing vfio "stuff". Nvidia has also been looking at this and has some ideas how we might standardize on some of the interfaces and create a vgpu framework to help share code between vendors and hopefully make a more consistent userspace interface for libvirt as well. =C2=A0I'll let Neo provide some details. =C2=A0Thanks, Alex