drm/xe/guc: Publish the ring tail when replaying a chained ULLS job

A chained ULLS job skips the ring tail write in submit_exec_queue()
since its predecessor's postamble has already published it from within
the ring. After a GT reset the context is re-registered with scheduling
disabled and that postamble is gone, so nothing publishes the replayed
job's tail: the context is enabled with head == tail and the job never
starts. On the kernel migration queue the second timeout wedges the
device.

Publish the tail for a chained job when the queue is not enabled. This
is the state in which submit_exec_queue() already sends the scheduling
enable H2G instead of relying on a resident context, and the tail write
precedes that H2G. guc_exec_queue_stop() clears ENABLED on reset and
register_exec_queue() does not set it, so the first replayed ULLS job
always takes this path; its re-emitted postamble then publishes the
next tail as usual. With the queue enabled nothing changes.

job->restore_replay does not identify this case, it is only set on the
SR-IOV VF pause/unpause path.

Fixes: 40c756bdbbee ("drm/xe: Add ULLS migration job support to GuC submission")
Cc: Matthew Brost <matthew.brost@intel.com>
Assisted-by: LLM
Signed-off-by: Varun Gupta <varun.gupta@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260930094031.3365707-7-varun.gupta@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

0 files changed, 0 insertions, 0 deletions