STRUCT FW_RSC_DEVMEM(9)

💖 struct fw_rsc_devmem(9) — iommu mapping request 💖

okay bestie, this is a page from the Kernel API Manual and it's literally about asking the host to iommu-map a chunk of memory for a remote processor. it's giving "polite request slip for memory access" energy and honestly? iconic. let's get into it ✨

---

✨ SYNOPSIS ✨

struct fw_rsc_devmem {
    u32 da;
    u32 pa;
    u32 len;
    u32 flags;
    u32 reserved;
    u8 name[32];
 };

bestie, that is the whole struct. six fields. no cap. let's meet them 🫶

---

🎀 Members 🎀

• da — the device address. this is the address the device side is gonna use, okay? 👑
• pa — the physical address. the real one. the one on actual hardware. 🔥
• len — length, and yes, it's in bytes, so don't be out here guessing. 📏
• flags — the iommu protection flags. this is where you tell it how protected you want the mapping to be, iykyk 💅
• reserved — reserved, and it must be zero. like, do not touch it, do not be cute with it, leave it at zero. periodt. 💀
• name — a human-readable name of the requested region to be mapped. it's u8 name[32], so keep it short — it's mainly for debugging purposes anyway 🐛🌸

---

🌸 Description 🌸

so here's the vibe: this resource entry is literally requesting that the host iommu-map a physically contiguous memory region for you. that's the whole job. 🫡

when do you actually need this? when the remote processor needs access to certain memory-based peripherals. that's the case. that's it.

⚠️ but bestie, listen — _never_ use this to access regular memory. like, ever. that is not what this is for and we do not do that here. 🚫

also, obviously, this is only needed if the remote processor is accessing memory via an iommu. no iommu, no need. simple as that. ✨

now for the field rundown, again, because it's important:

• da should specify the required device address
• pa should specify the physical address we want to map
• len should specify the size of the mapping
• flags is the IOMMU protection flags

and as always, name may (optionally!) contain a human readable name of this mapping — mainly for debugging purposes. optional! but cute and helpful. 🎀

---

🙈 Note 🙈

okay so this is the part where I have to be real with you: at this point we just "trust" those devmem entries to contain valid physical addresses. trust. quotes and all. 😭

and lowkey that isn't safe, and it will be changed — that's the plan, not a rumour.

eventually we want remoteproc implementations to provide us ranges of physical addresses that the firmware is allowed to request. and then firmwares will not be allowed to request access to physical addresses outside those ranges. so: boundaries. safety. growth. we love to see it. 🌈⭐

🫶 so rn: trust-based. soon: range-checked. don't build your whole personality on the trusting version, bestie.

---

💜 SEE ALSO 💜

• Kernel file ./include/linux/rsc_table.h
• struct resource_table(9)
• struct fw_rsc_hdr(9)
• enum fw_resource_type(9)
• struct fw_rsc_carveout(9)
• struct fw_rsc_trace(9)
• struct fw_rsc_vdev_vring(9)
• struct fw_rsc_vdev(9)
• rsc_table_for_each_entry(9)

like, go read the whole friend group honestly, they all hang out in ./include/linux/rsc_table.h together 🦋

---

and that's the page!! this lil gem lives in ./include/linux, and the version/date stamp on it is October 2026 — so yeah, it's from the future, main character energy fr fr. mwah, go map some peripherals responsibly 💋👑🍓