STRUCT PANTHOR_VM_OP_CTX(9)

📦 version 7.3.1, in nixpkgs unstable

🦋 NAME

struct panthor_vm_op_ctx — the VM operation context 💖

okay so bestie, this is the little struct that holds everything a VM operation needs before it even starts running. Think of it as the packed lunch your op brings along so it doesn't have to stop at the drive-thru mid-flight 🍓

✨ SYNOPSIS

struct panthor_vm_op_ctx {
    struct {
      u32 count;
      u32 ptr;
      void **pages;
    } rsvd_page_tables;
    struct panthor_vma *preallocated_vmas[3];
    u32 flags;
    struct {
      u64 addr;
      u64 range;
    } va;
    struct {
      struct drm_gpuvm_bo *vm_bo;
      u64 bo_offset;
      struct panthor_gem_object *bo;
    } map;
};

🎀 Members

  • rsvd_page_tables — the pages that have been reserved for the MMU page table update, bestie 🫶
    • rsvd_page_tables.count — literally just the number of pages reserved 🔢
    • rsvd_page_tables.ptr — points to the first unused page in the pages table 👀
    • rsvd_page_tables.pages — the actual array of pages that get used for an MMU page table update ✨
After an VM operation, there might be free pages left in this array. They should be returned to the pt_cache as part of the op_ctx cleanup. don't forget, okay?? that's the whole point of the cleanup 😭
  • preallocated_vmas — pre-allocated VMAs, there specifically to handle the remap case 💅

Partial unmap requests, or map requests that overlap existing mappings, will trigger a remap call, and that remap needs to register up to three panthor_vma objects — one for the new mapping, and two for the previous and next mappings. yeah. three. iconic behavior honestly 👑

  • flags — a combination of drm_panthor_vm_bind_op_flags 🚩
  • va — the virtual range that the VM operation is targeting 🎯
    • va.addr — start address 📍
    • va.range — range size 📏
  • map — the fields that are specific to a map operation 🗺️
    • map.vm_bo — the buffer object to map 💖
    • map.bo_offset — offset in the buffer object 🔎
    • map.bo — the BO being mapped 🌸

💜 Description

So here's the vibe: VM operations can potentially take place in a dma-signaling path 😳 which means we need to make sure that everything that might require resource allocation is pre-allocated upfront. That is literally what this operation context is for. no allocation surprises mid-signal, periodt 🚫

We also collect the resources that have been freed, so we can release them asynchronously and let the VM_BIND scheduler go ahead and process the next VM_BIND request. very main character of the scheduler honestly 🔥

🌈 SEE ALSO

Kernel file ./drivers/gpu/drm/panthor/panthor_mmu.c and also, in no particular order, all of these besties:

okay that's the whole page, go read the source at ./drivers/gpu/drm/panthor 💅 this one's dated October 2026 and it's struct panthor_vm_op_ctx(9) out of the Kernel API Manual — mwah, ily, go forth and map responsibly 🧚💖

📦 where this page comes from