intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Arvind Yadav <arvind.yadav@intel.com>
To: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: rodrigo.vivi@intel.com, matthew.brost@intel.com,
	himal.prasad.ghimiray@intel.com,
	thomas.hellstrom@linux.intel.com
Subject: [PATCH 5/5] drm/xe/guc: Reset LRC ring pointers before replay
Date: Wed, 16 Sep 2026 15:23:37 +0530	[thread overview]
Message-ID: <20260916095337.3104891-6-arvind.yadav@intel.com> (raw)
In-Reply-To: <20260916095337.3104891-1-arvind.yadav@intel.com>

A GT reset can stop a context after the LRC head has advanced past the
start of the oldest pending job.

The replay path rewinds the software ring tail to the job's recorded
start so the pending jobs are written again. However, it leaves the LRC
head at its saved later position and initializes the LRC tail from that
position.

The hardware and software ring positions can therefore use different
replay starting points.

Before resubmitting the queue, set the software tail and both LRC ring
pointers to the start of the oldest pending job. Update the pointers
while the context is unregistered, before resubmitting pending jobs.

Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
---
 drivers/gpu/drm/xe/xe_guc_submit.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
index ca24a77dfb26..878ba94d22e0 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -2984,17 +2984,17 @@ static void guc_exec_queue_start(struct xe_exec_queue *q)
 		trace_xe_exec_queue_resubmit(q);
 		if (job) {
 			for (i = 0; i < q->width; ++i) {
+				u32 replay_head = job->ptrs[i].head;
+
 				/*
-				 * The GuC context is unregistered at this point
-				 * time, adjusting software ring tail ensures
-				 * jobs are rewritten in original placement,
-				 * adjusting LRC tail ensures the newly loaded
-				 * GuC / contexts only view the LRC tail
-				 * increasing as jobs are written out.
+				 * A started job may have advanced the saved LRC
+				 * head past its original ring position. Rewind
+				 * both head and tail before rewriting and
+				 * replaying the pending jobs.
 				 */
-				q->lrc[i]->ring.tail = job->ptrs[i].head;
-				xe_lrc_set_ring_tail(q->lrc[i],
-						     xe_lrc_ring_head(q->lrc[i]));
+				q->lrc[i]->ring.tail = replay_head;
+				xe_lrc_set_ring_head(q->lrc[i], replay_head);
+				xe_lrc_set_ring_tail(q->lrc[i], replay_head);
 			}
 		}
 		xe_sched_resubmit_jobs(sched);
-- 
2.43.0


  parent reply	other threads:[~2026-09-16  9:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  9:53 [PATCH 0/5] drm/xe: Fix VM teardown and migration queue recovery Arvind Yadav
2026-09-16  9:53 ` [PATCH 1/5] drm/xe: Hold a device reference across deferred VM destruction Arvind Yadav
2026-09-18  3:22   ` Matthew Brost
2026-09-18  7:22     ` Thomas Hellström
2026-09-18 22:41       ` Matthew Brost
2026-09-21  7:06         ` Thomas Hellström
2026-09-16  9:53 ` [PATCH 2/5] drm/xe/guc: Wake disable waiters after clearing pending state Arvind Yadav
2026-09-18 22:36   ` Matthew Brost
2026-09-21  6:46     ` Yadav, Arvind
2026-09-16  9:53 ` [PATCH 3/5] drm/xe: Mark VMs as closing before queue cleanup Arvind Yadav
2026-09-16  9:53 ` [PATCH 4/5] drm/xe: Defer VM teardown until exec queue cleanup completes Arvind Yadav
2026-09-16  9:53 ` Arvind Yadav [this message]
2026-09-16 10:01 ` ✓ CI.KUnit: success for drm/xe: Fix VM teardown and migration queue recovery Patchwork
2026-09-16 10:59 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-16 12:11 ` ✓ Xe.CI.FULL: " Patchwork
2026-09-18 22:31 ` [PATCH 0/5] " Matthew Brost
2026-09-24 10:06   ` Yadav, Arvind

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260916095337.3104891-6-arvind.yadav@intel.com \
    --to=arvind.yadav@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).