From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neo Jia Subject: Re: RE: [iGVT-g] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Date: Wed, 3 Feb 2016 00:41:13 -0800 Message-ID: <20160203084113.GA25545@nvidia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Lv, Zhiyuan" , Alex Williamson , Gerd Hoffmann , Yang Zhang , "igvt-g@lists.01.org" , qemu-devel , "kvm@vger.kernel.org" , Paolo Bonzini , Kirti Wankhede To: "Tian, Kevin" Return-path: Received: from hqemgate15.nvidia.com ([216.228.121.64]:6136 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964871AbcBCIlU convert rfc822-to-8bit (ORCPT ); Wed, 3 Feb 2016 03:41:20 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Feb 03, 2016 at 08:04:16AM +0000, Tian, Kevin wrote: > > From: Zhiyuan Lv > > Sent: Tuesday, February 02, 2016 3:35 PM > >=20 > > Hi Gerd/Alex, > >=20 > > On Mon, Feb 01, 2016 at 02:44:55PM -0700, Alex Williamson wrote: > > > On Mon, 2016-02-01 at 14:10 +0100, Gerd Hoffmann wrote: > > > > =A0 Hi, > > > > > > > > > > Unfortunately it's not the only one. Another example is, de= vice-model > > > > > > may want to write-protect a gfn (RAM). In case that this re= quest goes > > > > > > to VFIO .. how it is supposed to reach KVM MMU? > > > > > > > > > > Well, let's work through the problem.=A0=A0How is the GFN rel= ated to the > > > > > device?=A0=A0Is this some sort of page table for device mappi= ngs with a base > > > > > register in the vgpu hardware? > > > > > > > > IIRC this is needed to make sure the guest can't bypass execbuf= fer > > > > verification and works like this: > > > > > > > > =A0 (1) guest submits execbuffer. > > > > =A0 (2) host makes execbuffer readonly for the guest > > > > =A0 (3) verify the buffer (make sure it only accesses resources= owned by > > > > =A0=A0=A0=A0=A0=A0the vm). > > > > =A0 (4) pass on execbuffer to the hardware. > > > > =A0 (5) when the gpu is done with it make the execbuffer writab= le again. > > > > > > Ok, so are there opportunities to do those page protections outsi= de of > > > KVM?=A0=A0We should be able to get the vma for the buffer, can we= do > > > something with that to make it read-only.=A0=A0Alternatively can = the vgpu > > > driver copy it to a private buffer and hardware can execute from = that? > > > I'm not a virtual memory expert, but it doesn't seem like an > > > insurmountable problem.=A0=A0Thanks, > >=20 > > Originally iGVT-g used write-protection for privilege execbuffers, = as Gerd > > described. Now the latest implementation has removed wp to do buffe= r copy > > instead, since the privilege command buffers are usually small. So = that part > > is fine. > >=20 > > But we need write-protection for graphics page table shadowing as w= ell. Once > > guest driver modifies gpu page table, we need to know that and mani= pulate > > shadow page table accordingly. buffer copy cannot help here. Thanks= ! > >=20 >=20 >=20 > 4) Map/unmap guest memory > -- > It's there for KVM. >=20 > 5) Pin/unpin guest memory > -- > IGD or any PCI passthru should have same requirement. So we should be > able to leverage existing code in VFIO. The only tricky thing (Jike m= ay > elaborate after he is back), is that KVMGT requires to pin EPT entry = too, > which requires some further change in KVM side. But I'm not sure whet= her > it still holds true after some design changes made in this thread. So= I'll > leave to Jike to further comment. >=20 Hi Kevin, I think you should be able to map and pin guest memory via the IOMMU AP= I, not KVM. > Well, then I realize pretty much opens have been covered with a solut= ion > when ending this write-up. Then we should move forward to come up a > prototype upon which we can then identify anything missing or overloo= ked > (definitely there would be), and also discuss several remaining opens= atop > (such as exit-less emulation, pin/unpin, etc.). Another thing we nee= d > to think is whether this new design is still compatible to Xen side. >=20 > Thanks a lot all for the great discussion (especially Alex with many = good > inputs)! I believe it becomes much clearer now than 2 weeks ago, abou= t=20 > how to integrate KVMGT with VFIO. :-) >=20 It is great to see you guys are onboard with VFIO solution! As Kirti ha= s mentioned in other threads, let's review the current registration APIs = and figure out what we need to add for both solutions. Thanks, Neo > Thanks > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html