From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex Williamson <alex.williamson@redhat.com>
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>
	 <AADFC41AFE54684AB9EE6CBC0274A5D15F786B4B@SHSMSX101.ccr.corp.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>
	 <AADFC41AFE54684AB9EE6CBC0274A5D15F78EAEA@SHSMSX101.ccr.corp.intel.com>
	 <1453844613.18049.1.camel@redhat.com>
	 <AADFC41AFE54684AB9EE6CBC0274A5D15F78EB95@SHSMSX101.ccr.corp.intel.com>
	 <1453846073.18049.3.camel@redhat.com>
	 <AADFC41AFE54684AB9EE6CBC0274A5D15F78ECBB@SHSMSX101.ccr.corp.intel.com>
	 <1453847250.18049.5.camel@redhat.com>
	 <AADFC41AFE54684AB9EE6CBC0274A5D15F78ED63@SHSMSX101.ccr.corp.intel.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 <jike.song@intel.com>,
	Yang Zhang <yang.zhang.wz@gmail.com>,
	"igvt-g@lists.01.org" <igvt-g@ml01.01.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
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 <rfc822;kvm@vger.kernel.org>);
	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: <kvm.vger.kernel.org>

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