Re: [PATCH v7 19/24] drm/xe: Add ULLS migration job support to migration layer

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: Missing ULLS_EXIT in teardown leaves hardware parked on freed memory
--

commit 81f7dc64bc0d604133ac8c3a1f3ec0fd0a9dd8a1
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Add ULLS migration job support to migration layer

Add function to enter ULLS mode for migration job and delayed worker to
exit (power saving). ULLS mode expected to entered upon page fault or
SVM prefetch. ULLS mode exit delay is currently set to 5ms.

> diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
> index 471ae5741836e..d7d13a25cdb91 100644
> --- a/drivers/gpu/drm/xe/xe_migrate.c
> +++ b/drivers/gpu/drm/xe/xe_migrate.c
[ ... ]
> @@ -95,9 +105,30 @@ struct xe_migrate {
>   */
>  #define MAX_PTE_PER_SDI 0x1FEU
>  
> +static bool xe_migrate_ulls_enabled(struct xe_migrate *m)
> +{
> +	lockdep_assert_held(&m->job_mutex);
> +	return m->ulls.enabled;
> +}
> +
> +static void xe_migrate_ulls_toggle_enable(struct xe_migrate *m, bool enabled)
> +{
> +	lockdep_assert_held(&m->job_mutex);
> +	m->ulls.enabled = enabled;
> +}
> +
>  static void xe_migrate_fini(void *arg)
>  {
>  	struct xe_migrate *m = arg;
> +	struct xe_device *xe = tile_to_xe(m->tile);
> +
> +	disable_delayed_work_sync(&m->ulls.exit_work);
> +	scoped_guard(mutex, &m->job_mutex) {
> +		if (xe_migrate_ulls_enabled(m)) {
> +			xe_pm_runtime_put(xe);
> +			xe_migrate_ulls_toggle_enable(m, false);

[Severity: High]
Does this missing ULLS_EXIT in the teardown sequence leave the hardware
parked on freed memory?

During driver unbind or probe failure in xe_migrate_fini(), if ULLS mode is
currently active (for example, within 5ms of a recent migration job), the
reserved hardware engine is actively spinning in a MI_SEMAPHORE_WAIT loop.

This teardown path cancels exit_work and clears the ULLS enabled flag, but
fails to push the ULLS_EXIT job or explicitly kill the queue. It then
proceeds to call xe_exec_queue_put() and free the page tables. Because
xe_exec_queue_kill() is never called, GuC is never instructed to preempt
and deregister the context.

Can this regression leave the hardware engine actively executing from the
ring buffer memory while the host frees it, potentially leading to IOMMU CAT
faults, GPU hangs, or host memory corruption?

> +		}
> +	}
>  
>  	xe_vm_lock(m->q->vm, false);
>  	xe_bo_unpin(m->pt_bo);

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