pci_dev_reset_iommu_prepare(9)

📦 version 7.3.1, in nixpkgs unstable

okay bestie, you're looking at pci_dev_reset_iommu_prepare(9) from the Kernel API Manual, and it's giving "pause the IOMMU so this PCI device can reset safely" realness. lowkey crucial. 🦋

✨ NAME ✨

pci_dev_reset_iommu_prepare — Block IOMMU to prepare for a PCI device reset. periodt.

🌈 SYNOPSIS 🌈

int pci_dev_reset_iommu_prepare (struct pci_dev *pdev );

🎀 ARGUMENTS 🎀

  • pdev — the PCI device that is going to enter a reset routine. that's the one we're prepping for, bestie 💅

🔥 DESCRIPTION 🔥

okay so the PCIe r6.0, sec 10.3.1 IMPLEMENTATION NOTE recommends to disable and block ATS before initiating a reset. yes, the actual spec note. and what that means is: during the reset routine, a PCIe device wants to block any IOMMU activity — both translation and ATS invalidation. both. not a vibe check, a full block. 🙈

This function attaches the device's RID/PASID(s) to the group->blocking_domain, incrementing the group->recovery_cnt, so the IOMMU driver can pause any IOMMU activity while leaving the group->domain pointer intact. the domain pointer stays untouched, the blocking domain gets the RID/PASID(s), and recovery_cnt goes up. later, when the reset is finished, pci_dev_reset_iommu_done can restore everything. iconic teamwork, honestly. 🫶

The caller must use pci_dev_reset_iommu_prepare with pci_dev_reset_iommu_done before/after the core-level reset routine, to decrement the recovery_cnt. like, they're a matched set — don't use one without the other and then act surprised. 🎀

These two functions are designed to be used by PCI reset functions that would not invoke any racy iommu_release_device, since the PCI sysfs node gets removed before it notifies with a BUS_NOTIFY_REMOVED_DEVICE. when using them in other case, callers must ensure there will be no racy iommu_release_device call — which otherwise would UAF the dev->iommu_group pointer. no cap, that's a use-after-free and it is NOT the move. 💀

⚠️ real talk: using these outside the designed path means you must ensure there is no racy iommu_release_device call. if there is, it would UAF the dev->iommu_group pointer. not cute, not slay, do not do it. 🚨

⭐ RETURN ⭐

0 on success, or a negative error code if the preparation failed. that's the whole return vibe. ✨

👑 SEE ALSO 👑

Kernel file ./drivers/iommu/iommu.c — yes, that exact file — plus all these function besties, in the original order:

mwah 💋 this page is from source ./drivers/iommu, in the Kernel API Manual, dated October 2026 — pci_dev_reset_iommu_prepare(9), out. slay bestie, go prep that reset. 💖

📦 where this page comes from