VFIO_DEVICE_GET_GFX_DMABUF(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… VFIO_DEVICE_GET_GFX_DMABUF πŸ’…

okay so welcome to the Kernel API Manual, section 9, and today's main character is VFIO_DEVICE_GET_GFX_DMABUF β€” yes bestie, the name is giving very much "I am an ioctl and I know it" ✨


πŸŽ€ NAME πŸŽ€

VFIO_DEVICE_GET_GFX_DMABUF β€” and her whole entire personality is right there in the encoding, no cap:

_IOW(VFIO_TYPE, VFIO_BASE + 15, __u32)

that's the vibe check, that's the whole ID, she's VFIO_TYPE with VFIO_BASE + 15 energy and a __u32 payload 🫢


πŸ¦‹ SYNOPSIS πŸ¦‹

VFIO_DEVICE_GET_GFX_DMABUF

literally that's it. no arguments to memorise, no flags, nothing. she's lowkey effortless and we respect it πŸ’…


🌸 DESCRIPTION 🌸

okay so picture this: this ioctl returns a brand-new dma-buf file descriptor πŸ”₯ for a guest framebuffer that's already been exposed β€” like, out there, visible, doing its little framebuffer thing.

and which framebuffer? the one described by the dmabuf_id you hand over. that's the token, that's the receipt, that's the little "yes, that one please" πŸŽ€

and where does that dmabuf_id come from in the first place? it's returned by VFIO_DEVICE_QUERY_GFX_PLANE, as a token of the exposed guest framebuffer. so the flow is literally: query the plane, get the token, then come back here with it β€” iykyk, one hand washes the other πŸ’–

no surprises here, babe. no hidden tricks. the id you got from the query is the id you feed to this call, and out pops a fresh fd for you πŸ¦‹

πŸ‘‘ SEE ALSO πŸ‘‘

go off, cross-references, we love a linked list of lore 🌈


and that's the whole page, bestie 🫢 straight from ./include/uapi/linux, dated October 2026, filed under VFIO_DEVICE_GET_GFX_DMABUF(9) β€” periodt πŸ’…βœ¨

πŸ“¦ where this page comes from