From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhiyuan Lv Subject: Re: [iGVT-g] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Date: Tue, 2 Feb 2016 15:35:10 +0800 Message-ID: <20160202073510.GA672@zlv-hp-dev> References: <1453864068.3107.3.camel@redhat.com> <56A85913.1020506@intel.com> <1453911589.6261.5.camel@redhat.com> <56A9AE69.3060604@intel.com> <1453994586.29166.1.camel@redhat.com> <56AB12CC.5000402@intel.com> <56AB27AA.80602@intel.com> <1454093405.23148.13.camel@redhat.com> <1454332246.10168.47.camel@redhat.com> <1454363095.10542.10.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Yang Zhang , "igvt-g@lists.01.org" , "kvm@vger.kernel.org" , qemu-devel , Paolo Bonzini To: Alex Williamson , Gerd Hoffmann Return-path: Received: from mga01.intel.com ([192.55.52.88]:65446 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753410AbcBBHqL (ORCPT ); Tue, 2 Feb 2016 02:46:11 -0500 Content-Disposition: inline In-Reply-To: <1454363095.10542.10.camel@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Hi Gerd/Alex, 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, > >=A0 > > > > Unfortunately it's not the only one. Another example is, device= -model > > > > may want to write-protect a gfn (RAM). In case that this reques= t goes > > > > to VFIO .. how it is supposed to reach KVM MMU? > > >=A0 > > > Well, let's work through the problem.=A0=A0How is the GFN related= to the > > > device?=A0=A0Is this some sort of page table for device mappings = with a base > > > register in the vgpu hardware? > >=A0 > > IIRC this is needed to make sure the guest can't bypass execbuffer > > verification and works like this: > >=A0 > > =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 own= ed 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 writable a= gain. >=20 > Ok, so are there opportunities to do those page protections outside o= f > 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, Originally iGVT-g used write-protection for privilege execbuffers, as G= erd described. Now the latest implementation has removed wp to do buffer co= py instead, since the privilege command buffers are usually small. So that= part is fine. But we need write-protection for graphics page table shadowing as well.= Once guest driver modifies gpu page table, we need to know that and manipula= te shadow page table accordingly. buffer copy cannot help here. Thanks! Regards, -Zhiyuan >=20 > Alex >=20 > _______________________________________________ > iGVT-g mailing list > iGVT-g@lists.01.org > https://lists.01.org/mailman/listinfo/igvt-g From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQVfG-00086H-5u for qemu-devel@nongnu.org; Tue, 02 Feb 2016 02:46:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQVfA-0000Cm-JH for qemu-devel@nongnu.org; Tue, 02 Feb 2016 02:46:18 -0500 Received: from mga14.intel.com ([192.55.52.115]:60534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQVfA-0000CW-Dy for qemu-devel@nongnu.org; Tue, 02 Feb 2016 02:46:12 -0500 Date: Tue, 2 Feb 2016 15:35:10 +0800 From: Zhiyuan Lv Message-ID: <20160202073510.GA672@zlv-hp-dev> References: <1453864068.3107.3.camel@redhat.com> <56A85913.1020506@intel.com> <1453911589.6261.5.camel@redhat.com> <56A9AE69.3060604@intel.com> <1453994586.29166.1.camel@redhat.com> <56AB12CC.5000402@intel.com> <56AB27AA.80602@intel.com> <1454093405.23148.13.camel@redhat.com> <1454332246.10168.47.camel@redhat.com> <1454363095.10542.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1454363095.10542.10.camel@redhat.com> Subject: Re: [Qemu-devel] [iGVT-g] 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: Alex Williamson , Gerd Hoffmann Cc: Yang Zhang , "igvt-g@lists.01.org" , qemu-devel , "kvm@vger.kernel.org" , Paolo Bonzini Hi Gerd/Alex, 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: > >   Hi, > >  > > > > Unfortunately it's not the only one. Another example is, device-model > > > > may want to write-protect a gfn (RAM). In case that this request goes > > > > to VFIO .. how it is supposed to reach KVM MMU? > > >  > > > Well, let's work through the problem.  How is the GFN related to the > > > device?  Is this some sort of page table for device mappings with a base > > > register in the vgpu hardware? > >  > > IIRC this is needed to make sure the guest can't bypass execbuffer > > verification and works like this: > >  > >   (1) guest submits execbuffer. > >   (2) host makes execbuffer readonly for the guest > >   (3) verify the buffer (make sure it only accesses resources owned by > >       the vm). > >   (4) pass on execbuffer to the hardware. > >   (5) when the gpu is done with it make the execbuffer writable again. > > Ok, so are there opportunities to do those page protections outside of > KVM?  We should be able to get the vma for the buffer, can we do > something with that to make it read-only.  Alternatively 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.  Thanks, Originally iGVT-g used write-protection for privilege execbuffers, as Gerd described. Now the latest implementation has removed wp to do buffer copy instead, since the privilege command buffers are usually small. So that part is fine. But we need write-protection for graphics page table shadowing as well. Once guest driver modifies gpu page table, we need to know that and manipulate shadow page table accordingly. buffer copy cannot help here. Thanks! Regards, -Zhiyuan > > Alex > > _______________________________________________ > iGVT-g mailing list > iGVT-g@lists.01.org > https://lists.01.org/mailman/listinfo/igvt-g