STRUCT MSM_GEM_VM(9)

💖 struct msm_gem_vm(9) 💖

okay bestie, welcome to the Kernel API Manual page for struct msm_gem_vm(9) — this is literally the VM object and we're gonna break it down, no cap. ✨

🌸 NAME 🌸

struct msm_gem_vm — VM object

✨ SYNOPSIS ✨

here's the literal struct, character for character, do not touch:

       struct msm_gem_vm {
           struct drm_gpuvm base;
           struct rcu_head rcu;
           struct drm_gpu_scheduler sched;
           struct {
             wait_queue_head_t wait;
             atomic_t in_flight;
           } prealloc_throttle;
           struct drm_mm mm;
           struct msm_mmu *mmu;
           struct mutex mmu_lock;
           struct pid *pid;
           struct dma_fence *last_fence;
           struct msm_gem_vm_log_entry *log;
           uint32_t log_shift;
           uint32_t log_idx;
           int faults;
           bool managed;
           bool unusable;
        };

💖 Members 💖

• base — Inherit from drm_gpuvm.
• rcu — RCU-delayed free so an exported sched fence->sched stays valid.
• sched — Scheduler used for asynchronous VM_BIND request.

Unused for kernel managed VMs (where all operations are synchronous).

• prealloc_throttle — Used to throttle VM_BIND ops if too much pre- allocated memory is in flight.

Because we have to pre-allocate pgtable pages for the worst case (ie. new mappings do not share any PTEs with existing mappings) we could end up consuming a lot of resources transiently. The prealloc_throttle puts an upper bound on that.

• mm — Memory management for kernel managed VA allocations

Only used for kernel managed VMs, unused for user managed VMs.

Protected by vm lock. See msm_gem_lock_vm_and_obj, for ex.

• mmu — The mmu object which manages the pgtables
• mmu_lock — Protects access to the mmu
• pid — For address spaces associated with a specific process, this will be non-NULL:
• last_fence — Fence for last pending work scheduled on the VM
• log — A log of recent VM updates
• log_shift — length of log is (1 << log_shift)
• log_idx — index of next log entry to write
• faults — the number of GPU hangs associated with this address space
• managed — is this a kernel managed VM?
• unusable — True if the VM has turned unusable because something bad happened during an asynchronous request.

We don't try to recover from such failures, because this implies informing userspace about the specific operation that failed, and hoping the userspace driver can replay things from there. This all sounds very complicated for little gain.

Instead, we should just flag the VM as unusable, and fail any further request targeting this VM.

As an analogy, this would be mapped to a VK_ERROR_DEVICE_LOST situation, where the logical device needs to be re-created.

🌈 Description 🌈

A VM object representing a GPU (or display or GMU or ...) virtual address space. 🦋

In the case of GPU, if per-process address spaces are supported, the address space is split into two VMs, which map to TTBR0 and TTBR1 in the SMMU. TTBR0 is used for userspace objects, and is unique per msm_context/drm_file, while TTBR1 is the same for all processes. (The kernel controlled ringbuffer and a few other kernel controlled buffers live in TTBR1.) ✨

The GPU TTBR0 vm can be managed by userspace or by the kernel, depending on whether userspace supports VM_BIND. All other vm's are managed by the kernel. (Managed by kernel means the kernel is responsible for VA allocation.) 💅

Note that because VM_BIND allows a given BO to be mapped multiple times in a VM, and therefore have multiple VMA's in a VM, there is an extra object provided by drm_gpuvm infrastructure.. the drm_gpuvm_bo, which is not embedded in any larger driver structure. The GEM object holds a list of drm_gpuvm_bo, which in turn holds a list of msm_gem_vma. A linked vma holds a reference to the vm_bo, and drops it when the vma is unlinked. So we just need to call drm_gpuvm_bo_obtain_locked to return a ref to an existing vm_bo, or create a new one. Once the vma is linked, the ref to the vm_bo can be dropped (since the vma is holding one). 🫶

🎀 SEE ALSO 🎀

Kernel file ./drivers/gpu/drm/msm/msm_gem.h struct msm_gem_vm_log_entry(9), struct msm_gem_vma(9), msm_gem_lock_vm_and_obj(9) 🌸

---

and that's the whole vibe, bestie 💅 — this iconic page comes from ./drivers/gpu/drm/msm, dated October 2026, and the title is literally struct msm_gem_vm(9). slay. 👑