STRUCT FW_RSC_CARVEOUT(9)

✨ struct fw_rsc_carveout(9) ✨

okay bestie, welcome to the Kernel API Manual 💖 you're about to meet struct fw_rsc_carveout — the "hey host, can I please get some physically contiguous memory" request. it's giving main character energy for firmware resource tables 👑

---

🌸 NAME 🌸

struct fw_rsc_carveout — a request for physically contiguous memory, no cap 💅

---

🎀 SYNOPSIS 🎀

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

---

🦋 Members 🦋

• da — the device address ✨
• pa — the physical address 📍
• len — the length, and yes queen, it's in bytes 🍓
• flags — the iommu protection flags 🔥
• reserved — reserved… and it must be zero (don't be quirky about this one, seriously) 💀
• name — a human-readable name for the memory region you're requesting 🏷️

---

🌈 Description 🌈

so basically: this resource entry asks the host to allocate a physically contiguous memory region. that's the whole vibe 🫶

these request entries should come before other firmware resource entries, because other entries might ask to place other data objects inside these very memory regions (think data/code segments, trace resource entries, ...). order matters, iykyk ⭐

allocating memory this way helps you use the reserved physical memory (like CMA, for example) more efficiently — slay — and it also minimizes the number of TLB entries you need to map it, in case rproc is using an IOMMU. reducing TLB pressure is important, like genuinely, it can have a substantial impact on performance 👑

if the firmware is compiled with static addresses, then da should specify the expected device address of this memory region. but if da is set to FW_RSC_ADDR_ANY, the host will dynamically allocate it, and then overwrite da with the dynamically allocated address ✨

we will always use da to negotiate the device addresses — even if it isn't using an iommu. in that case though, it will obviously contain physical addresses 🙈

some remote processors need to know the allocated physical address even if they do use an iommu. this is needed, e.g., if they control hardware accelerators which access the physical memory directly (this is exactly the case with OMAP4 for instance). in that case, the host will overwrite pa with the dynamically allocated physical address 📍

generally we don't want to expose physical addresses if we don't have to — remote processors are generally _not_ trusted — so we might want to change this to happen _only_ when explicitly required by the hardware. so, yeah, that's a whole thing 😭

flags is used to provide IOMMU protection flags, and name should (optionally) contain a human readable name of this carveout region — mainly for debugging purposes 🎀

---

💜 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_devmem(9)
• struct fw_rsc_trace(9)
• struct fw_rsc_vdev_vring(9)
• struct fw_rsc_vdev(9)
• rsc_table_for_each_entry(9)

---

that's the whole page bestie, you ate that 💅✨ this one lives in ./include/linux, from the October 2026 edition of the Kernel API Manual — go forth and carve out some memory, periodt 🌟💖