iommu_replace_device_pasid(9)

💅 iommu_replace_device_pasid 💅

okay so this is a page from the Kernel API Manual, and honestly? it's giving "small function, big responsibilities" and we're gonna get into it 🫶

---

🌸 NAME 🌸

iommu_replace_device_pasid — swap out the domain that one specific pasid of the device is attached to. that's the whole gig. slay ✨

---

🦋 SYNOPSIS 🦋

int iommu_replace_device_pasid (struct iommu_domain *domain , struct
       device *dev , ioasid_t pasid , struct iommu_attach_handle *handle );

---

🎀 ARGUMENTS 🎀

• domain — the new iommu domain. the fresh fit the pasid is gonna be wearing 💖
• dev — the attached device. like, the device in question, bestie.
• pasid — the pasid of the device. yes that exact one.
• handle — the attach handle.

---

✨ DESCRIPTION ✨

so this API lets the pasid switch domains. iconic behaviour, truly.

but — and this is the important part — the pasid should have already been attached. if it hasn't been? this fails. no cap, it's just not gonna work 🙈

and the pasid will keep the old configuration if the replacement failed. so like, no messy half-swapped situation, it just stays exactly as it was. we love a clean rollback 💅

caller note, listen up: the caller should always provide a new handle to avoid a race with the paths that have lockless reference to handle, if it intends to pass a valid handle. like, always. new handle. don't reuse. big deal 🔥

Returns 0 on success, or an error. that's it, that's the vibe check.

---

👑 SEE ALSO 👑

Kernel file ./drivers/iommu/iommu.c and these absolutely iconic siblings:

• iommu_device_register(9)
• iommu_insert_resv_region(9)
• iommu_group_alloc(9)
• iommu_group_get_iommudata(9)
• iommu_group_set_iommudata(9)
• iommu_group_set_name(9)
• iommu_group_add_device(9)
• iommu_group_remove_device(9)
• iommu_group_mutex_assert(9)
• iommu_group_for_each_dev(9)
• iommu_group_get(9)
• iommu_group_ref_get(9)
• iommu_group_put(9)
• iommu_group_id(9)
• device_iommu_capable(9)
• iommu_group_has_isolated_msi(9)
• iommu_set_fault_handler(9)
• iommu_paging_domain_alloc_flags(9)
• iommu_attach_device(9)
• iommu_get_domain_for_dev(9)
• iommu_driver_get_domain_for_dev(9)
• iommu_attach_group(9)
• iommu_unmap(9)
• iommu_unmap_fast(9)
• report_iommu_fault(9)
• iommu_get_resv_regions(9)
• iommu_put_resv_regions(9)
• iommu_setup_default_domain(9)
• iommu_device_use_default_domain(9)
• iommu_device_unuse_default_domain(9)
• iommu_group_claim_dma_owner(9)
• iommu_device_claim_dma_owner(9)
• iommu_group_release_dma_owner(9)
• iommu_device_release_dma_owner(9)
• iommu_group_dma_owner_claimed(9)
• iommu_attach_handle_get(9)
• iommu_attach_group_handle(9)
• iommu_detach_group_handle(9)
• iommu_replace_group_handle(9)
• pci_dev_reset_iommu_prepare(9)
• pci_dev_reset_iommu_done(9)
• iommu_dma_prepare_msi(9)

---

okay that's the whole page, mwah 💋 it lives in ./drivers/iommu, it's dated October 2026, and it's part of the Kernel API Manual — go forth and switch those domains responsibly, bestie 🌈⭐💜