hmm_dma_map_pfn(9)

📦 version 7.3.1, in nixpkgs unstable

💅 hmm_dma_map_pfn 💅

ok so this is a page from the Kernel API Manual (section 9, the kernel-API girlies 🫶) and yeah we're talking about hmm_dma_map_pfn — the function that maps a physical HMM page to a DMA address. no cap, that's the whole vibe of it.

✨ NAME ✨

hmm_dma_map_pfn — Map a physical HMM page to DMA address 🔥

🌸 SYNOPSIS 🌸

dma_addr_t hmm_dma_map_pfn (struct device *dev , struct hmm_dma_map *map
, size_t idx , struct pci_p2pdma_map_state *p2pdma_state );

like, that's the signature bestie, copy it exactly, don't be weird about it 💖

🎀 ARGUMENTS 🎀

  • dev — the Device you're mapping the page for. main character energy, obviously 💅
  • map — the HMM map. yeah. that one. 🌸
  • idx — Index into the PFN and dma address arrays. it's giving "which one, bestie" 🦋
  • p2pdma_state — PCI P2P state. that's it, that's the whole description 😭

🦋 DESCRIPTION 🦋

okay so dma_alloc_iova allocates IOVA based on the size specified by their use in iova->size. noted. ✨

Call this function after IOVA allocation to link whole page to get the DMA address. slay, that's the order of operations, don't skip steps 🫶

heads up bestie, this part matters: note that the very first call to this function will have offset set to 0 in the IOVA space allocated from dma_alloc_iova. literally zero. the fresh start era 💖

For subsequent calls to this function on same iova, offset needs to be advanced by the caller with the size of previous page that was linked + DMA address returned for the previous page that was linked by this function. so, like, you (the caller) are doing that math, not the function. no cap, it's on you 😤🔥

👑 SEE ALSO 👑

Kernel file ./mm/hmm.c — and the whole friend group:

iykyk, go read those next 🧚💜

and that's the page!! sign-off time: this one lives in ./mm, and the date on it is October 2026, and the page itself is hmm_dma_map_pfn(9). periodt. bye bestie, go map some pages 💅🎀🌈

📦 where this page comes from