STRUCT MSM_CONTEXT(9)

💅 struct msm_context(9) — Kernel API Manual, but make it make sense

okay so bestie, listen 💖 this page is literally about struct msm_context — the per-drm_file context — like, one per open file, that's her whole gig. She's the main character of your process's GPU life, no cap. 👑

---

✨ NAME ✨

struct msm_context — per-drm_file context 🎀

---

🌸 SYNOPSIS 🌸

struct msm_context {
    struct rw_semaphore ctxlock;
    struct list_head submitqueues;
    int queueid;
    bool closed;
    bool userspace_managed_vm;
    struct drm_gpuvm *vm;
    struct kref ref;
    int seqno;
    int sysprof;
    char *comm;
    char *cmdline;
    uint64_t elapsed_ns;
    uint64_t cycles;
    struct drm_sched_entity *entities[NR_SCHED_PRIORITIES * MSM_GPU_MAX_RINGS];
    atomic64_t ctx_mem;
    struct msm_perfcntr_context_state *perfctx;
};

---

🦋 Members 🦋

okay this is the part where we go member by member, and honestly? each one ate. 💅

• ctxlock — she's the bouncer 🫶 she synchronizes access to submitqueues list, etc. Ever heard of it bestie, she's literally the lock.
• submitqueues — the guest list 🎀 list of msm_gpu_submitqueue created by userspace — everything userspace has spun up lives right here.
• queueid — Counter incremented each time a submitqueue is created, and it's used to assign msm_gpu_submitqueue.id. So yes, she's the little ticker handing out the numbers 🔢
• closed — The device file associated with this context has been closed. ⚠️ and here's the vibe-killer detail: Once the device is closed, any submits that have not been written to the ring buffer are no-op'd. That's not a drill bestie, they just silently do nothing 😭
• userspace_managed_vm — the yes/no question: Has userspace opted-in to userspace managed VM (ie. VM_BIND) via MSM_PARAM_EN_VM_BIND? That's literally the whole field. Vibe check on VM_BIND 💅
• vm — The per-process GPU address-space. Big deal, main character energy 🌈 but do not access directly, use msm_context_vm. Like, respect the accessor, okay?? 🙈
• ref — the reference count. She's counting refs, that's it, that's the tweet. 🧚
• seqno — A unique per-process sequence number. What's it for? Used to detect context switches, without relying on keeping a, potentially dangling, pointer to the previous context. ngl, that's so smart — no dangling pointer drama, we just compare numbers 🔥
• sysprof — The value of MSM_PARAM_SYSPROF set by userspace. It's intended to be used by system profiling tools like Mesa's pps-producer (perfetto), and it's restricted to CAP_SYS_ADMIN. so like, privileged girlies only 👑

💜 okay breaking out the details because they matter: Setting a value of 1 will preserve performance counters across context switches. Setting a value of 2 will in addition suppress suspend. And why do we care?? (Performance counters lose state across power collapse, which is undesirable for profiling in some cases.) literally the worst 😭

🎀 also: The value automatically reverts to zero when the drm device file is closed. She resets herself, periodt.

• comm — Overridden task comm, see MSM_PARAM_COMM

Accessed under msm_gpu::lock ⚠️ so lock her properly bestie, no shortcuts.

• cmdline — Overridden task cmdline, see MSM_PARAM_CMDLINE

Accessed under msm_gpu::lock 🌸 same deal, same lock.

• elapsed_ns — The total (cumulative) elapsed time GPU was busy with rendering from this context in ns. Cumulative, bestie — she stacks. ⏱️
• cycles — The total (cumulative) GPU cycles elapsed attributed to this context. Cycle count, also cumulative, also iconic 🌟
• entities — Table of per-priority-level sched entities used by submitqueues associated with this drm_file. And here's the lore 🔥 Because some userspace apps make assumptions about rendering from multiple gl contexts (of the same priority) within the process happening in FIFO order without requiring any fencing beyond MakeCurrent, we create at most one drm_sched_entity per-process per-priority- level. So yes — at most one per process per priority level, because userspace assumptions are load-bearing, iykyk 💀
• ctx_mem — Total amount of memory of GEM buffers with handles attached for this context. That's the memory total, tracked with an atomic64_t, she's precise 💅
• perfctx — the perf counter context state pointer, typed struct msm_perfcntr_context_state * 🎀 (and yeah, she gets her own SEE ALSO entries down below because she runs with a whole crew)

---

⭐ SEE ALSO ⭐

• Kernel file ./drivers/gpu/drm/msm/msm_gpu.h
• struct msm_gpu_devfreq(9)
• struct msm_perfcntr_group_state(9)
• struct msm_perfcntr_state(9)
• msm_context_is_vmbind(9)
• msm_gpu_convert_priority(9)
• struct msm_gpu_submitqueue(9)

---

okay that's the whole page bestie, you're officially a msm_context expert now, I don't make the rules 🫶✨ this was struct msm_context(9) from ./drivers/gpu/drm/msm, dated October 2026 — go forth and slay your context switches 💖🎀🦋