Microsoft livre le pilote IOMMU para-virtualisé de Hyper-V, trois ans après son RFC
Le 11 octobre 2026, le pilote « hv-iommu-guest » a été placé dans la branche -next du sous-système IOMMU pour Linux 7.4 : il apporte enfin la protection DMA dans le noyau et l’attribution de périphériques via VFIO aux machines virtuelles Linux hébergées sur Hyper-V. Les administrateurs de parcs Hyper-V peuvent préparer la migration, le noyau stable étant attendu fin décembre.
11 octobre 2026. Microsoft a placé un nouveau pilote dans la branche -next du sous-système IOMMU du noyau Linux, en vue du cycle 7.4. Un pilote para-virtualisé. hv-iommu-guest apporte la protection DMA dans le noyau et l’attribution de périphériques via VFIO aux machines virtuelles Linux hébergées sur Hyper-V. Trois ans d’attente. Les premières séries de correctifs (RFC) remontent à décembre 2023. Pourquoi c’est important : c’est la brique qui manquait pour que les invités Linux sous Hyper-V puissent assigner des NVMe ou des accélérateurs Intel DSA à un invité avec les mêmes garanties d’isolation que sur un hyperviseur KVM.
Ce qu’est un IOMMU, et pourquoi Hyper-V en manquait
Un IOMMU — Input-Output Memory Management Unit — est l’équivalent, pour les périphériques, de la MMU qui traduit les adresses mémoire du processeur. Il remappe les accès DMA d’un périphérique vers la mémoire, de sorte qu’un périphérique ne peut lire ou écrire que dans la zone qui lui a été assignée. Sans lui, un périphérique qui accède directement à la mémoire peut, volontairement ou par bug, lire ou corrompre la mémoire de l’hôte ou d’un autre invité — c’est le principe des attaques DMA, longtemps la bête noire des ports Thunderbolt et FireWire.
Sur un hyperviseur de type 1 comme KVM, la machine virtuelle hérite d’un IOMMU réel, exposé par le matériel, qui assure cette isolation quand on lui assigne un périphérique. Hyper-V a longtemps fonctionné autrement : ses invités Linux ne disposaient pas d’un accès direct à un IOMMU matériel, ce qui compliquait l’attribution de périphériques et la protection DMA dans le noyau. Le nouveau pilote comble précisément cette lacune en proposant une interface para-virtualisée : l’invité ne parle plus au matériel directement, mais à l’hyperviseur, qui se charge de la traduction.
C’est la différence entre « virtuel » et « para-virtualisé » qu’il faut saisir. Un invité pleinement virtualisé croit posséder un IOMMU matériel. Un invité para-virtualisé sait qu’il est virtualisé et collabore avec l’hyperviseur via une interface légère, ce qui évite d’émuler un matériel coûteux tout en gardant les garanties d’isolation.
Ce que le pilote apporte : DMA protégé et VFIO
Concrètement, Microsoft décrit deux gains. D’abord, « les invités Linux sur Hyper-V bénéficient d’une protection DMA dans le noyau pour les périphériques assignés à l’invité » — autrement dit, le noyau peut enfin isoler un périphérique assigné au lieu de lui faire confiance. Ensuite, le pilote « permet l’attribution de périphériques à l’espace utilisateur de l’invité, par exemple via VFIO ». VFIO est le framework du noyau qui expose un périphérique à un processus utilisateur avec les garanties de l’IOMMU : c’est la porte d’entrée des cas d’usage comme le passthrough de NVMe, les piles réseau haute performance type DPDK, ou l’accès direct à un accélérateur.
La portée est matérielle plutôt large. Le pilote para-virtualisé fonctionne aussi bien sur les systèmes à Intel VT-d que sur ceux à AMD IOMMU : l’isolation repose sur les capacités du matériel de l’hôte, que l’hyperviseur relaye à l’invité. Microsoft indique avoir validé le pilote en assignant des périphériques NVMe à un invité, et, côté Intel, en testant l’assignation des accélérateurs DSA (Data Streaming Accelerator) à des machines virtuelles Linux.
L’activation passera par une option de configuration du noyau, HYPERV_PVIOMMU, à activer à la compilation. Pour l’utilisateur final d’une distribution, cela se traduira par un module disponible — puis par la possibilité, dans l’invité, d’utiliser les outils VFIO habituels au lieu de contournements propres à Hyper-V.
Trois ans de gestation, de décembre 2023 à Linux 7.4
Le chemin de ce pilote illustre la lenteur — et la rigueur — du processus amont du noyau. Les premiers correctifs RFC sur cette fonctionnalité remontent à décembre 2023. Il aura donc fallu près de trois ans pour que le code passe de la proposition initiale à la branche -next du sous-système IOMMU, où il attend désormais l’ouverture de la fenêtre de fusion de Linux 7.4.
Le calendrier annoncé tient en deux jalons. La fenêtre de fusion (merge window) de Linux 7.4 s’ouvre plus tard ce mois-ci ; le noyau stable 7.4 est attendu autour de la fin décembre 2026, soit trois ans après les premiers correctifs. Jusqu’à l’ouverture de la fenêtre, le code vit dans la branche next du dépôt IOMMU — la zone où les mainteneurs valident qu’il ne casse rien avant de le proposer à Linus Torvalds.
Cette durée n’est pas un signe d’abandon, mais de maturation. Un pilote IOMMU touche à l’isolation mémoire, le territoire le plus sensible du noyau : une erreur de remappage est une faille de sécurité, pas un simple plantage. Le fait que le code arrive en -next avec des tests sur NVMe et DSA montre que les prérequis de validation sont désormais remplis.
Ce que ça change pour les charges de travail
Concrètement, le pilote débloque trois cas d’usage que les invités Linux sous Hyper-V traitaient jusqu’ici avec des compromis. Le passthrough NVMe d’abord : assigner un disque directement à un invité, sans passer par la couche de stockage virtuel, améliore la latence et libère le CPU de l’hôte. Ensuite, les piles réseau haute performance : VFIO est le socle de DPDK, qui traite des millions de paquets par seconde en espace utilisateur. Enfin, l’accès aux accélérateurs — Intel DSA pour la copie mémoire, ou à terme des GPU — pour les charges d’inférence ou de compression.
Le bénéfice n’est pas que la performance : c’est l’isolation. Avec un IOMMU fonctionnel, un périphérique assigné est confiné à sa zone mémoire, et un bug ou un périphérique malveillant ne peut plus lire la mémoire de l’hôte ou des autres invités. C’est ce qui transforme l’attribution de périphérique d’une fonctionnalité de confort en une pratique défendable face à un audit de sécurité.
Ce que ça dit de Microsoft et du noyau Linux
L’épisode est aussi un repère dans la relation entre Microsoft et Linux. Microsoft est depuis des années l’un des contributeurs réguliers du noyau, d’abord pour faire tourner Linux en invité de première classe sur Azure et Hyper-V, puis plus largement. Un pilote IOMMU para-virtualisé n’est pas un patch cosmétique : c’est un morceau d’infrastructure de bas niveau, maintenu sur des années, au bénéfice direct de ses clients qui virtualisent des charges Linux sur Hyper-V.
Pour les exploitants, le message est double. D’une part, la convergence continue : les invités Linux sous Hyper-V se rapprochent, fonctionnalité par fonctionnalité, de ce que KVM offre depuis longtemps en matière d’attribution de périphériques. D’autre part, la protection DMA cesse d’être un luxe réservé aux déploiements bare-metal ou KVM : elle devient la norme attendue d’un hyperviseur, y compris pour les machines virtuelles Windows et Linux mélangées sur le même hôte.
Verdict
Si vous gérez un parc Hyper-V avec des invités Linux, notez le jalon dans votre veille : le pilote arrive en Linux 7.4, stable fin décembre 2026, et ne demande aucune action immédiate tant que la distribution n’embarque pas le noyau — mais préparez vos procédures d’attribution de périphériques (NVMe, accélérateurs) pour basculer sur VFIO standard quand ce sera disponible. Si vous êtes en cours de migration Hyper-V vers KVM, ce pilote réduit l’un des arguments de la bascule : l’écart d’isolation se referme. Si vous ne virtualisez pas sur Hyper-V, retenez la mécanique générale : l’isolation DMA devient un prérequis silencieux de toute virtualisation sérieuse, et son absence est un risque que peu d’équipes auditent encore.