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