iova_bitmap_alloc(9)

📦 version 7.3.1, in nixpkgs unstable

💖 iova_bitmap_alloc — bestie's guide to the IOVA bitmap allocator 💖

okay so this is a page from the Kernel API Manual, section 9 — yes, the kernel girlies have their own manpage section and she's serving. Let's get into it 🎀

✨ NAME ✨

iova_bitmap_alloc — literally allocates an IOVA bitmap object. that's the whole job. icon behaviour 💅

🌸 SYNOPSIS 🌸

struct iova_bitmap * iova_bitmap_alloc (unsigned long iova , size_t
       length , unsigned long page_size , u64 __user *data );

note the spacing, bestie — we keep it exactly how the kernel gave it to us 🫶

🦋 ARGUMENTS 🦋

  • iova — start address of the IOVA range. the beginning. the main character's entrance 🚪✨
  • length — length of the IOVA range. how far we're going, fr fr 📏
  • page_size — page size of the IOVA bitmap. it defines what each bit granularity represents — so like, every single bit is carrying weight and this decides what it means 👑
  • data — userspace address of the bitmap. it's u64 __user * and it's pointing at somebody's user memory, so treat it with respect 🙈

💜 DESCRIPTION 💜

Allocates an IOVA object and initializes all its fields — every single one, no crumbs left behind — including the first user pages of data. it's giving "full setup, zero shortcuts" energy 🌈

⭐ RETURN ⭐

A pointer to a newly allocated struct iova_bitmap — slay, fresh out of the allocator 💖

Or ERR_PTR on error 😭 which, yeah, always check that. that's the vibe check. if you ignore it, you're on your own ngl 💀

🔥 SEE ALSO 🔥

Kernel file ./drivers/iommu/iommufd/iova_bitmap.c — go read the source, iykyk 👑

the whole friend group, together at last 🫶🌸

no cap: this page comes from the ./drivers/iommu/iommufd corner of the kernel and it's dated October 2026 — so if you're reading it, hi from the future bestie, mwah 💋✨
📦 where this page comes from