Microsoft has submitted a new paravirtualized IOMMU driver to the Linux kernel, queued in the IOMMU subsystem's -next integration branch ahead of the 7.4 merge window. If it lands as expected — subject to the usual subsystem pull — Linux guest virtual machines running on Hyper-V will gain a proper paravirtualized path for address translation, unlocking PCI passthrough, SR-IOV, VFIO and nested virtualisation workflows that have historically been awkward or impossible inside Hyper-V guests.
The submission was reported by Phoronix as it was queued into iommu/next.
What a paravirtualized IOMMU actually changes
Today, when a Linux guest wants to perform direct device assignment or expose virtual functions to workloads inside the VM, it typically needs a hardware IOMMU (Intel VT-d or AMD-Vi) to be visible and functional from within that guest. On a bare-metal host, that is the norm. Inside a Hyper-V VM, it has long been a gap: without an IOMMU abstraction in the guest, features like VFIO-based device passthrough, SR-IOV virtual function exposure, and nested virtualisation setups that rely on address-translation support either failed outright or required brittle workarounds.
A paravirtualized IOMMU solves this by having the hypervisor — in this case Hyper-V — provide the address-translation services in software rather than relying on passthrough of physical IOMMU hardware. The guest's kernel sees a standards-compliant IOMMU interface, and everything built on top of it (VFIO, virtio-sriov, device assignment) behaves as it would on physical iron. For enterprises running performance-sensitive or device-dependent workloads in Linux VMs, this is the difference between "not supported" and "works out of the box."
Why this matters in a Hyper-V and Azure world
Microsoft is, by its own account, the largest contributor of code to the Linux kernel — and the company's earlier milestone of becoming the single largest corporate contributor arrived around the time of its 2018 GitHub acquisition. This driver fits a well-established pattern: Microsoft upstreaming the kernel glue its own platform needs, so that guest operating systems — the majority of which on Azure are Linux — work properly on Microsoft infrastructure without downstream patches.
Hong Kong enterprises with significant Linux estates on Azure or on-premises Hyper-V clusters stand to benefit directly wherever Microsoft enables the host-side support. Cloud migrations that were previously constrained by device-passthrough or SR-IOV requirements inside guests become simpler to plan. Container and NFV-style workloads that lean on VFIO gain a credible path on Microsoft's stack, not just on KVM. And for teams standardising on Hyper-V across private and public cloud footprints, parity with KVM's long-standing paravirtualized IOMMU support closes a persistent feature gap.
Availability and next steps
The driver is currently queued in iommu/next and is targeted at the upcoming Linux 7.4 cycle, assuming the IOMMU maintainers carry it through the normal -next integration and it survives the merge window unmodified. Kernel and infrastructure teams tracking the 7.4 roadmap should watch the eventual iommu/next pull request for confirmation, and — importantly — watch for the corresponding host-side Hyper-V enablement, which will be gated by Microsoft on both the hypervisor version and the Azure or System Center rollout schedule.
Administrators planning Linux-on-Hyper-V deployments that depend on device passthrough or SR-IOV should treat this as a milestone to track rather than a feature to build against today: the guest-side driver is only half of the equation, and real-world availability will depend on when Microsoft switches on support in its own hosts.
Microsoft 已向 Linux kernel 提交一套全新的半虛擬化（paravirtualized）IOMMU 驅動程式，並已排入 IOMMU subsystem 的 -next 整合分支，為 7.4 merge window 作好準備。倘若如預期般順利合入——即須經 subsystem 正常 pull——在 Hyper-V 上運行的 Linux guest 虛擬機將獲得一條專屬的半虛擬化地址轉換（address translation）路徑，從而解鎖 PCI passthrough、SR-IOV、VFIO 以及 nested virtualisation 等工作流程；這些功能歷來在 Hyper-V 虛擬機內不是難以使用，就是根本無法運作。
是次提交由 Phoronix 報導，當時驅動程式已排入 iommu/next。
半虛擬化 IOMMU 究竟改變了甚麼
現時，當 Linux guest 需要進行直接設備指派（device assignment），或在虛擬機內向工作負載開放 virtual function 時，一般必須有一個硬件 IOMMU（Intel VT-d 或 AMD-Vi）能從 guest 內部被識別並正常運作。在 bare-metal 主機上，這是常態。但在 Hyper-V 虛擬機內，這一直是個缺口：由於 guest 內沒有 IOMMU 抽象層，VFIO 設備 passthrough、SR-IOV virtual function 暴露，以及依賴地址轉換支援的 nested virtualisation 設定，往往直接失敗，或需要脆弱不堪的 workaround。
半虛擬化的 IOMMU 正是為解決此問題而生：由 hypervisor（此處即 Hyper-V）以軟件方式提供地址轉換服務，而非依賴物理 IOMMU 硬件的 passthrough。guest 的 kernel 會看到一個符合標準的 IOMMU interface，其上建立的一切（VFIO、virtio-sriov、device assignment）均會如在物理硬件上般正常運作。對於在 Linux 虛擬機內運行效能敏感或依賴設備的工作負載的企業而言，這就是「不支援」與「開箱即用」之間的分別。
為何在 Hyper-V 及 Azure 的世界裏至關重要
根據 Microsoft 自己的說法，如今 Linux kernel 的最大代碼貢獻者正是 Microsoft——而公司成為單一最大企業貢獻者的里程碑，大約出現於 2018 年收購 GitHub 之時。這套驅動程式符合一個久經驗證的模式：Microsoft 將自身平台所需的 kernel 膠水代碼（glue）提交至主線，令 guest 作業系統——Azure 上絕大多數均為 Linux——毋須依賴 downstream patch，便能在 Microsoft 基礎設施上正常運作。
對於在 Azure 或本機 Hyper-V 叢集（on-premises Hyper-V clusters）上擁有大量 Linux 資產的香港企業而言，只要 Microsoft 在主機端啟用相應支援，便能直接受惠。過往受制於 guest 內設備 passthrough 或 SR-IOV 要求的雲端遷移計劃，將會變得更為簡單。依賴 VFIO 的容器及 NFV 類工作負載，亦能在 Microsoft 的技術堆疊上獲得一條可行路徑，而不僅局限於 KVM。至於在私有雲及公有雲環境統一採用 Hyper-V 的團隊，與 KVM 長期具備的半虛擬化 IOMMU 支援看齊，亦填補了一項長久存在的功能差距。
可用性及後續步驟
該驅動程式目前排入 iommu/next，目標是即將到來的 Linux 7.4 開發週期，前提是 IOMMU maintainers 將其納入正常的 -next 整合流程，且在 merge window 期間未經改動而順利通過。追蹤 7.4 路線圖的 kernel 及基礎設施團隊，應留意最終的 iommu/next pull request 以作確認——更重要的是，須留意相應的主機端 Hyper-V 啟用進展，該等支援將由 Microsoft 以 hypervisor 版本及 Azure 或 System Center 發佈時間表作為啟用條件。
計劃部署依賴設備 passthrough 或 SR-IOV 的 Linux-on-Hyper-V 環境的管理員，應將此事視為一個需要持續追蹤的里程碑，而非現階段便可據以規劃的功能：guest 端驅動程式只是方程式的一半，實際可用時間將取決於 Microsoft 何時在自家主機上啟用相關支援。