msm_context_is_vmbind(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

This is msm_context_is_vmbind(9) from the Kernel API Manual, and it answers one iconic question: has userspace opted in to VM_BIND? πŸ‘‘


✨ SYNOPSIS ✨

bool msm_context_is_vmbind (struct msm_context *ctx );

πŸŽ€ ARGUMENTS πŸŽ€

  • ctx β€” the drm_file context. That's the vibe check input, bestie.

🌸 DESCRIPTION 🌸

Okay so, see MSM_PARAM_EN_VM_BIND. If userspace is managing the VM, it can do sparse binding, including having multiple, potentially partial, mappings in the VM. Therefore certain legacy uabi (ie. GET_IOVA, SET_IOVA) are rejected because they don't have a sensible meaning. πŸ’…

No cap: those legacy uabi calls get rejected in that setup because they literally don't have a sensible meaning there. 🫢

πŸ¦‹ RETURN πŸ¦‹

Returns true if userspace is managing the VM, and false otherwise. Periodt. ✨

🌈 SEE ALSO 🌈

  • Kernel file ./drivers/gpu/drm/msm/msm_gpu.h, plus these absolutely iconic references: struct msm_gpu_devfreq(9), struct msm_perfcntr_group_state(9), struct msm_perfcntr_state(9), struct msm_context(9), msm_gpu_convert_priority(9), struct msm_gpu_submitqueue(9).

That's the whole vibe, bestie πŸ’– This page lives under ./drivers/gpu/drm/msm, it's dated October 2026, and it's msm_context_is_vmbind(9) β€” slay, bye! 🫢✨

πŸ“¦ where this page comes from