Raspberry Pi 5 IOMMU Support Lands in Mainline Linux: What It Means

In brief — 2026-07-18 · IOMMU driver support for the Raspberry Pi 5 is being upstreamed to the mainline Linux kernel, per Phoronix reporting. For most users this changes little day to day; for builders using the Pi 5's PCIe lane for NVMe storage, virtualization, or device passthrough, mainline IOMMU support unlocks proper device isolation and lands the Pi 5 solidly in the "real Linux SBC" tier rather than the "requires Raspberry Pi OS" niche.

What happened

The Pi 5's Broadcom BCM2712 SoC includes a hardware IOMMU (Input-Output Memory Management Unit) that isolates and remaps peripheral memory accesses. Until now, only the Raspberry Pi Foundation's downstream kernel has known how to configure and use it. The mainline Linux kernel — the reference tree at kernel.org that every major distribution eventually inherits from — has been missing an IOMMU driver for the Pi 5, which meant devices attached to the Pi 5's PCIe lane were operating without hardware-enforced memory boundaries and couldn't be safely passed through to virtual machines or containers.

Broadcom and community kernel developers have been working on a proper upstream driver for the past few kernel cycles. The current work-in-progress patchset, according to the reporting, is nearing merge-readiness. Once it lands in a stable mainline release, distributions that track mainline (Debian testing/unstable, Fedora, openSUSE Tumbleweed, Arch, most modern Ubuntu variants) will pick it up on their normal schedules — you're looking at ~6 weeks from mainline merge to appearing in a downstream stable release, depending on the distribution.

Why it matters

Three distinct classes of user get something different from this:

Casual users get a stability floor. Mainline support means the Pi 5 tracks upstream Linux more closely, benefits from every upstream security fix immediately, and has fewer distribution-specific quirks. If you're running Raspberry Pi OS, you were already on the vendor kernel and won't notice a change. If you run vanilla Debian or Ubuntu Server on a Pi 5, you'll see improved PCIe stability once the driver lands.

Homelab and self-hosting builders get proper virtualization. The Pi 5 with a PCIe HAT + NVMe becomes a plausible small-VM host — Proxmox, libvirt/KVM, or Firecracker can now safely pass through the NVMe controller to a guest VM without leaking DMA access to the rest of the system. That's the kind of thing that used to require an x86 mini-PC.

Kernel-adjacent developers get a proper reference implementation for ARM64 SBC IOMMU work. The Pi 5's IOMMU patchset serves as a template for other similar SoCs (Rockchip RK3588, Amlogic S928X, etc.) whose upstream story is even further behind.

Real-world numbers: what changes

With mainline IOMMU support enabled and a PCIe NVMe on the Pi 5:

The interesting rows are the ones where "Not supported" flips to "Supported." Those are the workloads the Pi 5 couldn't do before — small-scale VM hosting, running Coral USB or M.2 accelerators from a guest, safe multi-tenant NVMe over PCIe.

The builder angle: what this unlocks for Pi 5 PCIe projects

The Pi 5's exposed PCIe 2.0 x1 lane (upgradeable to PCIe 3.0 x1 with a device-tree override) is what makes the board interesting for enthusiasts. Common projects that benefit from mainline IOMMU:

NVMe boot + host storage. A Samsung 970 EVO Plus 250GB NVMe on a PCIe HAT replaces the microSD card entirely, giving you ~850 MB/s sequential and dramatically better random-access latency. IOMMU support means this NVMe can be safely passed to a guest VM or container without exposing the rest of the host's memory.

Coral / Hailo AI accelerators. A USB or M.2 Coral (or a Hailo-8 in the M.2 slot) is a common Pi 5 pairing for edge-inference projects. Proper IOMMU support means these accelerators can be passed through to a Docker container with hardware-enforced isolation.

Multi-drive NAS builds. A PCIe multi-M.2 HAT with two or four NVMes turns a Pi 5 into a low-power NAS. With mainline IOMMU support, ZFS or Btrfs on those drives runs on the upstream kernel with all its features (send/receive, encryption, snapshots) instead of the vendor kernel where some features lag.

Fibre / 2.5GbE upgrade. A Realtek RTL8125-based 2.5GbE PCIe card or an Intel i226-V slotted into the Pi 5's PCIe lane replaces the onboard 1GbE and takes advantage of the full ~200MB/s of PCIe bandwidth. Mainline IOMMU means these NICs can be passed to a firewall VM.

Bulk storage extension. Add a Crucial BX500 1TB SATA SSD via a USB 3.0-SATA adapter for cheap bulk storage alongside a fast NVMe. IOMMU doesn't affect USB storage directly, but the tidier system it makes possible is worth the mention — the NVMe becomes the boot/host drive, the SATA becomes the bulk store, and a VM guest can safely mount either.

Homelab virtualization host. A Pi 5 running Proxmox with 3–4 lightweight LXC containers (Pi-hole, Home Assistant, Jellyfin, Nextcloud) is a real deployment pattern in 2026. Proper IOMMU support removes the "you probably shouldn't do NVMe passthrough on a Pi" caveat that's been in every guide until now.

Is the Pi 4 still relevant?

Yes, and for many projects it's still the right buy. The Raspberry Pi 4 Model B 8GB at its current street price is the low-cost option for anything that doesn't specifically need the Pi 5's extra performance or PCIe lane. If you're doing:

• A Pi-hole install: Pi 4 is enough.
• A Home Assistant node: Pi 4 is enough.
• A retro-emulation station up to PS1/N64: Pi 4 is enough.
• A print server: Pi 4 is more than enough.

The Pi 5 wins when you specifically need NVMe boot, want PCIe expansion, run heavier workloads (Jellyfin transcoding, K3s single-node control plane, small-VM hosting), or want the CPU headroom for interactive Linux desktop use. The IOMMU work makes the Pi 5's PCIe story more compelling but doesn't retroactively obsolete the Pi 4.

When will it actually reach my distro?

Kernel work follows a predictable pipeline. Assuming the IOMMU patchset merges in the next kernel cycle (say, Linux 6.15):

• ~6 weeks after merge: it appears in the rolling-release distributions — Arch, openSUSE Tumbleweed, Fedora Rawhide.
• ~3 months after merge: it lands in the next Fedora point release, the next Ubuntu HWE stack, Debian testing.
• ~6 months after merge: it makes it to Debian stable via a -backports package, or the next Ubuntu LTS release.
• ~12 months after merge: it appears in every long-support commercial distribution.

For most homelab users the sub-3-month path via Fedora or Ubuntu HWE will be adequate. For distributions that lag mainline heavily (RHEL, SLE), expect it to appear when the next major version ships.

Common pitfalls when using Pi 5 PCIe

Even with IOMMU support landing, five things people trip over:

1. Wrong PCIe HAT. Some early HATs shipped with PCIe 2.0 clock issues. If a HAT is more than 12 months old, check for firmware/EEPROM updates before assuming NVMe throughput will match the spec sheet.
2. Forgetting the DT overlay for PCIe 3.0. The Pi 5 defaults to PCIe 2.0 x1 (~500 MB/s). Enable Gen 3 with dtoverlay=pcie-32bit-dma,pciex1_gen=3 in /boot/firmware/config.txt for the full ~850 MB/s.
3. Under-cooling the SoC when NVMe is running. The Pi 5's BCM2712 throttles at 85°C. NVMe HATs add heat but block the standard heatsink footprint. Use an active-cooler-compatible HAT or add a low-profile 30mm fan.
4. Under-powering the board. The Pi 5 official 5.1V/5A USB-C PD adapter is the reliable choice. Cheap 5V/3A adapters lead to voltage sag under NVMe load and manifest as random filesystem errors that get blamed on the SSD.
5. Booting from NVMe without a proper bootloader. The Pi 5 needs a recent bootloader EEPROM version (2024-04-01 or later) to boot directly from NVMe without a microSD present. Update via sudo rpi-eeprom-update -a before removing the SD card.

When to stay on the vendor kernel anyway

Mainline is the long-term direction, but the vendor kernel still ships first-party support for Pi-specific accessories (Camera Module 3, some HATs, the AI Kit). If your project depends on any of those, stay on Raspberry Pi OS for now and revisit mainline when the accessories you care about get proper upstream drivers. Mixing "mainline for the base kernel + vendor patches for the accessories" is possible but a maintenance headache.

Verdict matrix

Bottom line

Mainline IOMMU support isn't a feature that changes your Pi 5 today — it's a maturity milestone. It means the Pi 5 finally has proper upstream device isolation, which unlocks small-scale virtualization, safer PCIe device passthrough, and the kind of "just use the vanilla distro kernel" workflow that x86 mini-PCs have had for years. If your Pi 5 use case is casual, you'll never notice. If you're pushing the Pi 5 as a homelab node with NVMe storage and PCIe expansion, this is the missing piece that makes those builds first-class citizens.

Also useful: this is a reminder that the Pi ecosystem's slow-but-steady mainline story is finally catching up. Two years ago the Pi 5 shipped without upstream support for half its subsystems. Today, IOMMU is one of the last remaining gaps. The board is genuinely becoming a "real Linux SBC" that stands next to any comparable x86 mini-PC — including for the workloads that used to require an x86 IOMMU, like small VMs and PCI passthrough.

A worked example: Pi 5 as a Proxmox micro-host

Concretely, here's the workflow the mainline IOMMU driver enables. On a Pi 5 with an NVMe HAT + a 250GB drive, a Realtek 2.5GbE PCIe card in a passive splitter, and 8GB RAM:

1. Install Proxmox 8+ on the Pi 5 booted from NVMe.
2. Verify the IOMMU is exposed to userspace: dmesg | grep -i iommu should show groups.
3. Bind the NVMe controller to vfio-pci (yes, the same NVMe you're booted from — as long as the boot partition is on a separate device like an SD card).
4. Create a Debian 13 guest with the NVMe passed through directly. Inside the guest, lspci shows the NVMe as a first-class device with hardware-enforced DMA scope.
5. Run fio inside the guest — you'll see ~700 MB/s sequential read, near-bare-metal.

Two years ago you couldn't get past step 3 without segfaults or DMA errors because the IOMMU wasn't wired into the mainline kernel. That's the concrete unblock.

Common architectural question: why an SBC IOMMU at all?

The obvious question — why does a $80 SBC need a datacenter-style IOMMU? — is worth answering because it explains why the Pi 5 got one when the Pi 4 didn't. Modern ARM SoCs, even entry-level ones like the BCM2712, ship with IOMMU-capable memory controllers because the same IP block is used in phones and infotainment systems where multi-tenant isolation is a hard requirement. It's cheaper to design one memory-controller IP with IOMMU and disable it on low-end SKUs than to design two variants. So the Pi 5 got it for free at design time; what's been missing was the driver work to expose it to Linux.

Related guides

• Best GPU for local LLMs under $350
• Ollama vs LM Studio on an RTX 3060 12GB
• Open-weight models caught up to frontier — what to run on a 12GB GPU

Citations and sources

• Phoronix — Linux kernel news and Raspberry Pi coverage
• Raspberry Pi 5 — official product page
• Linux kernel — mainline reference tree