[PATCH] drm/i915/gvt: Fix crash after request->hw_context change

[PATCH] drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

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 context.

Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
index 2efb723b90cb..00f79fc940da 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -125,8 +125,9 @@ static int populate_shadow_context(struct intel_vgpu_workload *workload)
 	struct intel_vgpu *vgpu = workload->vgpu;
 	struct intel_gvt *gvt = vgpu->gvt;
 	int ring_id = workload->ring_id;
+	struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
 	struct drm_i915_gem_object *ctx_obj =
-		workload->req->hw_context->state->obj;
+		shadow_ctx->__engine[ring_id].state->obj;
 	struct execlist_ring_context *shadow_ring_context;
 	struct page *page;
 	void *dst;
@@ -595,8 +596,6 @@ static int prepare_workload(struct intel_vgpu_workload *workload)
 		return ret;
 	}
 
-	update_shadow_pdps(workload);
-
 	ret = intel_vgpu_sync_oos_pages(workload->vgpu);
 	if (ret) {
 		gvt_vgpu_err("fail to vgpu sync oos pages\n");
@@ -615,6 +614,8 @@ static int prepare_workload(struct intel_vgpu_workload *workload)
 		goto err_unpin_mm;
 	}
 
+	update_shadow_pdps(workload);
+
 	ret = prepare_shadow_batch_buffer(workload);
 	if (ret) {
 		gvt_vgpu_err("fail to prepare_shadow_batch_buffer\n");
@@ -825,7 +826,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		scheduler->current_workload[ring_id];
 	struct intel_vgpu *vgpu = workload->vgpu;
 	struct intel_vgpu_submission *s = &vgpu->submission;
-	struct i915_request *rq;
+	struct i915_request *rq = workload->req;
 	int event;
 
 	mutex_lock(&vgpu->vgpu_lock);
@@ -835,7 +836,6 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 	 * switch to make sure request is completed.
 	 * For the workload w/o request, directly complete the workload.
 	 */
-	rq = fetch_and_zero(&workload->req);
 	if (rq) {
 		wait_event(workload->shadow_ctx_status_wq,
 			   !atomic_read(&workload->shadow_ctx_active));
@@ -866,7 +866,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		intel_context_unpin(rq->hw_context);
 		mutex_unlock(&rq->i915->drm.struct_mutex);
 
-		i915_request_put(rq);
+		i915_request_put(fetch_and_zero(&workload->req));
 	}
 
 	gvt_dbg_sched("ring id %d complete workload %p status %d\n",
-- 
2.17.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/gvt: Fix crash after request->hw_context change

[Chris Wilson]

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 context.

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

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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change
URL   : https://patchwork.freedesktop.org/series/43406/
State : failure

== Summary ==

Applying: drm/i915/gvt: Fix crash after request->hw_context change
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/scheduler.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change

[Chris Wilson]

Quoting Patchwork (2018-05-18 11:55:01)
> == Series Details ==
> 
> Series: drm/i915/gvt: Fix crash after request->hw_context change
> URL   : https://patchwork.freedesktop.org/series/43406/
> State : failure
> 
> == Summary ==
> 
> Applying: drm/i915/gvt: Fix crash after request->hw_context change
> error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/scheduler.c).
> error: could not build fake ancestor
> Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change

Wrong tree used as teh baseline, could you resend? Or an alternative to
avoid dereferencing state outside of being pinned?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: ??? Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1072 bytes --]

On 2018.05.18 12:03:02 +0100, Chris Wilson wrote:
> Quoting Patchwork (2018-05-18 11:55:01)
> > == Series Details ==
> > 
> > Series: drm/i915/gvt: Fix crash after request->hw_context change
> > URL   : https://patchwork.freedesktop.org/series/43406/
> > State : failure
> > 
> > == Summary ==
> > 
> > Applying: drm/i915/gvt: Fix crash after request->hw_context change
> > error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/scheduler.c).
> > error: could not build fake ancestor
> > Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change
> 
> Wrong tree used as teh baseline, could you resend? Or an alternative to
> avoid dereferencing state outside of being pinned?

Sorry, applied against gvt dev tree which has unmerged ones against
dinq. Current code is to try to do possible shadowing earlier even not
requiring real request be allocated, need to relook for proper lifetime
to sort this out.

-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1098 bytes --]

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 context.
> 
> 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
> 
> 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?

-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/gvt: Fix crash after request->hw_context change

[Chris Wilson]

Quoting Zhenyu Wang (2018-05-21 04:44:34)
> 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 context.
> > 
> > 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
> > 
> > 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?

It's just a matter of how you get it. The only reason I was using the
request was that had an explicit pointer to the pinned context; it
looked easier to keep using that rather than add a separate context
member. If you would rather do that, do so -- please don't keep
tacitly using the gem_context to derive the intel_context without any
obvious sign of protection. (It's just that the link between gem_context
and intel_context is going to become more tenuous, so it is important we
make the ownership and lifecycle of intel_context more explicit.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2] drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

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 context.

v2: Move request alloc earlier as already try to track shadow status
depending on request state, which also facilitate to use request->hw_context
for target engine context reference.

Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 52 +++++++++-------------------
 1 file changed, 16 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c
index e1760030dda1..7f5e01df95ee 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -348,6 +348,7 @@ int intel_gvt_scan_and_shadow_workload(struct intel_vgpu_workload *workload)
 	struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
 	struct intel_engine_cs *engine = dev_priv->engine[workload->ring_id];
 	struct intel_context *ce;
+	struct i915_request *rq;
 	int ret;
 
 	lockdep_assert_held(&dev_priv->drm.struct_mutex);
@@ -386,46 +387,26 @@ int intel_gvt_scan_and_shadow_workload(struct intel_vgpu_workload *workload)
 			goto err_shadow;
 	}
 
-	ret = populate_shadow_context(workload);
-	if (ret)
-		goto err_shadow;
-
-	return 0;
-
-err_shadow:
-	release_shadow_wa_ctx(&workload->wa_ctx);
-err_unpin:
-	intel_context_unpin(ce);
-	return ret;
-}
-
-static int intel_gvt_generate_request(struct intel_vgpu_workload *workload)
-{
-	int ring_id = workload->ring_id;
-	struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
-	struct i915_request *rq;
-	struct intel_vgpu *vgpu = workload->vgpu;
-	struct intel_vgpu_submission *s = &vgpu->submission;
-	struct i915_gem_context *shadow_ctx = s->shadow_ctx;
-	int ret;
-
-	rq = i915_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
+	rq = i915_request_alloc(engine, shadow_ctx);
 	if (IS_ERR(rq)) {
 		gvt_vgpu_err("fail to allocate gem request\n");
 		ret = PTR_ERR(rq);
-		goto err_unpin;
+		goto err_shadow;
 	}
-
-	gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
-
 	workload->req = i915_request_get(rq);
-	ret = copy_workload_to_ring_buffer(workload);
+
+	ret = populate_shadow_context(workload);
 	if (ret)
-		goto err_unpin;
-	return 0;
+		goto err_req;
 
-err_unpin:
+	return 0;
+err_req:
+	rq = fetch_and_zero(&workload->req);
+	i915_request_put(rq);
+err_shadow:
 	release_shadow_wa_ctx(&workload->wa_ctx);
+err_unpin:
+	intel_context_unpin(ce);
 	return ret;
 }
 
@@ -609,7 +590,7 @@ static int prepare_workload(struct intel_vgpu_workload *workload)
 		goto err_unpin_mm;
 	}
 
-	ret = intel_gvt_generate_request(workload);
+	ret = copy_workload_to_ring_buffer(workload);
 	if (ret) {
 		gvt_vgpu_err("fail to generate request\n");
 		goto err_unpin_mm;
@@ -823,7 +804,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		scheduler->current_workload[ring_id];
 	struct intel_vgpu *vgpu = workload->vgpu;
 	struct intel_vgpu_submission *s = &vgpu->submission;
-	struct i915_request *rq;
+	struct i915_request *rq = workload->req;
 	int event;
 
 	mutex_lock(&gvt->lock);
@@ -832,7 +813,6 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 	 * switch to make sure request is completed.
 	 * For the workload w/o request, directly complete the workload.
 	 */
-	rq = fetch_and_zero(&workload->req);
 	if (rq) {
 		wait_event(workload->shadow_ctx_status_wq,
 			   !atomic_read(&workload->shadow_ctx_active));
@@ -863,7 +843,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		intel_context_unpin(rq->hw_context);
 		mutex_unlock(&rq->i915->drm.struct_mutex);
 
-		i915_request_put(rq);
+		i915_request_put(fetch_and_zero(&workload->req));
 	}
 
 	gvt_dbg_sched("ring id %d complete workload %p status %d\n",
-- 
2.17.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: Fix crash after request->hw_context change (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL   : https://patchwork.freedesktop.org/series/43406/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4eec44c20bac drm/i915/gvt: Fix crash after request->hw_context change
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#8: 
delay to zero workload's request pointer after used for update guest context.

total: 0 errors, 1 warnings, 0 checks, 96 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for drm/i915/gvt: Fix crash after request->hw_context change (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL   : https://patchwork.freedesktop.org/series/43406/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4211 -> Patchwork_9062 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/43406/revisions/2/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9062 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_chamelium@hdmi-hpd-fast:
      fi-kbl-7500u:       SKIP -> FAIL (fdo#103841, fdo#102672)

    igt@kms_frontbuffer_tracking@basic:
      fi-hsw-4200u:       PASS -> DMESG-FAIL (fdo#102614, fdo#106103)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
      fi-cnl-psr:         PASS -> DMESG-WARN (fdo#104951)

    
    ==== Possible fixes ====

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      fi-cnl-y3:          DMESG-WARN (fdo#104951) -> PASS

    
  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
  fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103


== Participating hosts (42 -> 38) ==

  Missing    (4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq 


== Build changes ==

    * Linux: CI_DRM_4211 -> Patchwork_9062

  CI_DRM_4211: 1427d7c0760072ddcb2060fce079cc5c70fec914 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9062: 4eec44c20bac95e27cf69a4fdfa811ecf6f7a81a @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit


== Linux commits ==

4eec44c20bac drm/i915/gvt: Fix crash after request->hw_context change

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9062/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for drm/i915/gvt: Fix crash after request->hw_context change (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL   : https://patchwork.freedesktop.org/series/43406/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4211_full -> Patchwork_9062_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9062_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9062_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/43406/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_9062_full:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_schedule@deep-bsd2:
      shard-kbl:          PASS -> SKIP

    igt@gem_exec_schedule@deep-render:
      shard-kbl:          SKIP -> PASS

    
== Known issues ==

  Here are the changes found in Patchwork_9062_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_cursor_legacy@flip-vs-cursor-legacy:
      shard-hsw:          PASS -> FAIL (fdo#102670)

    igt@kms_flip@2x-flip-vs-expired-vblank:
      shard-glk:          PASS -> FAIL (fdo#105363)

    igt@kms_flip@2x-wf_vblank-ts-check-interruptible:
      shard-hsw:          PASS -> FAIL (fdo#103928)

    igt@kms_flip@plain-flip-ts-check:
      shard-glk:          PASS -> FAIL (fdo#100368)

    igt@kms_flip_tiling@flip-to-x-tiled:
      shard-glk:          PASS -> FAIL (fdo#104724)

    igt@kms_flip_tiling@flip-y-tiled:
      shard-glk:          PASS -> FAIL (fdo#103822, fdo#104724)

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)

    igt@perf@polling:
      shard-hsw:          PASS -> FAIL (fdo#102252)

    
    ==== Possible fixes ====

    igt@gem_exec_schedule@deep-bsd1:
      shard-kbl:          DMESG-WARN (fdo#103558, fdo#105602) -> PASS +1

    igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
      shard-glk:          FAIL (fdo#105703) -> PASS

    igt@kms_flip_tiling@flip-to-y-tiled:
      shard-glk:          FAIL (fdo#104724) -> PASS

    igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc:
      shard-glk:          FAIL (fdo#103167, fdo#104724) -> PASS

    igt@kms_setmode@basic:
      shard-kbl:          FAIL (fdo#99912) -> PASS

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
  fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (9 -> 9) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4211 -> Patchwork_9062

  CI_DRM_4211: 1427d7c0760072ddcb2060fce079cc5c70fec914 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9062: 4eec44c20bac95e27cf69a4fdfa811ecf6f7a81a @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9062/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2] drm/i915/gvt: Fix crash after request->hw_context change

[Chris Wilson]

Quoting Zhenyu Wang (2018-05-21 09:17:52)
> 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 context.
> 
> v2: Move request alloc earlier as already try to track shadow status
> depending on request state, which also facilitate to use request->hw_context
> for target engine context reference.
> 
> Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Zhi Wang <zhi.a.wang@intel.com>
> Cc: Weinan Li <weinan.z.li@intel.com>
> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Looks like it's applying the principles we discussed to avoid
chasing gem_context to get at the pinned intel_context,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks for the fixup!
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2] drm/i915/gvt: Fix crash after request->hw_context change

[Chris Wilson]

Quoting Chris Wilson (2018-05-21 10:54:57)
> Quoting Zhenyu Wang (2018-05-21 09:17:52)
> > 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 context.
> > 
> > v2: Move request alloc earlier as already try to track shadow status
> > depending on request state, which also facilitate to use request->hw_context
> > for target engine context reference.
> > 
> > Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Cc: Zhi Wang <zhi.a.wang@intel.com>
> > Cc: Weinan Li <weinan.z.li@intel.com>
> > Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
> 
> Looks like it's applying the principles we discussed to avoid
> chasing gem_context to get at the pinned intel_context,
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Thanks for the fixup!

And pushed, many thanks again.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx