STRUCT MSM_VM_BIND_JOB(9)

🎀 struct msm_vm_bind_job — tracking for a VM_BIND ioctl 💅

okay so this page lives in the Kernel API Manual, and the star of the show is struct msm_vm_bind_job(9) — the little bookkeeping baddie that keeps track of one single VM_BIND ioctl. it's giving "group project manager" energy and honestly? it ate. 🦋

---

✨ SYNOPSIS ✨

struct msm_vm_bind_job {
    struct drm_sched_job base;
    struct drm_gpuvm *vm;
    struct dma_fence *fence;
    struct msm_gpu_submitqueue *queue;
    struct msm_mmu_prealloc prealloc;
    struct list_head vm_ops;
    bool bos_pinned;
    unsigned int nr_ops;
    struct msm_vm_bind_op {
      uint32_t op;
      uint32_t flags;
      union {
        struct drm_gem_object *obj;
        uint32_t handle;
      };
      uint64_t obj_offset;
      uint64_t iova;
      uint64_t range;
    } ops[];
 };

like, look at that trailing ops[] — flexible array member main character energy, no notes. 👑

---

🌸 MEMBERS 🌸

• base — the base class for drm_sched jobs. every job needs a foundation, and this is hers. 💖
• vm — the VM being operated on. the actual vibe being transformed, iykyk.
• fence — the fence that is signaled when the job completes. think of it as the "we're so back" notification. 🔔
• queue — the queue that the job runs on. her designated lane, literally.
• prealloc — tracking for pre-allocated MMU pgtable pages. pre-allocated = pre-planned, and we love a planner. 📋
• vm_ops — a list of struct msm_vm_op. her little entourage of operations.
• bos_pinned — are the GEM objects being bound pinned? a whole yes/no moment, very vibe check. ✅
• nr_ops — the number of userspace requested ops. girl is counting, always counting. 🔢
• ops — the userspace requested ops. the whole reason she exists, fr fr.

the userspace requested ops are copied/parsed and validated before we start applying the updates, to try to do as much up-front error checking as possible — that way the VM doesn't end up in an undefined state due to a partially executed VM_BIND. ⚠️ no cap, that's the entire point: fail early, fail clean, don't leave the VM in shambles mid-operation. 💀

this table also serves to hold a reference to the backing GEM objects. so she's not just a list, she's a lifeline — she keeps those objects alive. 🫶

• {unnamed_union} — anonymous. mysterious. doesn't gatekeep her identity. 🙈

---

💜 DESCRIPTION 💜

so here's the whole storyline, bestie: a table of userspace requested VM updates — that's MSM_VM_BIND_OP_UNMAP/MAP/MAP_NULL — gets applied to the vm, and that generates a list of VM ops (MSM_VM_OP_MAP/UNMAP) which get applied to the pgtables asynchronously. ✨ async queen ✨

and lowkey the glow-up is real, because one userspace request can multiply. for example, a userspace requested MSM_VM_BIND_OP_MAP could end up generating both an MSM_VM_OP_UNMAP to unmap an existing mapping and an MSM_VM_OP_MAP to apply the new mapping. one request in, two ops out — that's range, that's versatility, that's the whole pipeline. 🔥

ngl this is the part where you just trust the flow: userspace asks, the kernel validates, the pgtables get updated async later. simple as.

---

🌈 SEE ALSO 🌈

• Kernel file ./drivers/gpu/drm/msm/msm_gem_vma.c
• struct msm_vm_map_op(9)
• struct msm_vm_unmap_op(9)
• struct msm_vm_op(9)
• msm_gem_vm_unusable(9)
• msm_gem_vm_create(9)
• msm_gem_vm_close(9)

---

and that's the page, bestie — brought to you by ./drivers/gpu/drm/msm, dated October 2026, filed under struct msm_vm_bind_job(9). go read the SEE ALSOs, they're literally all connected 🧚⭐💜