Re: [PATCH v4 22/25] drm/xe: Add ULLS migration job support to GuC submission

[Matthew Brost <matthew.brost@intel.com>]

On Fri, Sep 04, 2026 at 12:38:37AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] Direct MMIO write to the physical engine's RING_TAIL for GuC-scheduled ULLS jobs causes hardware state corruption if the context is preempted or evicted.
> --
> 
> commit f60d4c34d363517fe528679e6ff3d059b7861099
> Author: Matthew Brost <matthew.brost@intel.com>
> 
> drm/xe: Add ULLS migration job support to GuC submission
> 
> This commit adds ULLS migration job support to the GuC submission backend.
> It modifies the migration queue job limits and introduces direct hardware
> engine tail writes for subsequent ULLS jobs.
> 
> Link: https://patch.msgid.link/20260228013501.106680-24-matthew.brost@intel.com
> 
> > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
> > index dcb4b8a4f3b78..1578d80b01b82 100644
> > --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> > @@ -1207,6 +1207,11 @@ static void submit_exec_queue(struct xe_exec_queue *q, struct xe_sched_job *job)
> >  	if (exec_queue_suspended(q))
> >  		return;
> >  
> > +	if (job->is_ulls && !job->is_ulls_first) {
> > +		xe_hw_engine_write_ring_tail(q->hwe, lrc->ring.tail);
> 
> [Severity: Critical]
> Can this direct MMIO write to the engine's RING_TAIL cause hardware state
> corruption if the ULLS context is preempted or evicted?
> 

The GuC context can't ever be evicted or preempted as the migrate queue
completely owns the engine state which is way this is safe.

It is questionable if we should wait on the first ULLS job signaling so
we know the queue is on the hardware but I've yet to see any failures in
my testing. This is something to watch out for though - if we get a
random kernel queue hang, we should adjust to wait until first ULLS job
signals.

It we ever use multiple queues on the paging engine, we will also have
to use fences + ordering to ensure either all ULLS jobs are complete or
all non-ULLS jobs are complete before before jobs reach run_job().

Matt

> The driver bypasses the GuC submission interface (H2G) for ULLS jobs and
> directly writes to the engine's MMIO RING_TAIL register. If the ULLS
> migration context is not actively resident on the hardware engine at the exact
> moment of the write, the write will advance the ring tail of whichever context
> is currently resident on that engine (e.g., VM bind contexts sharing the same
> USM engine).
> 
> Since the GuC scheduler fundamentally owns engine context switching, it can
> preempt or evict the ULLS context for internal tasks or schedule other queues
> that explicitly share the USM engine. If the CPU submits a ULLS job while the
> ULLS context is swapped out, would the direct MMIO tail write hit the
> currently running context instead?
> 
> > +		xe_lrc_set_ulls_semaphore(lrc, xe_sched_job_lrc_seqno(job));
> > +	}
> > +
> >  	if (!exec_queue_enabled(q)) {
> >  		action[len++] = XE_GUC_ACTION_SCHED_CONTEXT_MODE_SET;
> >  		action[len++] = q->guc->id;
> 
> [ ... ]
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260903235842.3401722-1-matthew.brost@intel.com?part=22