pci_add_dma_alias(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

okay so bestie, welcome to pci_add_dma_alias(9) from the Kernel API Manual β€” this one is all about giving a PCI device a DMA devfn alias, and it’s lowkey important for IOMMU vibes πŸ’…


πŸ’– NAME πŸ’–

pci_add_dma_alias β€” Add a DMA devfn alias for a device. periodt.


✨ SYNOPSIS ✨

void pci_add_dma_alias (struct pci_dev *dev , u8 devfn_from , unsigned
       int nr_devfns );

πŸŽ€ ARGUMENTS πŸŽ€

  • dev β€” the PCI device for which the alias is added 🫢
  • devfn_from β€” the alias slot and function ✨
  • nr_devfns β€” number of subsequent devfns to alias πŸ’«

πŸ’… DESCRIPTION πŸ’…

okay so this helper encodes an 8-bit devfn as a bit number in dma_alias_mask, which is used to program permissible bus-devfn source addresses for DMA requests in an IOMMU. no cap, that’s the whole vibe.

These aliases factor into IOMMU group creation and are useful for devices generating DMA requests beyond or different from their logical bus-devfn. examples include device quirks where the device simply uses the wrong devfn, as well as non-transparent bridges where the alias may be a proxy for devices in another domain. iconic but also kind of chaotic 😭

IOMMU group creation is performed during device discovery or addition, prior to any potential DMA mapping and therefore prior to driver probing (especially for userspace assigned devices where IOMMU group definition cannot be left as a userspace activity). so yeah, DMA aliases should therefore be configured via quirks, such as the PCI fixup header quirk. fr fr, that’s the timing.


πŸ”— SEE ALSO πŸ”—

Kernel file ./drivers/pci/pci.c β€” and honestly the whole PCI friend group shows up here:


and that’s the whole page, bestie πŸ’– source is ./drivers/pci, dated October 2026, and we were literally just talking about pci_add_dma_alias(9) πŸ¦‹βœ¨

πŸ“¦ where this page comes from