iommufd_hwpt_nested_alloc(9)

💅 iommufd_hwpt_nested_alloc(9) — from the Kernel API Manual, bestie 🎀

okay so you found the kernel API manual, and now you're staring at iommufd_hwpt_nested_alloc like 👀. don't worry, i got you. this is the whole page, nothing skipped, no cap.

---

✨ NAME ✨

iommufd_hwpt_nested_alloc — get a NESTED iommu_domain for a device 🦋

---

🌸 SYNOPSIS 🌸

struct iommufd_hwpt_nested * iommufd_hwpt_nested_alloc (struct
iommufd_ctx *ictx , struct iommufd_hwpt_paging *parent , struct
iommufd_device *idev , u32 flags , const struct iommu_user_data
*user_data );

like, that's the whole signature. it's giving "five arguments and a dream" 💫

---

🎀 ARGUMENTS 🎀

• ictx — the iommufd context. your whole vibe's home base, basically.
• parent — the parent PAGING-type hwpt you wanna associate the domain with. yes, "PAGING-type" is the exact kind — don't come at me with anything else.
• idev — the device you're getting an iommu_domain for. the main character of this whole operation 👑
• flags — flags straight from userspace. their house, their rules.
• user_data — the user_data pointer. must be valid, fr fr. no cute little NULL surprises, okay? 😭

---

💖 DESCRIPTION 💖

so what it does is: allocate a brand-new iommu_domain — and heads up, it must be IOMMU_DOMAIN_NESTED, that's not optional — and hand it back to you as a NESTED hw_pagetable. iconic behavior tbh.

also, the parent PAGING-type hwpt you pass in? it must be capable of being a parent — that's a requirement, not a suggestion. check before you ship it 🫶

---

🔥 SEE ALSO 🔥

• Kernel file ./drivers/iommu/iommufd/hw_pagetable.c — go read the source, it's literally right there 🧚
• iommufd_hwpt_paging_alloc(9)
• iommufd_viommu_alloc_hwpt_nested(9)

---

and that's the page, bestie! 🌈 this one's from ./drivers/iommu/iommufd, dated October 2026, and it's the iommufd_hwpt_nested_alloc(9) entry — slay, go forth and nest those domains 💜✨