From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [iGVT-g] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Date: Mon, 01 Feb 2016 14:44:55 -0700 Message-ID: <1454363095.10542.10.camel@redhat.com> References: <569C5071.6080004@intel.com> <569F4C86.2070501@intel.com> <56A6083E.10703@intel.com> <1453757426.32741.614.camel@redhat.com> <56A72313.9030009@intel.com> <56A77D2D.40109@gmail.com> <1453826249.26652.54.camel@redhat.com> <1453844613.18049.1.camel@redhat.com> <1453846073.18049.3.camel@redhat.com> <1453847250.18049.5.camel@redhat.com> <1453848975.18049.7.camel@redhat.com> <56A821AD.5090606@intel.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jike Song , Yang Zhang , "igvt-g@lists.01.org" , qemu-devel , "kvm@vger.kernel.org" , Paolo Bonzini To: Gerd Hoffmann Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50664 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753773AbcBAVo4 (ORCPT ); Mon, 1 Feb 2016 16:44:56 -0500 In-Reply-To: <1454332246.10168.47.camel@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2016-02-01 at 14:10 +0100, Gerd Hoffmann wrote: > =C2=A0 Hi, >=C2=A0 > > > Unfortunately it's not the only one. Another example is, device-m= odel > > > may want to write-protect a gfn (RAM). In case that this request = goes > > > to VFIO .. how it is supposed to reach KVM MMU? > >=C2=A0 > > Well, let's work through the problem.=C2=A0=C2=A0How is the GFN rel= ated to the > > device?=C2=A0=C2=A0Is this some sort of page table for device mappi= ngs with a base > > register in the vgpu hardware? >=C2=A0 > IIRC this is needed to make sure the guest can't bypass execbuffer > verification and works like this: >=C2=A0 > =C2=A0 (1) guest submits execbuffer. > =C2=A0 (2) host makes execbuffer readonly for the guest > =C2=A0 (3) verify the buffer (make sure it only accesses resources ow= ned by > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the vm). > =C2=A0 (4) pass on execbuffer to the hardware. > =C2=A0 (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?=C2=A0=C2=A0We should be able to get the vma for the buffer, can we= do something with that to make it read-only.=C2=A0=C2=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.=C2=A0=C2=A0Thanks, Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQMHO-00080e-P4 for qemu-devel@nongnu.org; Mon, 01 Feb 2016 16:45:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQMHJ-0005ke-PP for qemu-devel@nongnu.org; Mon, 01 Feb 2016 16:45:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQMHJ-0005kK-Jp for qemu-devel@nongnu.org; Mon, 01 Feb 2016 16:44:57 -0500 Message-ID: <1454363095.10542.10.camel@redhat.com> From: Alex Williamson Date: Mon, 01 Feb 2016 14:44:55 -0700 In-Reply-To: <1454332246.10168.47.camel@redhat.com> References: <569C5071.6080004@intel.com> <569F4C86.2070501@intel.com> <56A6083E.10703@intel.com> <1453757426.32741.614.camel@redhat.com> <56A72313.9030009@intel.com> <56A77D2D.40109@gmail.com> <1453826249.26652.54.camel@redhat.com> <1453844613.18049.1.camel@redhat.com> <1453846073.18049.3.camel@redhat.com> <1453847250.18049.5.camel@redhat.com> <1453848975.18049.7.camel@redhat.com> <56A821AD.5090606@intel.com> <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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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: Gerd Hoffmann Cc: Yang Zhang , "igvt-g@lists.01.org" , Jike Song , "kvm@vger.kernel.org" , qemu-devel , Paolo Bonzini On Mon, 2016-02-01 at 14:10 +0100, Gerd Hoffmann wrote: > =C2=A0 Hi, >=C2=A0 > > > Unfortunately it's not the only one. Another example is, device-mod= el > > > may want to write-protect a gfn (RAM). In case that this request go= es > > > to VFIO .. how it is supposed to reach KVM MMU? > >=C2=A0 > > Well, let's work through the problem.=C2=A0=C2=A0How is the GFN relat= ed to the > > device?=C2=A0=C2=A0Is this some sort of page table for device mapping= s with a base > > register in the vgpu hardware? >=C2=A0 > IIRC this is needed to make sure the guest can't bypass execbuffer > verification and works like this: >=C2=A0 > =C2=A0 (1) guest submits execbuffer. > =C2=A0 (2) host makes execbuffer readonly for the guest > =C2=A0 (3) verify the buffer (make sure it only accesses resources owne= d by > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the vm). > =C2=A0 (4) pass on execbuffer to the hardware. > =C2=A0 (5) when the gpu is done with it make the execbuffer writable ag= ain. Ok, so are there opportunities to do those page protections outside of KVM?=C2=A0=C2=A0We should be able to get the vma for the buffer, can we d= o something with that to make it read-only.=C2=A0=C2=A0Alternatively can th= e 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.=C2=A0=C2=A0Thanks, Alex