xe_guc_ct_send(9)

💖 xe_guc_ct_send — NAME (yes bestie, it's giving "who am I") 💖

okay so xe_guc_ct_send — it sends an HXG message to the GuC over CT. that's the whole vibe, that's the whole job. ✨

this page lives in the Kernel API Manual, and honestly? iconic of it.

---

🎀 SYNOPSIS 🎀

int xe_guc_ct_send (struct xe_guc_ct *ct , const u32 *action , u32 len ,
u32 g2h_len , u32 num_g2h );

like, that's the signature. no notes. 💅

---

🌸 ARGUMENTS 🌸

• ct — the xe_guc_ct. your ct. the ct in question. 🫶
• action — dword array with the HXG message. can't be NULL, fr fr, do not pass NULL here, that's not the move.
• len — length of the HXG message in dwords. can't be 0 either. it's giving "please actually send something".
• g2h_len — G2H response space to reserve, in dwords. or 0. (0 is allowed here, unlike len, slay for flexibility ✨)
• num_g2h — number of G2H messages expected. or 0. yes, also allowed to be 0. ⭐

---

🦋 DESCRIPTION 🦋

so the return codes from the non-blocking send helpers are — and bestie, listen, this is the part the professor will test you on 😭 —

• -ENOTRECOVERABLE — the xe device is wedged. like, fully not okay. Stop submitting new GuC work; the request cannot make progress until the device is recovered. it's giving "do not poke the wedged device, she needs to recover". 💀
• -EPIPE — the H2G CTB is marked broken. The channel stays unusable until the CT is restarted, which clears the broken flag. so no, you can't just vibes your way past this. restart = the fix. 🔥
• -ENODEV — the CT channel is disabled, and messages are not expected in this state. Don't retry until it is enabled again. that's it, that's the rule, respect the boundary 🚫
• -ECANCELED — the CT channel is stopped or a GT recovery is pending; the message was dropped. Often benign, lowkey. Cancel-tolerant callers (e.g. TLB invalidations, GuC submission) rely on the stop/start flow to recover; others should retry once the CT is re-enabled or the reset/recovery completes. so like — iykyk whether you're cancel-tolerant or not. 🧚
• -EDEADLK — no CTB room AND the wait for space timed out. and the send helpers have already requested an async GT reset before returning this error. so the reset is already in motion, don't @ me. 🙈

also, -ENOMEM may be returned if an internal allocation fails; the blocking xe_guc_ct_send_recv path retries that allocation. -EBUSY and -EAGAIN are internal flow-control results handled by the send helpers — so they're not really your problem, they get handled. 😌

---

👑 RETURN 👑

0 on success, or a negative error code on failure. that's the whole spectrum. zero means she ate. negative means read this page again. 🌈

---

⭐ SEE ALSO ⭐

go read these next bestie, they're all in the same friend group:

Kernel file ./drivers/gpu/drm/xe/xe_guc_ct.c GuC CTB Blob(9), xe_guc_ct_queue_proc_time_jiffies(9), xe_guc_ct_init_post_hwconfig(9), xe_guc_ct_restart(9), xe_guc_ct_enable(9), xe_guc_ct_disable(9), xe_guc_ct_flush_and_stop(9), xe_guc_ct_stop(9), xe_guc_ct_runtime_suspend(9), xe_guc_ct_runtime_resume(9), xe_guc_ct_send_recv(9), xe_guc_ct_fast_path(9), xe_guc_ct_snapshot_capture(9), xe_guc_ct_snapshot_print(9), xe_guc_ct_snapshot_free(9), xe_guc_ct_print(9)

---

and that's the page! 🎀 sourced from ./drivers/gpu/drm/xe, dated October 2026, and this little manual is literally called xe_guc_ct_send(9) — go forth and send your HXG messages responsibly, bestie 💜✨