STRUCT IOMMU_VDEVICE_ALLOC(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct iommu_vdevice_alloc(9) β€” kernel API manual, bestie edition πŸŽ€

okay so bestie, this is a page straight out of the Kernel API Manual, and it's literally all about struct iommu_vdevice_alloc β€” the struct behind the ioctl(IOMMU_VDEVICE_ALLOC) call. it's giving "registration desk for virtual devices" and honestly? iconic. let's get into it πŸ¦‹


✨ NAME ✨

struct iommu_vdevice_alloc β€” the struct you hand to ioctl(IOMMU_VDEVICE_ALLOC). that's it, that's the name, no cap πŸ’–


🫢 SYNOPSIS 🫢

here's the whole shape of it, copy-paste energy, do not touch a single character:

struct iommu_vdevice_alloc {
    __u32 size;
    __u32 viommu_id;
    __u32 dev_id;
    __u32 out_vdevice_id;
    __aligned_u64 virt_id;
 };

like, look at those fields. so organized. so slay 🌸


πŸŽ€ Members πŸŽ€

okay now the fun part β€” meeting the whole cast πŸ’…

  • size β€” it's just sizeof(struct iommu_vdevice_alloc). a little self-portrait so everyone knows how big this struct is. main character energy fr ✨
  • viommu_id β€” the vIOMMU ID you're associating with your virtual device. like, whose party is this and which VIP list are we on πŸŽ‰
  • dev_id β€” the physical device you want to allocate a virtual instance on, on that vIOMMU. yes bestie, physical. the real one πŸ”₯
  • out_vdevice_id β€” the object handle for the vDevice that comes back out. you pass this to IOMMU_DESTORY later. this is your little receipt, keep it safe 🧾🫢
  • virt_id β€” the virtual device ID, and it's per vIOMMU. e.g. vSID of ARM SMMUv3, vDeviceID of AMD IOMMU, and vRID of Intel VT-d. different vendor, different name, same vibe check πŸ’œ

🌈 Description 🌈

so what does this actually do? it allocates a virtual device instance β€” for a physical device β€” against a vIOMMU. that instance holds the device's information (the stuff related to its vIOMMU) inside a VM. very "your name is on the list, come on in" πŸ’–

now here's the part where you listen to me, bestie, because this is the important bit πŸ™ˆ

you should use IOMMU_DESTROY to destroy the virtual device before you destroy the physical device (which happens by closing the vfio_cdev fd). like, clean up your own mess, in order, please and thank you.

because if you don't? the virtual device gets forcibly destroyed on physical device destruction, and its vdevice_id is permanently leaked β€” unremovable & unreusable β€” until the iommu fd is closed. permanent leak. not a cute look. not the vibe. πŸ˜­πŸ’€

so yeah: destroy virtual first, then physical. periodt. πŸ‘‘


πŸ”₯ SEE ALSO πŸ”₯

the whole extended friend group, no one left behind, list is long but every single one is invited 🫢

  • Kernel file ./include/uapi/linux/iommufd.h
  • General ioctl format(9)
  • struct iommu_destroy(9)
  • struct iommu_ioas_alloc(9)
  • struct iommu_iova_range(9)
  • struct iommu_ioas_iova_ranges(9)
  • struct iommu_ioas_allow_iovas(9)
  • enum iommufd_ioas_map_flags(9)
  • struct iommu_ioas_map(9)
  • struct iommu_ioas_noiommu_get_pa(9)
  • struct iommu_ioas_map_file(9)
  • struct iommu_ioas_copy(9)
  • struct iommu_ioas_unmap(9)
  • enum iommufd_option(9)
  • enum iommufd_option_ops(9)
  • struct iommu_option(9)
  • enum iommufd_vfio_ioas_op(9)
  • struct iommu_vfio_ioas(9)
  • enum iommufd_hwpt_alloc_flags(9)
  • enum iommu_hwpt_vtd_s1_flags(9)
  • struct iommu_hwpt_vtd_s1(9)
  • struct iommu_hwpt_arm_smmuv3(9)
  • struct iommu_hwpt_amd_guest(9)
  • enum iommu_hwpt_data_type(9)
  • struct iommu_hwpt_alloc(9)
  • enum iommu_hw_info_vtd_flags(9)
  • struct iommu_hw_info_vtd(9)
  • enum iommu_hw_info_arm_smmuv3_flags(9)
  • struct iommu_hw_info_arm_smmuv3(9)
  • struct iommu_hw_info_tegra241_cmdqv(9)
  • struct iommu_hw_info_amd(9)
  • enum iommu_hw_info_type(9)
  • enum iommufd_hw_capabilities(9)
  • enum iommufd_hw_info_flags(9)
  • struct iommu_hw_info(9)
  • struct iommu_hwpt_set_dirty_tracking(9)
  • enum iommufd_hwpt_get_dirty_bitmap_flags(9)
  • struct iommu_hwpt_get_dirty_bitmap(9)
  • enum iommu_hwpt_invalidate_data_type(9)
  • enum iommu_hwpt_vtd_s1_invalidate_flags(9)
  • struct iommu_hwpt_vtd_s1_invalidate(9)
  • struct iommu_viommu_arm_smmuv3_invalidate(9)
  • struct iommu_hwpt_invalidate(9)
  • enum iommu_hwpt_pgfault_flags(9)
  • enum iommu_hwpt_pgfault_perm(9)
  • struct iommu_hwpt_pgfault(9)
  • enum iommufd_page_response_code(9)
  • struct iommu_hwpt_page_response(9)
  • struct iommu_fault_alloc(9)
  • enum iommu_viommu_type(9)
  • struct iommu_viommu_tegra241_cmdqv(9)
  • struct iommu_viommu_alloc(9)
  • struct iommu_ioas_change_process(9)
  • enum iommu_veventq_flag(9)
  • struct iommufd_vevent_header(9)
  • enum iommu_veventq_type(9)
  • struct iommu_vevent_arm_smmuv3(9)
  • struct iommu_vevent_tegra241_cmdqv(9)
  • struct iommu_veventq_alloc(9)
  • enum iommu_hw_queue_type(9)
  • struct iommu_hw_queue_alloc(9)

and that's the tea, bestie πŸ“ this page lives over in ./include/uapi/linux, it's stamped October 2026, and it's filed under struct iommu_vdevice_alloc(9) β€” go forth, allocate responsibly, and destroy in the right order πŸ’œβœ¨πŸ§š

πŸ“¦ where this page comes from