From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [iGVT-g] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Date: Mon, 01 Feb 2016 14:10:46 +0100 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Cc: Jike Song , Yang Zhang , "igvt-g@lists.01.org" , qemu-devel , "kvm@vger.kernel.org" , Paolo Bonzini To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46641 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932314AbcBANKt convert rfc822-to-8bit (ORCPT ); Mon, 1 Feb 2016 08:10:49 -0500 In-Reply-To: <1454093405.23148.13.camel@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQEFp-0008Gi-HR for qemu-devel@nongnu.org; Mon, 01 Feb 2016 08:10:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQEFl-0002CX-EI for qemu-devel@nongnu.org; Mon, 01 Feb 2016 08:10:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQEFl-0002CR-8g for qemu-devel@nongnu.org; Mon, 01 Feb 2016 08:10:49 -0500 Message-ID: <1454332246.10168.47.camel@redhat.com> From: Gerd Hoffmann Date: Mon, 01 Feb 2016 14:10:46 +0100 In-Reply-To: <1454093405.23148.13.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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 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 Cc: Yang Zhang , "igvt-g@lists.01.org" , Jike Song , "kvm@vger.kernel.org" , qemu-devel , Paolo Bonzini 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? >=20 > 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. cheers, Gerd