STRUCT XE_EXEC_QUEUE(9)
π struct xe_exec_queue β Kernel API Manual, bestie edition π
okay so like. this is the Kernel API Manual page for struct xe_exec_queue, and honestly? it's giving main character struct. it's a whole execution queue and it has so many fields. grab a snack, we're going through all of them π
πΈ NAME πΈ
struct xe_exec_queue β Execution queue. that's the vibe. that's the whole assignment. β¨
π SYNOPSIS π
bestie. look at this. it's long but it's iconic. i'm putting it down verbatim because every single line matters, no cap π₯
struct xe_exec_queue {
struct xe_file *xef;
struct xe_gt *gt;
struct xe_hw_engine *hwe;
struct kref refcount;
struct xe_vm *vm;
struct xe_vm *user_vm;
enum xe_engine_class class;
u32 logical_mask;
char name[MAX_FENCE_NAME_LEN];
u16 width;
u16 msix_vec;
struct xe_hw_fence_irq *fence_irq;
struct dma_fence *last_fence;
#define EXEC_QUEUE_FLAG_KERNEL BIT(0);
#define EXEC_QUEUE_FLAG_PERMANENT BIT(1);
#define EXEC_QUEUE_FLAG_VM BIT(2);
#define EXEC_QUEUE_FLAG_BIND_ENGINE_CHILD BIT(3);
#define EXEC_QUEUE_FLAG_HIGH_PRIORITY BIT(4);
#define EXEC_QUEUE_FLAG_LOW_LATENCY BIT(5);
#define EXEC_QUEUE_FLAG_MIGRATE BIT(6);
#define EXEC_QUEUE_FLAG_DISABLE_STATE_CACHE_PERF_FIX BIT(7);
unsigned long flags;
union {
struct list_head multi_gt_list;
struct list_head multi_gt_link;
};
union {
struct xe_execlist_exec_queue *execlist;
struct xe_guc_exec_queue *guc;
};
struct {
struct xe_exec_queue_group *group;
struct list_head link;
enum xe_multi_queue_priority priority;
spinlock_t lock;
u8 pos;
u8 valid:1;
u8 is_primary:1;
} multi_queue;
struct {
u32 timeslice_us;
u32 preempt_timeout_us;
u32 job_timeout_ms;
enum xe_exec_queue_priority priority;
} sched_props;
struct {
struct dma_fence *pfence;
u64 context;
u32 seqno;
struct list_head link;
bool suspended;
} lr;
#define XE_EXEC_QUEUE_TLB_INVAL_PRIMARY_GT 0;
#define XE_EXEC_QUEUE_TLB_INVAL_MEDIA_GT 1;
#define XE_EXEC_QUEUE_TLB_INVAL_COUNT
(XE_EXEC_QUEUE_TLB_INVAL_MEDIA_GT + 1);
struct {
struct xe_dep_scheduler *dep_scheduler;
struct dma_fence *last_fence;
} tlb_inval[XE_EXEC_QUEUE_TLB_INVAL_COUNT];
struct list_head vm_exec_queue_link;
struct {
u8 type;
struct list_head link;
} pxp;
struct drm_syncobj *ufence_syncobj;
u64 ufence_timeline_value;
void *replay_state;
const struct xe_exec_queue_ops *ops;
const struct xe_ring_ops *ring_ops;
struct drm_sched_entity *entity;
#define XE_MAX_JOB_COUNT_PER_EXEC_QUEUE 1000;
atomic_t job_cnt;
u64 tlb_flush_seqno;
struct list_head hw_engine_group_link;
spinlock_t lrc_lookup_lock;
struct xe_lrc *lrc[];
};
π¦ Members π¦
okay now the fun part β every single member, explained. i'm obsessed with how much detail is in here. let's go π«Ά
xefβ back pointer to thexefile if this is a user-created exec queue. like a little "return to sender" tag πgtβ the GT structure this exec queue can submit tohweβ a hardware engine of the same class. it may (physical engine) or may not (virtual engine) be where the job's actual engine ends up running. should never really be used for submissions. ngl, it's decorative-adjacent. don't submit through it πrefcountβ ref count of this exec queue. keep it balanced or things get spicyvmβ the VM (address space) for this exec queueuser_vmβ the User VM (address space) for this exec queue β bind queues only πclassβ class of this exec queuelogical_maskβ logical mask of where a job submitted to this exec queue can runnameβ name of this exec queue (yes it has a name, it's a whole person)widthβ width (number of BBs submitted per exec) of this exec queuemsix_vecβ MSI-X vector (for platforms that support it)fence_irqβ fence IRQ used to signal job completion βlast_fenceβ last fence on the exec queue. protected byvm->lockin write mode if it's a bind exec queue, and protected by the dma resv lock if it's a non-bind exec queue πflagsβ flags for this exec queue. should be statically set up aside from the ban bit{unnamed_union}β anonymous. mysterious. no name. we love a mystery π΅οΈmulti_gt_listβ list head for VM bind engines if multi-GTmulti_gt_linkβ link for VM bind engines if multi-GT
{unnamed_union}β anonymous (again! two mysterious unions, it's giving twins π―)execlistβ execlist backend specific state for the exec queuegucβ GuC backend specific state for the exec queue
multi_queueβ multi queue informationmulti_queue.groupβ queue group informationmulti_queue.linkβ link into the group's secondary queues listmulti_queue.priorityβ queue priority within the multi-queue group. it's protected bymulti_queue.lockmulti_queue.lockβ lock for protecting certain membersmulti_queue.posβ position of the queue within the multi-queue groupmulti_queue.validβ the queue belongs to a multi queue groupmulti_queue.is_primaryβ is this the primary queue (Q0) of the group? π
sched_propsβ scheduling propertiessched_props.timeslice_usβ timeslice period in micro-secondssched_props.preempt_timeout_usβ preemption timeout in micro-secondssched_props.job_timeout_msβ job timeout in millisecondssched_props.priorityβ priority of this exec queue
lrβ long-running exec queue statelr.pfenceβ preemption fencelr.contextβ preemption fence contextlr.seqnoβ preemption fence seqnolr.linkβ link into the VM's list of exec queueslr.suspendedβ tracks whether the consumer-issued suspend succeeded and a matching resume is still owed. suspend can fail (e.g. killed/banned/wedged), leaving the queue un-suspended, so consumers must only resume queues that were actually suspended. set by the suspend caller on success and cleared by the resume caller. a queue is only ever suspended by a single consumer at a time (preempt-fence mode and hw engine group fault mode are mutually exclusive), so a single flag is sufficient. genuinely very thoughtful of them, tbh π§
tlb_invalβ TLB invalidations exec queue statetlb_inval.dep_schedulerβ the TLB invalidation dependency schedulertlb_inval.last_fenceβ last fence for tlb invalidation, protected byvm->lockin write mode
vm_exec_queue_linkβ link to track the exec queue within a VM's list of exec queuespxpβ PXP info trackingpxp.typeβ PXP session type used by this queuepxp.linkβ link into the list of PXP exec queues
ufence_syncobjβ user fence syncobjufence_timeline_valueβ user fence timeline valuereplay_stateβ GPU hang replay state π (hope you never need it)opsβ submission backend exec queue operationsring_opsβ ring operations for this exec queueentityβ DRM sched entity for this exec queue (1 to 1 relationship, they're exclusive π)job_cntβ number of drm jobs in this exec queuetlb_flush_seqnoβ the seqno of the last rebind tlb flush performed. protected by the vm's resv. unused ifvm == NULLhw_engine_group_linkβ link into exec queues in the same hw engine grouplrc_lookup_lockβ lock for protectinglrcarray access. only used when running in parallel to queue creation is possiblelrcβ logical ring context for this exec queue π
π Description π
contains all state necessary for submissions. can either be a user object or a kernel object. that's the whole point, and it ate. periodt.
β SEE ALSO β
- Kernel file
./drivers/gpu/drm/xe/xe_exec_queue_types.h - enum
xe_multi_queue_priority(9) struct xe_exec_queue_group(9)struct xe_exec_queue_ops(9)
go read those too, iykyk π
and that's the page, bestie! π«Ά this came from ./drivers/gpu/drm/xe, dated October 2026, and it's the struct xe_exec_queue(9) manual page. go forth and submit responsibly β¨ππ¦
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms