linux.git/drivers/gpu/drm/xe/xe_exec_queue.h, branch v7.1-rc7

Revert "drm/xe: Skip exec queue schedule toggle if queue is idle during suspend"

2026-06-04T13:03:57+00:00

This reverts commit 8533051ce92015e9cc6f75e0d52119b9d91610b6.

The idle-skip optimization bypasses GuC suspend, so the GPU may not
perform the context switch that flushes TLB entries for invalidated
userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB
invalidation and page faults during userptr invalidation tests.

Restore unconditional schedule toggling on suspend so the context-switch
TLB flush is always performed.

This optimization will be reintroduced with a fix that does not skip
suspend in LR/preempt-fence VM mode.

Fixes: 8533051ce920 ("drm/xe: Skip exec queue schedule toggle if queue is idle during suspend")
Cc: stable@vger.kernel.org # v7.0+
Suggested-by: Thomas Hellstrom 
Signed-off-by: Tangudu Tilak Tirumalesh 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Daniele Ceraolo Spurio 
Link: https://patch.msgid.link/20260603065217.3131066-2-tilak.tirumalesh.tangudu@intel.com
(cherry picked from commit 6a1e7934d9a6cf46aecae00a99c2603d1295e170)
Signed-off-by: Rodrigo Vivi

drm/xe: Wrappers for setting and getting LRC references

2026-02-27T17:02:04+00:00

There is a small but non-zero chance that VF post migration fixups
are running on an exec queue during teardown. The chances are
decreased by starting the teardown by releasing guc_id, but remain
non-zero. On the other hand the sync between fixups and EQ creation
(wait_valid_ggtt) drastically increases the chance for such parallel
teardown if queue creation error path is entered (err_lrc label).

The exec queue itself is not going to cause an issue, but LRCs have
a small chance of getting freed during the fixups.

Creating a setter and a getter makes it easier to protect the fixup
operations with a lock. For other driver activities, the original
access method (without any protection) can still be used.

v2: Separate lock, only for LRCs. Kerneldoc fixes. Subject tag fix.

Signed-off-by: Tomasz Lis 
Reviewed-by: Matthew Brost 
Signed-off-by: Michal Wajdeczko 
Link: https://patch.msgid.link/20260226212701.2937065-3-tomasz.lis@intel.com

drm/xe/uapi: disallow bind queue sharing

2026-01-21T10:07:18+00:00

Currently this is very broken if someone attempts to create a bind
queue and share it across multiple VMs. For example currently we assume
it is safe to acquire the user VM lock to protect some of the bind queue
state, but if allow sharing the bind queue with multiple VMs then this
quickly breaks down.

To fix this reject using a bind queue with any VM that is not the same
VM that was originally passed when creating the bind queue. This a uAPI
change, however this was more of an oversight on kernel side that we
didn't reject this, and expectation is that userspace shouldn't be using
bind queues in this way, so in theory this change should go unnoticed.

Based on a patch from Matt Brost.

v2 (Matt B):
  - Hold the vm lock over queue create, to ensure it can't be closed as
    we attach the user_vm to the queue.
  - Make sure we actually check for NULL user_vm in destruction path.
v3:
  - Fix error path handling.

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Reported-by: Thomas Hellström 
Signed-off-by: Matthew Auld 
Cc: José Roberto de Souza 
Cc: Matthew Brost 
Cc: Michal Mrozek 
Cc: Carl Zhang 
Cc:  # v6.8+
Acked-by: José Roberto de Souza 
Reviewed-by: Matthew Brost 
Reviewed-by: Arvind Yadav 
Acked-by: Michal Mrozek 
Link: https://patch.msgid.link/20260120110609.77958-3-matthew.auld@intel.com

Revert "drm/xe/multi_queue: Support active group after primary is destroyed"

2026-01-06T19:13:54+00:00

This reverts commit 3131a43ecb346ae3b5287ee195779fc38c6fcd11.

There is no must have requirement for this feature from Compute UMD.

Signed-off-by: Niranjana Vishwanathapura 
Reviewed-by: Matthew Brost 
Link: https://patch.msgid.link/20260106191051.2866538-5-niranjana.vishwanathapura@intel.com

drm/xe: Skip exec queue schedule toggle if queue is idle during suspend

2025-12-15T21:54:18+00:00

If an exec queue is idle, there is no need to issue a schedule disable
to the GuC when suspending the queue’s execution. Opportunistically skip
this step if the queue is idle and not a parallel queue. Parallel queues
must have their scheduling state flipped in the GuC due to limitations
in how submission is implemented in run_job().

Also if all pagefault queues can skip the schedule disable during a
switch to dma-fence mode, do not schedule a resume for the pagefault
queues after the next submission.

v2:
 - Don't touch the LRC tail is queue is suspended but enabled in run_job
   (CI)

Signed-off-by: Matthew Brost 
Reviewed-by: Thomas Hellström 
Link: https://patch.msgid.link/20251212182847.1683222-5-matthew.brost@intel.com

drm/xe/multi_queue: Support active group after primary is destroyed

2025-12-12T03:22:05+00:00

Add support to keep the group active after the primary queue is
destroyed. Instead of killing the primary queue during exec_queue
destroy ioctl, kill it when all the secondary queues of the group
are killed.

Signed-off-by: Niranjana Vishwanathapura 
Reviewed-by: Matthew Brost 
Link: https://patch.msgid.link/20251211010249.1647839-34-niranjana.vishwanathapura@intel.com

drm/xe/multi_queue: Add exec_queue set_property ioctl support

2025-12-12T03:21:04+00:00

This patch adds support for exec_queue set_property ioctl.
It is derived from the original work which is part of
https://patchwork.freedesktop.org/series/112188/

Currently only DRM_XE_EXEC_QUEUE_SET_PROPERTY_MULTI_QUEUE_PRIORITY
property can be dynamically set.

v2: Check for and update kernel-doc which property this ioctl
    supports (Matt Brost)

Signed-off-by: Matthew Brost 
Signed-off-by: Pallavi Mishra 
Signed-off-by: Niranjana Vishwanathapura 
Reviewed-by: Matthew Brost 
Link: https://patch.msgid.link/20251211010249.1647839-25-niranjana.vishwanathapura@intel.com

drm/xe/multi_queue: Add user interface for multi queue support

2025-12-12T03:20:37+00:00

Multi Queue is a new mode of execution supported by the compute and
blitter copy command streamers (CCS and BCS, respectively). It is an
enhancement of the existing hardware architecture and leverages the
same submission model. It enables support for efficient, parallel
execution of multiple queues within a single context. All the queues
of a group must use the same address space (VM).

The new DRM_XE_EXEC_QUEUE_SET_PROPERTY_MULTI_QUEUE execution queue
property supports creating a multi queue group and adding queues to
a queue group. All queues of a multi queue group share the same
context.

A exec queue create ioctl call with above property specified with value
DRM_XE_SUPER_GROUP_CREATE will create a new multi queue group with the
queue being created as the primary queue (aka q0) of the group. To add
secondary queues to the group, they need to be created with the above
property with id of the primary queue as the value. The properties of
the primary queue (like priority, timeslice) applies to the whole group.
So, these properties can't be set for secondary queues of a group.

Once destroyed, the secondary queues of a multi queue group can't be
replaced. However, they can be dynamically added to the group up to a
total of 64 queues per group. Once the primary queue is destroyed,
secondary queues can't be added to the queue group.

v2: Remove group->lock, fix xe_exec_queue_group_add()/delete()
function semantics, add additional comments, remove unused
group->list_lock, add XE_BO_FLAG_GGTT_INVALIDATE for cgp bo,
Assert LRC is valid, update uapi kernel doc.
(Matt Brost)
v3: Use XE_BO_FLAG_PINNED_LATE_RESTORE/USER_VRAM/GGTT_INVALIDATE
flags for cgp bo (Matt)
v4: Ensure queue is not a vm_bind queue
uapi change due to rebase

Signed-off-by: Stuart Summers
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Brost
Link: https://patch.msgid.link/20251211010249.1647839-21-niranjana.vishwanathapura@intel.com

drm/xe: Remove last fence dependency check from binds and execs

2025-11-04T16:21:18+00:00

Eliminate redundant last fence dependency checks in exec and bind jobs,
as they are now equivalent to xe_exec_queue_is_idle. Simplify the code
by removing this dead logic.

Signed-off-by: Matthew Brost 
Reviewed-by: Thomas Hellström 
Link: https://patch.msgid.link/20251031234050.3043507-7-matthew.brost@intel.com

drm/xe: Attach last fence to TLB invalidation job queues

2025-11-04T16:20:57+00:00

Add support for attaching the last fence to TLB invalidation job queues
to address serialization issues during bursts of unbind jobs. Ensure
that user fence signaling for a bind job reflects both the bind job
itself and the last fences of all related TLB invalidations. Maintain
submission order based solely on the state of the bind and TLB
invalidation queues.

Introduce support functions for last fence attachment to TLB
invalidation queues.

v3:
 - Fix assert in xe_exec_queue_tlb_inval_last_fence_set (CI)
 - Ensure migrate lock held for migrate queues (Testing)
v5:
 - Style nits (Thomas)
 - Rewrite commit message (Thomas)

Signed-off-by: Matthew Brost 
Reviewed-by: Thomas Hellström 
Link: https://patch.msgid.link/20251031234050.3043507-3-matthew.brost@intel.com