GUC CTB BLOB(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

🌸 GuC CTB Blob 🌸

okay so bestie, this is the GuC CTB Blob page from the Kernel API Manual (section 9), and it’s lowkey iconic. The whole idea: we allocate a single blob that holds both the CTB descriptors and the buffers. one blob, two jobs, main character energy fr fr. πŸ’…βœ¨

Here’s the layout β€” and yes, it’s giving β€œcursed ASCII art,” but we keep it exactly as the page gives it. No edits, no cleanup, we respect the chaos. πŸ’€

       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
       β”‚     offset   contents   size β”‚
       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
       +========+===============================================+======+ |
       0x0000 | H2G CTB Descriptor (send)                     |      |

       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
       β”‚     0x0800   G2H CTB Descriptor (g2h)        β”‚
       β”‚     0x1000   H2G CT Buffer (send)       n*4K β”‚
       β”‚                                              β”‚
       β”‚     0x1000   G2H CT Buffer (g2h)        m*4K β”‚
       β”‚     + n*4K                                   β”‚
       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Quick rule, bestie: the size of each CT Buffer must be a multiple of 4K β€” no exceptions. ✨

We don’t expect too many messages in flight at any one time, unless we’re using the GuC submission. In that case, each request needs a minimum of 2 dwords, which gives us a maximum of 256 queue'd requests. Hopefully that’s enough space to avoid backpressure on the driver. We make the receive buffer bigger (relative to the send buffer) so a G2H response CTB always has a landing spot. πŸ›¬πŸ’–

On top of submissions, the G2H buffer also has to hold enough room for recoverable page fault notifications. The number of page faults is interrupt driven and can be as much as the number of compute resources available. However, most of the actual work for these happens in a separate page fault worker thread. So we only need to make sure the queue has enough space to handle all of the submissions and responses, plus an extra buffer for incoming page faults. 🫢


✨ SEE ALSO ✨


That’s the whole page, bestie. Signing off from ./drivers/gpu/drm/xe, dated October 2026, for GuC CTB Blob(9) β€” mwah πŸ’‹πŸŽ€

πŸ“¦ where this page comes from