From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Subject: Re: [PATCH] drm/i915/gvt: Fix crash after
 request->hw_context change
Date: Mon, 21 May 2018 11:44:34 +0800
Message-ID: <20180521034434.o5o5epslmftduvyv@zhen-hp.sh.intel.com>
References: <20180518101305.8840-1-zhenyuw@linux.intel.com>
 <152663892627.13126.3694348985111443754@mail.alporthouse.com>
Reply-To: Zhenyu Wang <zhenyuw@linux.intel.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0103153051=="
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
In-Reply-To: <152663892627.13126.3694348985111443754@mail.alporthouse.com>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org


--===============0103153051==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="dkk4q3r4rutneqaf"
Content-Disposition: inline


--dkk4q3r4rutneqaf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018.05.18 11:22:06 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-05-18 11:13:05)
> > When we do shadowing, workload's request might not be allocated yet,
> > so we still require shadow context's object. And when complete workload,
> > delay to zero workload's request pointer after used for update guest co=
ntext.
>=20
> Please allocate the context earlier then. The point is that until you
> do, shadow_ctx->__engine[ring_id]->state is *undefined* and this code is
> still illegal. :-p
>=20
> The intent is that you start tracking the lifetime of the state you are
> using because the assumptions made here will not hold for much longer.

Chris, after double check, for shadowing we do assure to pin our
context earlier for target engine context, so shadow_ctx->__engine[ring_id]=
->state
is always valid. We just don't require the real request be generated earlier
during scan/shadow, so use pinned context state pointer directly. Will that=
 be
a problem in future?

--=20
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

--dkk4q3r4rutneqaf
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTXuabgHDW6LPt9CICxBBozTXgYJwUCWwJAogAKCRCxBBozTXgY
JzhYAJ4xRmgv18VxRKlSVjxpx0smGzfMRwCgn2h5Y1ytwtw9BzY+f5Fv7rWuiww=
=aIsz
-----END PGP SIGNATURE-----

--dkk4q3r4rutneqaf--

--===============0103153051==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4
IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg==

--===============0103153051==--