Re: [PATCH v8 20/24] drm/xe: Add ULLS migration job support to ring ops

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: prefetch race in ULLS migration ring tail update
--

commit 3d64140e37d6f99c19fcb4ef3b9b272bf7535ed9
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Add ULLS migration job support to ring ops

This commit adds preamble and postamble generation for ULLS migrations jobs.
The postamble advances the ring tail from within the ring itself to avoid
CPU overhead when submitting the next job.

> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c
> index 46ab1f0f35648..9f462bfecb831 100644
> --- a/drivers/gpu/drm/xe/xe_ring_ops.c
> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c
[ ... ]
> +/* Publish the next job's tail, then park the engine on its semaphore */
> +static int emit_ulls_postamble(struct xe_gt *gt, struct xe_lrc *lrc, u32 *dw,
> +			       int i, u32 seqno, u32 head)
> +{
> +	i = emit_ulls_ring_tail(gt, lrc, dw, i, head);
> +
> +	dw[i++] = MI_SEMAPHORE_WAIT |
> +		MI_SEMW_GGTT |
> +		MI_SEMW_POLL |
> +		MI_SEMW_COMPARE(SAD_EQ_SDD);

[Severity: High]
Does advancing the ring tail via LRI before stalling the engine on the
MI_SEMAPHORE_WAIT create a prefetch race?

When the command streamer's fetch unit sees the updated tail before the
semaphore stall, it may prefetch the unwritten memory for the next job into
the L1I cache.

When a page fault occurs later, the CPU writes the new job and signals the
semaphore. Since the Intel GPU L1I cache is not coherent with CPU writes and
isn't invalidated after the CPU writes the new commands, could the execution
unit consume the stale prefetched commands instead of the intended migration
job?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925201526.1355279-1-matthew.brost@intel.com?part=20