Short answer: An IOMMU is the memory-protection unit that sits between PCIe devices and system RAM — it translates and restricts the addresses a peripheral can touch. The Pi 5 has the hardware; until this week it lacked mainline kernel support. The pending patches, tracked on Phoronix, enable safer PCIe device passthrough, cleaner virtualization, and — modestly — better throughput on some NVMe HAT and high-bandwidth network workloads. It does not backport to the Pi 4.
In brief — 2026-07-19. IOMMU driver work for the Raspberry Pi 5's memory-management arrangement is under review for mainline inclusion. The change enables device-level memory isolation for the board's PCIe interface, which in turn permits guarded PCIe passthrough into virtual machines and eliminates certain classes of driver bounce-buffer copies. The scope is Pi 5 silicon specifically; the Pi 4 uses a different arrangement and does not benefit from this work.
What happened — the driver work landing in mainline
Coverage on Phoronix this week highlights a driver series targeting the Pi 5's IOMMU (input-output memory management unit) for mainline Linux inclusion. The patches add first-class support in the kernel's IOMMU subsystem for the Broadcom BCM2712's memory arrangement, exposing the hardware capability that the SoC has shipped with since launch but that the mainline kernel could not previously drive.
An IOMMU, at the hardware level, does for peripherals what a CPU's memory management unit does for processes. When a device — an NVMe drive on a PCIe HAT, a network card, a GPU — wants to DMA data into or out of system RAM, the IOMMU translates the device's view of memory (I/O virtual addresses) into physical addresses, and enforces that the device can only touch the memory the kernel explicitly authorized. Without an IOMMU, a peripheral has raw physical-memory access; a bug or a malicious device can write anywhere. With one, the device is confined to its allowed regions the same way a process is confined to its address space.
Where this sits in mainline review, per the linked coverage, is late-cycle: the patches have been through several revision rounds, address reviewer feedback, and appear on track for inclusion in an upcoming kernel release. Vendor-kernel adoption — the Raspberry Pi OS default kernel — typically lags mainline by a release or two, so users who want the feature early will run a mainline or distribution kernel (Debian, Fedora, Arch ARM) on the board.
Why it matters — isolation, passthrough, and cleaner drivers
Three distinct benefits, all of them modest individually but collectively meaningful:
One, device isolation. A misbehaving PCIe device — a flaky NVMe HAT, a cheap capture card, a network adapter with a firmware bug — can currently, in principle, corrupt kernel memory on the Pi 5. With the IOMMU active, the same misbehavior gets bounded to the memory the kernel granted the device. That is the same protection you have had on x86 workstations for years; it is arriving on this class of ARM SBC now.
Two, PCIe passthrough for virtualization. The ability to grant a virtual machine direct control of a physical PCIe device — an NVMe drive, a USB controller, a network adapter — depends on the IOMMU. Without one, the hypervisor either denies passthrough entirely (safer) or emulates the device (slow). With one, the VM gets bare-metal-adjacent I/O performance and the host stays isolated. On a Pi 5 with 8GB of RAM, this makes the board a plausible host for a single lightweight VM appliance — a router, a network sensor, a small self-hosted service — with hardware-passed-through storage.
Three, driver simplification. Certain older or memory-limited peripherals cannot DMA to the full 64-bit physical address range. Without an IOMMU, the kernel bounces those transfers through a lower-memory staging buffer, which costs CPU cycles and memory bandwidth. With one, the IOMMU rewrites the device's addresses on the fly, no bounce needed. On sustained high-throughput workloads — a Pi 5 with an NVMe HAT serving files, or a 2.5Gbit network adapter under heavy load — expect a small but measurable reduction in CPU overhead.
What carries over to the Pi 4
Very little. The Pi 4's BCM2711 uses a different memory-management arrangement, and its PCIe interface is more limited than the Pi 5's. The patches under review are Pi 5-specific and do not backport meaningfully. That is fine: the Raspberry Pi 4 Computer Model B 8GB remains an outstanding platform for homelab, retro-emulation, sensor-hub, and light-web-hosting work, and none of those workloads touch the capability being added here. If your Pi 4 is doing anything with a USB SSD or the built-in GbE, it will continue doing exactly what it did last week, just as well.
For readers with a Pi 4 running as a small file server: pair it with a Crucial BX500 1TB SATA SSD over a USB 3.0 adapter and you have a perfectly reasonable NAS for photos, backups, and small media libraries. The Pi 4's USB 3.0 bandwidth caps sequential throughput well below what SATA can theoretically deliver, but for the typical NAS workload — mixed reads and writes, small files — it is not the bottleneck.
For readers with a Raspberry Pi Zero W as a starter or side project, none of this applies at all. Zero W is a different SoC generation, no PCIe, no IOMMU concept.
Do you need a mainline kernel, or will the Pi OS default get it?
Mainline lands first. Vendor kernels — Raspberry Pi OS, Ubuntu's Pi image — pick changes up on their own cadence after the mainline patches stabilize. For most users, the right move is to wait: run Raspberry Pi OS's default kernel and let the feature arrive when the distribution ships it, likely within one or two kernel updates.
For users who want the capability now, the paths are:
- Mainline kernel on your existing OS. Raspberry Pi OS can run a mainline kernel via
rpi-update(with caveats — this is not the "safe" update path) or by building your own from source. The kernel.org documentation is the reference for build steps and configuration options. - Debian / Fedora / Arch ARM. These distributions ship mainline kernels earlier than the vendor. If you are comfortable with them, that is a cleaner path than patching the Pi OS kernel.
- Wait one to three months. For non-urgent use, this is the sensible choice. The Raspberry Pi OS team has a good record of picking up important kernel features once they stabilize.
Does this make the Pi 5 a viable virtualization host?
Better than before, still limited. IOMMU + PCIe passthrough removes one structural blocker to running a real hypervisor stack on the board. It does not remove the others: memory capacity caps at 8GB (or 16GB on newer Pi 5 SKUs), single-board I/O bandwidth is shared across every peripheral, and the SoC's performance ceiling — while very good for a $100 board — is still well below a proper x86 mini-PC.
A realistic Pi 5 virtualization use case, with the new kernel work landed, looks like: one lightweight VM (say, an OPNsense router or a pi-hole VM) with a network adapter passed through, plus a couple of containers for auxiliary services. That is genuinely useful for a home-lab appliance, especially in a small-form-factor low-power role. What it is not is a replacement for a dedicated hypervisor host — for that, spend the money on a small x86 mini-PC and get 32GB of RAM, several NVMe slots, and a proper server-class network interface.
The Raspberry Pi documentation has the official hardware capabilities and current OS support details; check the release notes when you upgrade your kernel or OS to confirm the IOMMU support has landed in your specific stack.
The bigger picture — mainline support for SBCs is quietly improving
The Pi 5 IOMMU work is one of a series of quiet but important mainline-kernel improvements for ARM single-board computers over the past two years. Better clock management, better USB power negotiation, better GPU driver support, better display pipelines. None of these are individually headline-worthy. Collectively they mean an SBC bought in 2026 has a much better software story out of the box than the same class of board in 2020.
For makers, that means fewer weekends spent hunting for the right kernel branch or the right out-of-tree driver, and more time on the actual project. For homelabbers, it means SBCs are becoming credible platforms for a broader class of workloads — including a few that used to require an x86 host. For everyone, it lowers the ambient-frustration cost of building on this hardware.
The pattern also matters for buying decisions. When mainline support for a board is good, that board keeps working long after the vendor's own kernel branch stagnates. The Pi 4 has excellent mainline support today, which is a large part of why a five-year-old design is still a rational purchase for new projects. Boards from vendors who kept their support out-of-tree — several Rockchip and Allwinner SBCs from the same era — have a much messier story and often require running a specific vendor-blessed kernel to work at all. Every mainline patch that lands is one less reason to worry that your board will become an orphan.
When to actually upgrade your board
If you already have a Pi 4 doing useful work, this news is not a reason to upgrade. The IOMMU patches do not affect it, and the specific workloads that benefit — hardware-passthrough virtualization, high-throughput NVMe over PCIe — are not things a Pi 4 is doing anyway. A Pi 4 is a great home server, a great retro-emulation host, a great sensor hub, and none of those change.
If you are shopping for a new board today and cannot decide between the Pi 4 and the Pi 5, the IOMMU work is one more small argument for the Pi 5. It is not the biggest argument — that is still the higher CPU performance, better memory bandwidth, and PCIe interface. But if any of your planned use cases involve PCIe HATs or virtualization, add "the IOMMU support is landing" to the reasons to buy the newer board.
What to do this week if you own a Pi 5
Practical checklist for Pi 5 owners who want to be ready when the feature lands in their default kernel:
- Update to the latest Raspberry Pi OS so you are on the current-cycle kernel base. That ensures you pick up the feature in the first vendor kernel that includes it.
- If you are running an NVMe HAT, note which model. Some HATs are more sensitive to kernel changes than others; check the vendor's compatibility notes.
- If you are considering PCIe passthrough into a VM, evaluate KVM/QEMU with
vfio-pcion the mainline path. This is the toolchain that the new IOMMU support unlocks. It works on x86 today; ARM/Pi support is what is arriving. - Benchmark your NAS or homelab workload now so you have a "before" number to compare against after the kernel update.
fioon the storage HAT andiperf3on the network interface give you the two most relevant measurements. - Keep a backup on a separate physical drive, as always. Kernel updates on ARM SBCs are usually smooth, but if the update ships during a busy month for the maintainers, you want a recovery path.
For anyone using a Pi 5 as a display appliance, a Kubernetes worker node in a cluster of Pis, a HomeAssistant server, or a Pi-hole DNS host — none of these workloads meaningfully change. IOMMU support is a foundational plumbing improvement, not a user-visible feature. You will not notice the day it lands unless you are running one of the specific workloads it enables.
Bottom line
Small patch, meaningful improvement. Pi 5 owners doing anything with PCIe HATs, homelab virtualization, or performance-sensitive I/O should watch for this feature landing in their default kernel over the coming months. Pi 4 owners can carry on unchanged — the feature does not apply, and the Pi 4's existing workloads are not the ones that would benefit anyway. Zero W owners can carry on further unchanged. The best purchase you can make in response to this news is nothing — if you already own the board, wait for the kernel update; if you do not, buy a Pi 5 for the same reasons you would have bought one last month.
Related guides
- Open WebUI on a Raspberry Pi 4, Inference on an RTX 3060
- Build a Wall-Mounted Raspberry Pi 4 Arcade Cabinet
- Best Storage Upgrades for Gaming and Retro PCs in 2026
Citations and sources
- Phoronix — Pi 5 IOMMU driver series coverage and mainline review status (accessed July 2026).
- Raspberry Pi — official documentation — Pi 4 and Pi 5 hardware capabilities and OS support (accessed July 2026).
- Linux kernel documentation — reference for the IOMMU subsystem and kernel build steps (accessed July 2026).
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
