Microsoft ships a para-virtualized IOMMU driver for Hyper-V, three years after its RFC
On October 11, 2026, the ’hv-iommu-guest’ driver landed in the IOMMU subsystem’s -next branch for Linux 7.4, bringing in-kernel DMA protection and VFIO device assignment to Linux guests running on Hyper-V. Administrators of Hyper-V fleets can start planning the migration, with the stable kernel expected in late December.
October 11, 2026. Microsoft placed a new driver in the -next branch of the IOMMU subsystem, targeting the Linux 7.4 cycle. A para-virtualized driver. hv-iommu-guest brings in-kernel DMA protection and VFIO device assignment to Linux guests running on Hyper-V. Three years in the making. The first request-for-comments (RFC) patches date back to December 2023. Why it matters: this is the missing piece for Hyper-V Linux guests to assign NVMe devices or Intel DSA accelerators with the same isolation guarantees as a KVM hypervisor.
What an IOMMU is, and why Hyper-V lacked one
An IOMMU — Input-Output Memory Management Unit — is to peripherals what the MMU is to the CPU. It remaps a device’s DMA accesses into memory so that a device can only read and write the region assigned to it. Without one, a device that talks to memory directly can, deliberately or by bug, read or corrupt the memory of the host or another guest — the principle behind DMA attacks, long the bane of Thunderbolt and FireWire ports.
On a type-1 hypervisor like KVM, the virtual machine inherits a real IOMMU exposed by the hardware, which provides that isolation when a device is assigned to it. Hyper-V has long worked differently: its Linux guests had no direct access to a hardware IOMMU, which complicated device assignment and in-kernel DMA protection. The new driver fills exactly that gap by offering a para-virtualized interface: the guest no longer talks to the hardware directly, but to the hypervisor, which handles the translation.
The distinction between “virtual” and “para-virtualized” matters here. A fully virtualized guest believes it owns a hardware IOMMU. A para-virtualized guest knows it is virtualized and cooperates with the hypervisor through a lightweight interface — avoiding the cost of emulating hardware while preserving the isolation guarantees.
What the driver brings: protected DMA and VFIO
Microsoft describes two gains. First, “Linux guests on Hyper-V enjoy in-kernel DMA protection for devices assigned to the guest” — the kernel can finally isolate an assigned device instead of trusting it. Second, the driver “allows for device assignment to the guest user-space such as via VFIO”. VFIO is the kernel framework that exposes a device to a user-space process under IOMMU guarantees: it is the entry point for NVMe passthrough, high-performance network stacks like DPDK, or direct access to an accelerator.
The hardware reach is broad. The para-virtualized driver works on both Intel VT-d and AMD IOMMU systems: isolation rides on the host hardware’s capabilities, which the hypervisor relays to the guest. Microsoft says it validated the driver by assigning NVMe devices to a guest, and, on the Intel side, by testing assignment of DSA (Data Streaming Accelerator) devices to Linux VMs.
Enablement will go through a kernel configuration option, HYPERV_PVIOMMU, set at compile time. For the end user of a distribution, that translates into an available module — and then the ability, inside the guest, to use the usual VFIO tooling instead of Hyper-V-specific workarounds.
Three years of gestation, from December 2023 to Linux 7.4
The path of this driver illustrates both the slowness and the rigor of the upstream kernel process. The first RFC patches on this feature date back to December 2023. It has therefore taken nearly three years for the code to move from the initial proposal to the -next branch of the IOMMU subsystem, where it now waits for the Linux 7.4 merge window to open.
The announced timeline has two milestones. The Linux 7.4 merge window opens later this month; the stable 7.4 kernel is expected around the end of December 2026, three years after the first patches. Until the window opens, the code lives in the next branch of the IOMMU repository — the place where maintainers validate that it breaks nothing before proposing it to Linus Torvalds.
That duration is not a sign of abandonment, but of maturation. An IOMMU driver touches memory isolation, the most sensitive territory of the kernel: a remapping bug is a security vulnerability, not merely a crash. The fact that the code arrives in -next with NVMe and DSA testing shows the validation prerequisites are now met.
What this changes for real workloads
Concretely, the driver unlocks three use cases that Linux guests under Hyper-V previously handled with compromises. NVMe passthrough first: assigning a disk directly to a guest, bypassing the virtual storage layer, improves latency and frees host CPU. Then high-performance networking: VFIO is the foundation of DPDK, which processes millions of packets per second in user space. Finally, accelerator access — Intel DSA for memory copy, or eventually GPUs — for inference or compression workloads.
The benefit is not just performance: it is isolation. With a working IOMMU, an assigned device is confined to its memory region, and a bug or a malicious device can no longer read the host’s or another guest’s memory. That is what turns device assignment from a convenience feature into a practice that stands up to a security audit. For storage and database teams, NVMe passthrough on Hyper-V closes a long-standing gap: the choice between raw disk latency and the operational convenience of a managed hypervisor is no longer binary. The same logic applies to any workload whose performance is dominated by direct hardware access.
What this says about Microsoft and the Linux kernel
The episode is also a marker in the relationship between Microsoft and Linux. Microsoft has for years been a regular kernel contributor, first to make Linux a first-class guest on Azure and Hyper-V, then more broadly. A para-virtualized IOMMU driver is not a cosmetic patch: it is a piece of low-level infrastructure, maintained over years, in direct service of its customers who virtualize Linux workloads on Hyper-V.
For operators, the message is twofold. On one hand, convergence continues: Linux guests under Hyper-V are closing, feature by feature, the gap with what KVM has long offered for device assignment. On the other, DMA protection stops being a luxury reserved for bare-metal or KVM deployments: it becomes the expected baseline of a hypervisor, including for mixed Windows and Linux virtual machines on the same host.
None of this lands on servers overnight. The driver sits in the -next branch until the merge window, then in a release candidate, then in stable 7.4 at the end of December. Distributions will pick it up on their own cadence, and enterprise kernels may trail by months. The practical effect is that most Hyper-V shops will not see in-kernel DMA protection until 2027 — which makes the present the right time to audit what is currently assigned without an IOMMU.
Verdict
If you manage a Hyper-V fleet with Linux guests, log the milestone in your watch list: the driver arrives in Linux 7.4, stable in late December 2026, and requires no immediate action until your distribution ships the kernel — but prepare your device-assignment procedures (NVMe, accelerators) to switch to standard VFIO when it becomes available. If you are mid-migration from Hyper-V to KVM, this driver removes one of the arguments for the switch: the isolation gap is closing. If you do not virtualize on Hyper-V, take away the general mechanics: DMA isolation is becoming a silent prerequisite of any serious virtualization, and its absence is a risk few teams audit today.