From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO6EW-0000dQ-Jb for qemu-devel@nongnu.org; Tue, 26 Jan 2016 11:12:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aO6ES-0005kj-E1 for qemu-devel@nongnu.org; Tue, 26 Jan 2016 11:12:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO6ES-0005kf-6P for qemu-devel@nongnu.org; Tue, 26 Jan 2016 11:12:40 -0500 Message-ID: <1453824758.26652.41.camel@redhat.com> From: Alex Williamson Date: Tue, 26 Jan 2016 09:12:38 -0700 In-Reply-To: <56A72313.9030009@intel.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> <1453757426.32741.614.camel@redhat.com> <56A72313.9030009@intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jike Song Cc: "Ruan, Shuai" , "Tian, Kevin" , Neo Jia , "kvm@vger.kernel.org" , "igvt-g@lists.01.org" , qemu-devel , Gerd Hoffmann , Paolo Bonzini , "Lv, Zhiyuan" On Tue, 2016-01-26 at 15:41 +0800, Jike Song wrote: > On 01/26/2016 05:30 AM, Alex Williamson wrote: > > [cc +Neo @Nvidia] > >=20 > > Hi Jike, > >=20 > > 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 > >=20 > > What's included in the subset?=C2=A0=C2=A0Certainly the bus reset ioc= tls really > > don't apply, but you'll need to support the full device interface, > > right?=C2=A0=C2=A0That includes the region info ioctl and access thro= ugh the vfio > > device file descriptor as well as the interrupt info and setup ioctls= . > >=20 >=20 > [All interfaces I thought are via ioctl:)=C2=A0=C2=A0For other stuff li= ke file > descriptor we'll definitely keep it.] >=20 > The list of ioctl commands provided by vfio_pci: >=20 > - VFIO_DEVICE_GET_PCI_HOT_RESET_INFO > - VFIO_DEVICE_PCI_HOT_RESET >=20 > As you said, above 2 don't apply. But for this: >=20 > - VFIO_DEVICE_RESET >=20 > In my opinion it should be kept, no matter what will be provided in > the bus driver. Yes, the DEVICE_INFO ioctl describes whether it's present, I would encourage implementing it. > - VFIO_PCI_ROM_REGION_INDEX > - VFIO_PCI_VGA_REGION_INDEX >=20 > I suppose above 2 don't apply neither? For a vgpu we don't provide a > ROM BAR or VGA region. Right, these aren't ioctls, just indexes into the REGION_INFO ioctl, they're optional. > - VFIO_DEVICE_GET_INFO > - VFIO_DEVICE_GET_REGION_INFO > - VFIO_DEVICE_GET_IRQ_INFO > - VFIO_DEVICE_SET_IRQS >=20 > Above 4 are needed of course. >=20 > We will need to extend: >=20 > - VFIO_DEVICE_GET_REGION_INFO >=20 >=20 > a) adding a flag: DONT_MAP. For example, the MMIO of vgpu > should be trapped instead of being mmap-ed. There's already an MMAP flag, mmap is only allowed when this is set, so there's no need for the anti-flag. =C2=A0I'm also working on support for sparse mmap capabilities so that within a region some portions can support mmap. > b) adding other information. For example, for the OpRegion, QEMU need > to do more than mmap a region, it has to: >=20 > - allocate a region > - copy contents from somewhere in host to that region > - mmap it to guest >=20 >=20 > I remember you already have a prototype for this? Yes, I'm working on this currently, it will by a device specific region and QEMU can either copy the contents to a new buffer in guest memory or provided trapped access to the host opregion. =C2=A0I thought vgpus weren't going to need opregions though, I figured it was more for GVT-d=20 support. =C2=A0Thanks, Alex