VFIO_SET_IOMMU(9)

📦 version 7.3.1, in nixpkgs unstable

💅 VFIO_SET_IOMMU 💅

okay so hi bestie, you're reading a page from the Kernel API Manual — section 9, the ioctl one — and this is literally the whole vibe: VFIO_SET_IOMMU. pull up a chair 🫶

✨ NAME ✨

VFIO_SET_IOMMU — and in case you were wondering what it actually is under the hood, it's _IOW(VFIO_TYPE, VFIO_BASE + 2, __s32). yes, that's the ioctl signature, write it down 📝

🦋 SYNOPSIS 🦋

VFIO_SET_IOMMU

that's it. that's the whole thing. no arguments in the synopsis, no cap 💀

🌸 DESCRIPTION 🌸

okay so what does it do? it sets the iommu to the given type — simple as that, main character energy ✨

but here's the catch, bestie: that type must be supported by an iommu driver. and how do you know if it is? you verify it by calling CHECK_EXTENSION using the same type. like, matching types, iykyk 🎀

also important — a group must be set to this file descriptor before this ioctl is available. so if you haven't set a group yet, this thing is just… not available to you. sorry babe 🙈

and the IOMMU interfaces that get enabled by this call? those are specific to the value you set. so like, different type in, different interfaces out. it's giving "you get what you pick" 💅

⭐ RETURN ⭐

  • 0 on success — slay 💖
  • -errno on failure — not slay 😭

Availability: when VFIO group attached 👑

🎀 SEE ALSO 🎀

the kernel file to go look at:

  • ./include/uapi/linux/vfio.h

and the whole friend group of related pages, fr fr:

lowkey a heads up bestie: this is kernel API territory — no guessing at behaviour, no vibe-based assumptions. verify your types with CHECK_EXTENSION and make sure your group is attached first. periodt 💅

🌈 that's the whole page! sources say it lives under ./include/uapi/linux and it's dated October 2026 — go off, you're gonna do amazing 🫶💜

📦 where this page comes from