linux-stable.git/drivers/gpu/drm/xe/xe_exec_queue.c, branch v6.18

drm/xe: Enforce correct user fence signaling order using

2025-11-07T11:55:19+00:00

Prevent application hangs caused by out-of-order fence signaling when
user fences are attached. Use drm_syncobj (via dma-fence-chain) to
guarantee that each user fence signals in order, regardless of the
signaling order of the attached fences. Ensure user fence writebacks to
user space occur in the correct sequence.

v7:
 - Skip drm_syncbj create of error (CI)

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Brost 
Reviewed-by: Thomas Hellström 
Link: https://patch.msgid.link/20251031234050.3043507-2-matthew.brost@intel.com
(cherry picked from commit adda4e855ab6409a3edaa585293f1f2069ab7299)
Signed-off-by: Lucas De Marchi

drm/xe: Fix error handling if PXP fails to start

2025-09-16T22:54:28+00:00

Since the PXP start comes after __xe_exec_queue_init() has completed,
we need to cleanup what was done in that function in case of a PXP
start error.
__xe_exec_queue_init calls the submission backend init() function,
so we need to introduce an opposite for that. Unfortunately, while
we already have a fini() function pointer, it performs other
operations in addition to cleaning up what was done by the init().
Therefore, for clarity, the existing fini() has been renamed to
destroy(), while a new fini() has been added to only clean up what was
done by the init(), with the latter being called by the former (via
xe_exec_queue_fini).

Fixes: 72d479601d67 ("drm/xe/pxp/uapi: Add userspace and LRC support for PXP-using queues")
Signed-off-by: Daniele Ceraolo Spurio 
Cc: John Harrison 
Cc: Matthew Brost 
Reviewed-by: John Harrison 
Signed-off-by: John Harrison 
Link: https://lore.kernel.org/r/20250909221240.3711023-3-daniele.ceraolospurio@intel.com

drm/xe: s/tlb_invalidation/tlb_inval

2025-08-27T18:49:00+00:00

tlb_invalidation is a bit verbose leading to ugly wraps in the code,
shorten to tlb_inval.

Signed-off-by: Stuart Summers 
Reviewed-by: Stuart Summers 
Signed-off-by: Matthew Brost 
Link: https://lore.kernel.org/r/20250826182911.392550-4-stuart.summers@intel.com

drm/xe/vf: Refactor CCS save/restore to use default migration context

2025-08-08T17:29:37+00:00

Previously, CCS save/restore operations created separate migration
contexts with new VM memory allocations, resulting in significant
overhead.

This commit eliminates redundant context creation reusing the default
migration context by registering new execution queues for CCS save and
restore on the existing migrate VM.

Signed-off-by: Satyanarayana K V P 
Suggested-by: Matthew Brost 
Cc: Michal Wajdeczko 
Cc: John Harrison 
Reviewed-by: Matthew Brost 
Reviewed-by: Stuart Summers 
Signed-off-by: Matthew Brost 
Link: https://lore.kernel.org/r/20250808073628.32745-2-satyanarayana.k.v.p@intel.com

drm/xe/vf: Refresh utilization buffer during migration recovery

2025-08-04T14:47:07+00:00

The WA buffer we use to capture context utilization contains GGTT
references. This means its instructions have to be either fixed or
re-emitted during VF post-migration recovery.

This patch adds re-emitting content of the utilization WA BB during
the recovery.

The way we write to vram requires scratch buffer to be used before
the whole block is memcopied. We are re-using a scratch buffer
introduced in earlier part of the recovery. This is not a performance
optimization, but a necessity to avoid creating dependencies between
locks.

v2: Notable rebase after "Prepare WA BB setup for more users" patch
v3: Added error propagation

Signed-off-by: Tomasz Lis 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Reviewed-by: Michal Winiarski 
Link: https://lore.kernel.org/r/20250802031045.1127138-8-tomasz.lis@intel.com
Signed-off-by: Michał Winiarski

drm/xe/vf: Post migration, repopulate ring area for pending request

2025-08-04T14:46:56+00:00

The commands within ring area allocated for a request may contain
references to GGTT. These references require update after VF
migration, in order to continue any preempted LRCs, or jobs which
were emitted to the ring but not sent to GuC yet.

This change calls the emit function again for all such jobs,
as part of post-migration recovery.

v2: Moved few functions to better files
v3: Take job_list_lock
v4: Rephrased comments

Signed-off-by: Tomasz Lis 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Reviewed-by: Michal Winiarski 
Cc: Jonathan Cavitt 
Reviewed-by: Jonathan Cavitt 
Link: https://lore.kernel.org/r/20250802031045.1127138-7-tomasz.lis@intel.com
Signed-off-by: Michał Winiarski

drm/xe/vf: Rebase MEMIRQ structures for all contexts after migration

2025-08-04T14:46:52+00:00

All contexts require an update of state data, as the data includes
GGTT references to memirq-related buffers.

Default contexts need these references updated as well, because they
are not refreshed when a new context is created from them.

The way we write to vram requires scratch buffer to be used
before the whole block is memcopied. Since using kalloc() within
specific recovery functions would lead to unintended relations
between locks, we are allocating the buffer earlier, before
any locks are taken. The same buffer will be used for other steps
of the recovery.

v2: Update addresses by xe_lrc_write_ctx_reg() rather than
  set_memory_based_intr()
v3: Renamed parameter, reordered parameters in some functs
v4: Check if have MEMIRQ, move `xe_gt*` funct to proper file
v5: Revert back to requiring scratch buffer, but allocate it
  earlier this time

Signed-off-by: Tomasz Lis 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Acked-by: Satyanarayana K V P 
Reviewed-by: Michal Winiarski 
Link: https://lore.kernel.org/r/20250802031045.1127138-6-tomasz.lis@intel.com
Signed-off-by: Michał Winiarski

drm/xe/vf: Rebase HWSP of all contexts after migration

2025-08-04T14:46:47+00:00

All contexts require an update due to GGTT range shift, as that
affects their HWSP.

The HW status page of a context contains GGTT references, which
need to be shifted to a new range (or re-computed using the
previously updated vma nodes). The references include ring start
address and indirect state address.

v2: move some functions to better matched files
v3: Add missing kerneldocs
v4: Style fix

Signed-off-by: Tomasz Lis 
Cc: Michal Wajdeczko 
Cc: Michal Winiarski 
Acked-by: Satyanarayana K V P 
Reviewed-by: Michal Winiarski 
Link: https://lore.kernel.org/r/20250802031045.1127138-5-tomasz.lis@intel.com
Signed-off-by: Michał Winiarski

drm/xe: Add dependency scheduler for GT TLB invalidations to bind queues

2025-07-25T01:25:59+00:00

Add a generic dependency scheduler for GT TLB invalidations, used to
schedule jobs that issue GT TLB invalidations to bind queues.

v2:
 - Use shared GT TLB invalidation queue for dep scheduler
 - Break allocation of dep scheduler into its own function
 - Add define for max number tlb invalidations
 - Skip media if not present

Suggested-by: Thomas Hellström 
Signed-off-by: Matthew Brost 
Reviewed-by: Stuart Summers 
Link: https://lore.kernel.org/r/20250724191216.4076566-5-matthew.brost@intel.com

drm/xe: Don't compare GT ID to GT count when determining valid GTs

2025-07-02T23:08:54+00:00

On current platforms with multiple GTs, all of the GT IDs are
consecutive; as a result we know that the GT IDs range from 0 to
gt_count-1 and can determine if a GT ID is valid by comparing against
the count.  The consecutive nature of GT IDs may not hold true on future
platforms if/when we have platforms that are both multi-tile and have
multiple GTs within each tile.  Once such platforms exist, it's quite
possible that we could wind up with something like a GT list composed of
IDs 0, 2, and 3 with no GT 1 (which would be a 2-tile platform with
media only on the second tile).

To future-proof the code we should stop comparing against the GT count
to determine whether a GT ID is valid or not.  Instead we should do an
actual lookup of the ID to determine whether the GT exists.  This also
means that our GT loop macro should not end at the GT count, but should
rather examine the entire space up to (# of tiles) * (max GT per tile)
to ensure it doesn't stop prematurely.

Reviewed-by: Jonathan Cavitt 
Link: https://lore.kernel.org/r/20250701201320.2514369-15-matthew.d.roper@intel.com
Signed-off-by: Matt Roper