IOMMU expliqué : l’interrupteur BIOS qui rend (ou casse) le passthrough GPU

Ce qu’est réellement l’IOMMU (et pourquoi le passthrough GPU en a besoin)

L’IOMMU est une unité de gestion de mémoire pour les périphériques. Les CPU disposent d’un MMU qui traduit les adresses virtuelles en adresses physiques,
garantissant l’isolation entre processus. L’IOMMU effectue le même type de traduction et d’isolation, mais pour les requêtes DMA (Direct Memory Access)
provenant de périphériques PCIe comme les GPU, cartes réseau, contrôleurs NVMe et HBA.

Sans IOMMU, un périphérique effectuant du DMA peut simplement dire : « Je veux lire/écrire la mémoire physique à l’adresse X. »
Si ce périphérique est bogué, mal configuré ou compromis, il peut corrompre le noyau hôte, la mémoire d’une autre VM ou une page contenant des secrets.
Avec une IOMMU, l’hôte installe une table de traduction pour que le périphérique ne voie que la mémoire que l’hôte lui destine.

Le passthrough GPU en une phrase

Le passthrough GPU signifie que le pilote de la VM communique avec un vrai GPU via PCIe comme s’il possédait le matériel, tandis que l’hyperviseur utilise des mappages IOMMU
pour confiner les DMA du périphérique à la mémoire de cette VM.

Pourquoi « ça démarre » n’est pas une preuve

Une VM peut parfois démarrer avec un GPU passé en passthrough même lorsque des fonctionnalités IOMMU clés sont manquantes ou mal configurées, surtout si la charge
n’engendre pas immédiatement des schémas DMA intensifs. Puis vous lancez un jeu, un job CUDA ou un reset de pilote — et l’hôte déraille.
Ce n’est pas une mauvaise chance. C’est la physique du DMA rencontrant une frontière d’isolation incomplète.

Les couches que vous déboguez réellement

• Firmware : réglages BIOS/UEFI (VT-d / AMD-Vi), SR-IOV, « Above 4G decoding », « Resizable BAR ».
• Noyau : IOMMU activé, remappage d’interruptions activé, mode de traduction DMA (strict vs lazy).
• Topologie PCIe : ports racine, ACS, et si les périphériques se retrouvent dans des groupes IOMMU séparables.
• Liaison des pilotes : pilote hôte vs pilote VFIO, et qui prend le GPU au démarrage.
• Configuration hyperviseur : arguments QEMU/KVM, OVMF vs SeaBIOS, type de machine (q35 a de l’importance).

Si vous traitez l’IOMMU comme « une chose de virtualisation », vous continuerez à faire des modifications par cargo-cult jusqu’à ce que ça marche… puis ça cassera.
Traitez-la comme un primitif d’isolation avec des états observables, et vous obtiendrez des résultats prévisibles.

Faits et historique utiles pour les réunions

Voici des points concrets, pas des anecdotes, qui aident à expliquer pourquoi l’IOMMU existe et pourquoi il est encore étonnamment facile de le mal configurer :

1. Le DMA précède la virtualisation moderne de plusieurs décennies. Les premiers périphériques haute performance utilisaient le DMA pour éviter des copies CPU — excellent pour la vitesse, gênant pour l’isolation.
2. L’IOMMU répond au chaos du bus partagé. À mesure que PCI puis PCIe se sont généralisés, le modèle « faire confiance à tout périphérique » est devenu un risque pour la sécurité et la fiabilité.
3. Intel l’appelle VT-d ; AMD l’appelle AMD-Vi. Différentes marques, même idée : remapper le DMA des périphériques via des tables de traduction.
4. Les OS modernes supposent de plus en plus l’existence d’une IOMMU. Ce n’est pas seulement pour les VM ; c’est aussi utilisé pour durcir le noyau et l’assignation sûre des périphériques.
5. Le remappage d’interruptions fait aussi partie de l’histoire. Ce n’est pas que le DMA. Les périphériques génèrent aussi des interruptions ; le remappage aide à prévenir des cas de mauvais routage ou d’injection d’interruptions.
6. ACS (Access Control Services) n’est pas un « plus agréable ». ACS influe sur l’isolation du trafic PCIe entre endpoints ; un ACS faible signifie souvent « tout est dans un seul groupe IOMMU ».
7. Les fabricants de GPU n’étaient pas enthousiastes au début. Le passthrough initial était capricieux parce que les GPU grand public et leurs pilotes n’étaient pas conçus pour une assignation en VM.
8. Above 4G decoding compte car les GPU utilisent beaucoup d’adresses mémoire. Les gros mappages de BAR et les plateformes modernes vous poussent vers des fonctionnalités d’espace d’adresses que les anciens réglages par défaut ne gèrent pas bien.

Le réglage BIOS/UEFI : noms, pièges et ce que signifie « activé »

L’erreur la plus coûteuse en passthrough GPU est de supposer que le libellé du BIOS correspond à l’état réel du matériel.
Sur de nombreux systèmes, vous devez activer plusieurs options, et les étiquettes varient selon le fournisseur et la génération de carte mère.
L’exigence centrale est : le CPU + le chipset doivent exposer une IOMMU et le firmware ne doit pas la désactiver.

Comment se nomme ce réglage

• Intel : « Intel VT-d », « VT-d », « IOMMU », parfois « Directed I/O ».
• AMD : « SVM » (virtualisation CPU) n’est pas IOMMU ; vous voulez « IOMMU », « AMD-Vi », parfois « PCIe ARI support ».
• Plateformes serveurs : Vous pouvez aussi voir « Interrupt Remapping », « DMA Protection », « PCIe ACS », « SR-IOV ».

Pièges BIOS qui semblent sans rapport mais ne le sont pas

• CSM vs UEFI pur : Beaucoup de configurations de passthrough GPU fonctionnent mieux avec OVMF (UEFI) et CSM désactivé.
• Above 4G decoding : Souvent requis pour les GPU modernes, surtout si vous passez plusieurs périphériques ou utilisez de larges fonctionnalités BAR.
• Resizable BAR : Peut modifier la taille et le comportement des mappings BAR. Parfois utile, parfois déstabilisant. Ne l’activez pas « pour les perfs » sans tester.
• Bifurcation des slots PCIe : Peut modifier la topologie ; la topologie modifie les groupes IOMMU.

Blague n°1 : les menus BIOS sont le seul endroit où « Activé » peut signifier « peut-être, selon votre humeur et le microcode ».

Une phrase pour garder l’équipe honnête

L’espoir n’est pas une stratégie. — idée paraphrasée souvent entendue en ingénierie / opérations

Traduction pour l’IOMMU : ne « supposez » pas qu’il est activé parce que vous avez basculé quelque chose une fois. Vérifiez depuis l’OS.

Groupes IOMMU : la frontière qui décide si vous pouvez isoler un GPU

Même avec l’IOMMU activée, vous pouvez être bloqué si votre GPU partage un groupe IOMMU avec d’autres périphériques dont vous avez besoin sur l’hôte
(comme un contrôleur USB pour le clavier, ou un contrôleur SATA contenant le disque de démarrage de l’hôte). Les groupes IOMMU représentent
les unités d’isolation minimales que votre plateforme peut appliquer en toute sécurité pour le DMA.

Pourquoi les groupes existent

Les périphériques derrière le même pont PCIe en amont peuvent être capables de voir le trafic des uns et des autres à moins que la plateforme ne supporte ACS et une isolation appropriée.
Le noyau regroupe ces périphériques parce qu’il ne peut pas garantir la séparation. Passer en passthrough un élément revient à passer tout le groupe.

Ce que vous voulez voir

• Le GPU (et sa fonction audio HDMI) dans un groupe IOMMU qui ne contient que ces fonctions.
• Les NIC et contrôleurs de stockage dans des groupes séparés sauf si vous les passez intentionnellement.
• Un comportement « tout dans le groupe 0 » minimal ; cela signale généralement une IOMMU non activée ou mal exposée.

ACS override : le hack tentant

Sur certaines cartes grand public, vous pouvez forcer le noyau à scinder les groupes avec un paramètre ACS override. On le présente souvent comme une solution magique.
Ce n’est pas magique ; c’est dire au noyau de faire semblant que l’isolation existe alors que le matériel ne la fournit pas entièrement.

N’utilisez l’ACS override que lorsque vous comprenez le risque : vous pouvez obtenir un passthrough fonctionnel, mais l’isolation DMA peut être plus faible que vous ne le pensez.
Pour un lab à la maison c’est acceptable. Pour tout ce qui touche des données de production, c’est une discussion de gouvernance.

Playbook de diagnostic rapide

C’est la séquence « j’ai 20 minutes avant la fin de la fenêtre de changements ». Ne freestylez pas. Vérifiez ces étapes dans l’ordre ; chaque étape élimine une classe de problèmes.

Première étape : prouvez que l’IOMMU est réellement activée

• Vérifiez les paramètres de démarrage du noyau et dmesg pour l’initialisation de l’IOMMU.
• Confirmez les tables DMAR (Intel) ou AMD-Vi détectées.
• Confirmez l’état du remappage d’interruptions si la stabilité et la sécurité vous importent.

Deuxième étape : validez les groupes IOMMU et la topologie

• Listez les groupes IOMMU ; assurez-vous que le GPU et sa fonction audio sont isolés.
• Identifiez ce qui partage le groupe ; décidez si vous pouvez le passer aussi.
• Si les groupes sont trop larges : préférez changer de slot / modifier la topologie BIOS avant l’ACS override.

Troisième étape : confirmez la liaison des pilotes et la propriété VFIO

• Assurez-vous que l’hôte n’a pas lié le GPU à nvidia/amdgpu.
• Lie les fonctions GPU à vfio-pci tôt au démarrage ; ne comptez pas sur un « unbind plus tard » sauf si vous aimez l’instabilité.
• Confirmez que /dev/vfio/* existe et correspond à vos IDs de groupe.

Quatrième étape : vérifiez le firmware de la VM, le type de machine et le comportement de reset

• Utilisez OVMF (UEFI) et q35 sauf raison contraire.
• Si le GPU ne se réinitialise pas proprement entre redémarrages de VM, prévoyez vendor-reset (si disponible) ou un reboot de l’hôte.
• Vérifiez les problèmes de ROM, la sélection du GPU primaire et le routage de la sortie console.

Tâches pratiques : commandes, sorties et décisions

Les tâches suivantes sont volontairement pratiques. Chacune inclut : la commande, à quoi ressemble une sortie typique, ce que cela signifie,
et la décision à prendre ensuite. Si vous faites du passthrough GPU sans exécuter ces étapes, vous opérez « au ressenti ».

Task 1: Identify your CPU vendor and virtualization flags

cr0x@server:~$ lscpu | egrep -i 'Vendor ID|Model name|Virtualization|Flags'
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) CPU E-2278G @ 3.40GHz
Virtualization:        VT-x
Flags:                 ... vmx ...

Signification : VT-x (Intel) ou SVM (AMD) est la virtualisation CPU, pas l’IOMMU. Toutefois, si vous n’avez pas cela, KVM est impossible.

Décision : Si la virtualisation CPU manque, corrigez le BIOS pour activer la virtualisation CPU. Puis reprenez.

Task 2: Confirm IOMMU is enabled in the kernel command line

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0 root=/dev/mapper/vg0-root ro quiet intel_iommu=on iommu=pt

Signification : intel_iommu=on (ou amd_iommu=on) demande l’IOMMU. iommu=pt utilise le mode pass-through pour réduire l’overhead sur les périphériques hôtes.

Décision : Si vous ne voyez pas le paramètre, ajoutez-le via GRUB/systemd-boot. S’il est présent, passez à la preuve via dmesg.

Task 3: Check dmesg for DMAR/AMD-Vi initialization

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 25
[    0.012345] DMAR: IOMMU enabled
[    0.012678] DMAR: Host address width 39
[    0.013000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.013250] DMAR: Queued invalidation will be enabled to support IOMMU
[    0.013500] DMAR: Intel(R) Virtualization Technology for Directed I/O

Signification : Le noyau vous indique qu’il a trouvé les tables et activé le remappage DMA.

Décision : Si vous voyez des erreurs comme « IOMMU disabled » ou rien du tout, arrêtez. Retournez au BIOS/UEFI et au mode de démarrage.

Task 4: Validate interrupt remapping status (stability/security)

cr0x@server:~$ dmesg | egrep -i 'remapping|x2apic|IR' | head -n 30
[    0.020000] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.020500] DMAR-IR: Queued invalidation will be enabled

Signification : Le remappage IRQ est activé ; c’est bon pour la correction dans des configurations complexes.

Décision : Si le remappage est désactivé pour des bugs firmware, envisagez une mise à jour du BIOS ou des paramètres noyau différents. En environnement régulé, traitez l’absence de remappage comme un risque.

Task 5: Enumerate PCI devices and find the GPU functions

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|audio|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)

Signification : Votre GPU est généralement composé de deux fonctions : graphique et audio HDMI/DP. Vous devez passer les deux.

Décision : Notez les adresses PCI (01:00.0 et 01:00.1) et les vendor:device IDs (10de:1e87, 10de:10f8) pour le binding vfio-pci.

Task 6: List IOMMU groups and confirm isolation

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}:"; ls -l "$g/devices"; done | sed -n '1,80p'
IOMMU Group 12:
total 0
lrwxrwxrwx 1 root root 0 Feb  4 09:12 0000:01:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
lrwxrwxrwx 1 root root 0 Feb  4 09:12 0000:01:00.1 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.1

Signification : Le groupe 12 ne contient que le GPU et sa fonction audio. Voilà ce à quoi ressemble un résultat « correct ».

Décision : Si d’autres périphériques sont dans le même groupe, décidez si vous pouvez les passer aussi. Sinon, essayez un autre slot ou des réglages BIOS avant d’envisager ACS override.

Task 7: Check what driver currently owns the GPU

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:3fdd]
	Kernel driver in use: nouveau
	Kernel modules: nouveau, nvidiafb

Signification : L’hôte a pris le GPU avec nouveau. VFIO ne pourra pas le prendre de façon fiable plus tard.

Décision : Empêchez la liaison par l’hôte (blacklist des pilotes ou liaison à vfio-pci tôt). N’essayez pas de « juste unbind » en production à moins d’aimer les surprises.

Task 8: Bind the GPU to vfio-pci via modprobe options

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1
EOF

cr0x@server:~$ sudo tee /etc/modprobe.d/blacklist-gpu.conf >/dev/null <<'EOF'
blacklist nouveau
blacklist nvidia
blacklist nvidia_drm
blacklist nvidia_modeset
EOF

Signification : Vous dites au noyau de lier ces IDs de périphérique à vfio-pci et d’empêcher les pilotes GPU courants de les réclamer.

Décision : Reconstruisez l’initramfs (tâche suivante) pour que cela s’applique tôt, puis redémarrez.

Task 9: Rebuild initramfs so vfio binding happens at boot

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.5.0

Signification : Votre initramfs inclut désormais les options de module/blacklists mises à jour, affectant le binding précoce des périphériques.

Décision : Redémarrez et revérifiez lspci -nnk pour confirmer que vfio-pci possède le GPU.

Task 10: After reboot, confirm vfio-pci is the kernel driver in use

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:3fdd]
	Kernel driver in use: vfio-pci
	Kernel modules: nouveau, nvidiafb

Signification : Parfait. La liste des modules peut toujours mentionner des modules potentiels ; la ligne clé est « Kernel driver in use ».

Décision : Passez à la configuration de la VM. Si le pilote n’est pas vfio-pci, vous avez toujours une course de liaison (souvent initramfs non mis à jour, ou mauvais IDs).

Task 11: Confirm VFIO devices exist for the group

cr0x@server:~$ ls -l /dev/vfio/
total 0
crw------- 1 root root 244,   0 Feb  4 09:15 12
crw------- 1 root root  10, 196 Feb  4 09:15 vfio

Signification : Le nœud numérique (12) correspond au groupe IOMMU 12. C’est ainsi que VFIO impose « tous les périphériques d’un groupe bougent ensemble ».

Décision : Si le nœud de groupe n’existe pas, VFIO n’est pas configuré ou l’IOMMU ne fonctionne pas comme vous le pensez. Retournez aux tâches 2–6.

Task 12: Check whether the GPU is the boot VGA device (can complicate things)

cr0x@server:~$ lspci -vv -s 01:00.0 | egrep -i 'Kernel driver|VGA|boot'
VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080] (rev a1)
	Kernel driver in use: vfio-pci
	Capabilities: [60] Power Management version 3
	Flags: bus master, fast devsel, latency 0, IRQ 16

Signification : Sur certains systèmes vous verrez « Boot VGA » dans les flags pour le GPU principal. Si votre GPU passthrough est aussi le GPU console de l’hôte, vous vous engagez à plus de travail.

Décision : Préférez un iGPU ou un GPU secondaire bon marché pour la console hôte. Si vous ne pouvez pas, vous devrez gérer framebuffer/console et éventuellement des quirks de ROM.

Task 13: Confirm KVM acceleration is present (so you’re not debugging slowness as “IOMMU issues”)

cr0x@server:~$ sudo kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

Signification : KVM est disponible. Si /dev/kvm manque, vous aurez de mauvaises performances et des comportements de temporisation étranges.

Décision : Corrigez la virtualisation CPU et les modules KVM avant d’accuser VFIO.

Task 14: Spot group cohabitation quickly for a specific device

cr0x@server:~$ readlink -f /sys/bus/pci/devices/0000:01:00.0/iommu_group
/sys/kernel/iommu_groups/12

Signification : C’est le mapping canonique du groupe. C’est scriptable et supprime les approximations.

Décision : Si le groupe contient d’autres périphériques, décidez si vous pouvez les passer aussi. Sinon, changez la topologie (slot/bifurcation) avant les hacks noyau.

Task 15: Check for IOMMU being “enabled” but effectively bypassed

cr0x@server:~$ dmesg | egrep -i 'iommu.*(pt|passthrough)|DMA' | head -n 20
[    0.050000] DMAR: IOMMU enabled
[    0.050500] DMAR: Default domain type: Passthrough (set via iommu=pt)

Signification : iommu=pt est normal pour un hôte hyperviseur : il réduit l’overhead pour les périphériques possédés par l’hôte. Les périphériques assignés à VFIO reçoivent quand même des domaines IOMMU isolés.

Décision : Si vous poursuivez des exigences strictes de sécurité DMA, envisagez le mode strict ; sinon laissez tel quel. Ne retirez pas iommu=pt par superstition.

Task 16: Inspect QEMU/libvirt log for VFIO attach errors

cr0x@server:~$ sudo tail -n 60 /var/log/libvirt/qemu/win11-gpu.log
2026-02-04T09:21:10.123456Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0,id=hostdev0: vfio 0000:01:00.0: failed to setup container for group 12: Failed to set iommu for container: Operation not permitted
2026-02-04T09:21:10.123789Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0,id=hostdev0: failed to initialize VFIO device

Signification : C’est un problème de permissions / container / propriété du groupe (ou une capacité manquante dans le runtime).

Décision : Lancez QEMU avec les privilèges appropriés (libvirt gère cela), confirmez les permissions du groupe vfio et vérifiez que vous n’êtes pas dans un conteneur non privilégié qui tente le passthrough.

Blague n°2 : les erreurs VFIO sont comme des biscuits de fortune — cryptiques, légèrement accusatrices, et toujours délivrées juste avant que vous vouliez partir chez vous.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une société de taille moyenne a déployé un hôte « temporaire » de virtualisation GPU pour accélérer un backlog de machine learning. Il a fonctionné une semaine.
Puis un reboot de maintenance routinier s’est transformé en une panne de demi-journée pour les pipelines ML de l’équipe.

L’hypothèse : « Nous avons activé la virtualisation dans le BIOS, donc le passthrough est couvert. » Ils avaient activé VT-x, mais pas VT-d.
L’hôte démarrait toujours, les VM démarraient toujours, et le GPU semblait dans la configuration de la VM — jusqu’au moment où VFIO a essayé d’attacher réellement.
Après le reboot, le GPU s’est énuméré différemment (les changements d’entraînement du slot arrivent), et la VM a échoué avec une erreur de groupe/conteneur VFIO.

L’équipe a passé des heures sur les versions de pilotes et les arguments QEMU parce que le message d’erreur ne disait pas « allez dans le BIOS ».
Quand quelqu’un a enfin vérifié dmesg, il n’y avait pas d’initialisation DMAR. L’hyperviseur avait fonctionné dans un état « ça a l’air ok »,
pas dans un état « c’est correct ».

La correction fut banale : activer VT-d, mettre à jour le BIOS vers une révision stable, et écrire un script de prévol qui greppe dmesg pour DMAR/AMD-Vi avant
d’autoriser des charges GPU sur le nœud. Ils ont aussi mis à jour leur checklist de build pour que « virtualisation activée » devienne deux vérifications explicites :
virtualisation CPU et virtualisation IOMMU.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un autre atelier voulait extraire un peu plus de débit de leurs VM GPU compute. Quelqu’un a suggéré d’activer Resizable BAR et de basculer
toutes les options « performance PCIe » dans le firmware : Above 4G decoding, ReBAR, des réglages ASPM agressifs, et une nouvelle topologie de bifurcation de slot PCIe.
Les benchmarks sur une seule VM semblaient un peu meilleurs.

Puis les bizarreries ont commencé : échecs intermittents de démarrage de VM, blocages occasionnels de l’hôte sous DMA GPU intensif, et un schéma où la seconde VM
à démarrer après un reboot échouait alors que la première réussissait. On a d’abord suspecté un pilote jusqu’à ce que ça n’en soit pas un.

Le vrai problème était l’instabilité de la topologie et le changement de groupes. Le changement de bifurcation a déplacé des périphériques derrière différents ponts, décalant les groupes IOMMU.
Leur automatisation liait toujours les anciens IDs de périphérique correctement, mais le regroupement était désormais plus large et incluait un contrôleur USB nécessaire à l’hôte.
Parfois l’assignation du groupe tombait « en sécurité », parfois non, selon l’ordre d’énumération et le comportement du firmware.

Le rollback a tout réglé instantanément. Ils ont conservé Above 4G decoding (requis), désactivé ReBAR pour l’instant, et traité la topologie PCIe comme un élément géré par changement avec une checklist de régression :
vérifier les groupes, vérifier le binding VFIO, vérifier les cycles démarrage/arrêt de VM, vérifier le comportement de reset.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers exploitait du passthrough GPU sur un petit pool d’hôtes pour des charges analytiques. Rien de spectaculaire, mais le contrôle des changements
était strict. Ils avaient un runbook de préflight presque comiquement simple : confirmer IOMMU activée, confirmer groupes inchangés, confirmer binding VFIO,
confirmer qu’une VM de test peut démarrer et s’arrêter deux fois.

Une mise à jour firmware était planifiée dans le cadre d’un cycle de patchs de sécurité. Les notes du fournisseur mentionnaient « compatibilité PCIe améliorée. »
L’équipe a traité cette phrase comme un dispositif non explosé. Ils ont drainé un hôte, l’ont patché et exécuté le préflight complet.

Le préflight a détecté que le remappage d’interruptions avait été désactivé par défaut après la mise à jour (le firmware a réinitialisé un réglage).
Tout fonctionnait encore « en apparence », mais les logs noyau montraient une dégradation dans la gestion DMA/interruption. Ils ont rollbacké le firmware sur cet hôte,
puis l’ont réappliqué en imposant explicitement les réglages BIOS et en stockant des captures d’écran dans leur enregistrement de changement interne.

La partie « sauver la mise » n’était pas un acte héroïque. C’était que l’équipe n’a pas découvert la régression pendant une période critique. Elle l’a découverte
sur un nœud drainé, avec du temps pour réfléchir et des preuves.

Erreurs courantes : symptôme → cause racine → correctif

1) « Aucun IOMMU détecté » ou pas de lignes DMAR/AMD-Vi dans dmesg

Symptôme : l’attachement VFIO échoue ; dmesg ne mentionne pas DMAR/AMD-Vi.

Cause racine : IOMMU désactivée dans le BIOS/UEFI, ou paramètres de démarrage du noyau manquants/ignorés, ou démarrage dans un mode qui cache les fonctionnalités.

Correctif : Activez VT-d/AMD-Vi, confirmez les paramètres noyau, mettez à jour le firmware si les tables DMAR sont corrompues. Vérifiez avec la Tâche 3.

2) Le GPU partage un groupe IOMMU avec un SATA/USB/NIC nécessaire à l’hôte

Symptôme : vous ne pouvez pas passer le GPU sans aussi passer d’autres périphériques critiques.

Cause racine : topologie PCIe + absence d’isolation ACS ; les cartes grand public regroupent souvent agressivement.

Correctif : Essayez un autre slot PCIe, désactivez/activez des périphériques onboard pour reshuffler, ajustez la bifurcation, mettez à jour le BIOS. Dernier recours : ACS override, en connaissance de cause.

3) La VM démarre mais les performances sont médiocres ; utilisation GPU étrange

Symptôme : la VM est lente ; frame pacing mauvais ; jobs compute saccadent.

Cause racine : KVM non actif, ou la VM utilise des périphériques émulés, ou mauvais affinage CPU/NUMA — pas l’IOMMU en soi.

Correctif : Confirmez /dev/kvm, utilisez des périphériques virtio, utilisez q35 + OVMF, et vérifiez le placement NUMA pour le complexe racine PCIe du GPU.

4) La VM démarre une fois, mais après arrêt elle ne redémarre pas sans reboot de l’hôte

Symptôme : le premier attachement fonctionne ; les attachements suivants échouent ; le GPU semble « bloqué ».

Cause racine : quirks de reset GPU (FLR non supporté ou peu fiable), ou le pilote laisse le périphérique dans un mauvais état.

Correctif : Utilisez vendor-reset si supporté, assurez-vous de passer toutes les fonctions, évitez toute liaison du pilote hôte, et planifiez des reboots d’hôte si nécessaire.

5) Écran noir dans la VM malgré un attachement VFIO réussi

Symptôme : la VM fonctionne, mais pas de sortie d’affichage depuis le GPU passé.

Cause racine : mauvais firmware VM (SeaBIOS vs OVMF), ROM GPU manquante, confusion sur le GPU primaire, ou sortie affichage routée vers un autre port.

Correctif : Passez à OVMF, utilisez q35, envisagez de spécifier un fichier ROM si nécessaire, et assurez-vous que l’écran est connecté au GPU passé.

6) VFIO « failed to set iommu for container: Operation not permitted »

Symptôme : logs Libvirt/QEMU montrent des échecs de permissions/conteneurs.

Cause racine : tentative de passthrough depuis un conteneur non privilégié, permissions de périphérique incorrectes, ou modèle de sécurité libvirt mal configuré.

Correctif : Exécutez l’hyperviseur sur l’hôte, pas dans un conteneur non privilégié ; validez les permissions de /dev/vfio ; utilisez QEMU géré par libvirt avec les privilèges appropriés.

7) Vous avez activé « SVM » sur AMD en pensant que c’était IOMMU

Symptôme : la virtualisation CPU fonctionne ; l’IOMMU non.

Cause racine : SVM est la virt CPU AMD ; AMD-Vi est l’IOMMU. Ce sont des bascules différentes.

Correctif : Activez explicitement AMD-Vi/IOMMU et vérifiez dmesg pour AMD-Vi.

8) ACS override « corrige » le regroupement mais introduit instabilité ou risque

Symptôme : les groupes semblent parfaits après ACS override, mais vous observez des hangs rares de l’hôte ou des objections lors des revues de sécurité.

Cause racine : vous avez forcé le noyau à scinder des groupes au-delà de ce que le matériel garantit.

Correctif : Préférez du matériel qui supporte correctement ACS ; pour des environnements sérieux, n’utilisez pas ACS override comme solution permanente.

Listes de vérification / plan étape par étape

Étape par étape : parvenir au premier passthrough GPU réussi (répétable)

1. Firmware : Activez VT-d (Intel) ou AMD-Vi/IOMMU (AMD). Activez Above 4G decoding. Préférez un démarrage UEFI pur.
2. Paramètres noyau : Ajoutez intel_iommu=on ou amd_iommu=on. Optionnellement ajoutez iommu=pt.
3. Redémarrer et vérifier : Utilisez dmesg pour confirmer que DMAR/AMD-Vi est activé et qu’il n’y a pas d’erreurs IOMMU flagrantes.
4. Découvrir les périphériques : Utilisez lspci -nn pour enregistrer les IDs et adresses des fonctions GPU et audio.
5. Vérifier les groupes : Assurez-vous que les fonctions GPU sont isolées dans leur propre groupe IOMMU.
6. Binder à vfio-pci tôt : Configurez les IDs vfio-pci et blacklist des pilotes hôtes ; reconstruisez l’initramfs.
7. Redémarrer et confirmer le binding : lspci -nnk doit montrer vfio-pci en usage pour les fonctions GPU.
8. Config VM : Utilisez q35 + OVMF. Passez les deux fonctions GPU. Préférez virtio pour disque et NIC.
9. Tester le cycle de vie : Démarrez la VM, chargez la charge, arrêtez la VM, redémarrez. Répétez. Vous testez le comportement de reset, pas seulement le premier démarrage.
10. Opérationnaliser : Écrivez des vérifications préflight (IOMMU activée, groupes stables, binding vfio correct) et exécutez-les après les mises à jour firmware/noyau.

Checklist gestion de changement (parce que les mises à jour firmware sont le chaos)

• Avant le changement : capturez dmesg (lignes IOMMU) et la liste des groupes IOMMU pour le GPU.
• Avant le changement : capturez lspci -nnk pour les fonctions GPU (pilote en usage).
• Après le changement : relancez les mêmes commandes ; comparez les sorties.
• Après le changement : démarrez/arrêtez la VM de test deux fois ; confirmez l’absence de régressions.
• Si les groupes ont changé : traitez cela comme un changement de topologie et réévaluez la sécurité avant de restaurer les charges de production.

Quand arrêter d’essayer et acheter du meilleur matériel

• Votre GPU partage un groupe avec des périphériques hôtes critiques et vous ne pouvez pas changer la topologie pour l’isoler.
• Vous exigez des garanties d’isolation strictes et vous vous appuyez sur ACS override pour que les groupes « paraissent corrects ».
• Vous avez besoin d’un comportement de reset fiable et votre combinaison GPU/carte mère ne le fournit pas sans reboots d’hôte.

FAQ

1) L’IOMMU sert-elle uniquement à la virtualisation ?

Non. Elle sert aussi pour l’isolation DMA et le durcissement du noyau sur métal nu. La virtualisation est juste le cas d’usage le plus visible.

2) Quelle est la différence entre VT-x et VT-d ?

VT-x est la virtualisation CPU (exécution efficace du code invité). VT-d est l’IOMMU (remappage DMA des périphériques). Vous avez besoin de VT-d pour un passthrough PCI sûr.

3) Sur AMD, « SVM » est-il identique à AMD-Vi ?

Non. SVM est la virtualisation CPU. AMD-Vi (souvent étiqueté IOMMU) est ce dont vous avez besoin pour le passthrough.

4) Pourquoi dois-je aussi passer la fonction audio du GPU ?

Parce que c’est généralement une fonction PCI distincte dans le même package de périphérique. La laisser sur l’hôte peut casser le comportement de reset ou causer des conflits de pilotes dans l’invité.

5) Les groupes IOMMU sont-ils une limitation de Linux ?

Le regroupement reflète les frontières d’isolation matérielle (ponts, capacités ACS). Linux est conservateur : il ne promettra pas d’isolation qu’il ne peut pas appliquer.

6) Dois-je toujours utiliser iommu=pt ?

Généralement oui pour un hôte hyperviseur : cela réduit l’overhead pour les périphériques détenus par l’hôte. Les périphériques assignés à VFIO restent isolés dans des domaines IOMMU.
Si vous visez une isolation DMA stricte pour tous les périphériques, reconsidérez et testez.

7) L’ACS override rend-il le passthrough « sûr » ?

Cela peut le faire fonctionner. « Sûr » dépend de l’isolation effectivement fournie par votre matériel. Pour des modèles de risque multi-tenant ou de production, évitez d’en dépendre.

8) Ma VM fonctionne jusqu’à ce que je la redémarre. Pourquoi ?

Probablement un problème de reset de périphérique. Beaucoup de GPU ne se réinitialisent pas proprement via FLR dans tous les scénarios. Vous pourriez avoir besoin du vendor-reset, d’un matériel différent, ou de reboots d’hôte entre assignations.

9) Ai-je besoin d’UEFI (OVMF) dans la VM ?

Pour de nombreux GPU modernes et invités Windows, oui. OVMF + q35 réduit les chemins VGA hérités bizarres et se comporte généralement mieux pour le passthrough.

10) Puis-je exécuter le passthrough GPU depuis un conteneur ?

En pratique, le passthrough GPU est une tâche au niveau hôte. Les conteneurs non privilégiés manquent souvent des permissions et de la gestion de périphériques requises pour VFIO.

Conclusion : prochaines étapes qui font réellement la différence

L’IOMMU n’est pas « une fonctionnalité ». C’est le contrat qui rend l’assignation de périphérique raisonnable. Si vous voulez que le passthrough GPU soit stable, cessez de traiter le réglage BIOS
comme une case à cocher et commencez à le considérer comme une dépendance que vous vérifiez en continu.

Prochaines étapes pratiques

1. Exécutez les Tâches 2–6 sur votre hôte et enregistrez les sorties comme baseline (cmdline noyau, lignes dmesg IOMMU, liste des groupes IOMMU).
2. Lie votre GPU à vfio-pci tôt (Tâches 7–10). Si vous faites encore du unbind à chaud, vous choisissez la fragilité.
3. Testez le cycle de vie VM deux fois (démarrer → charge → arrêter → démarrer). Si ça ne marche qu’une fois, vous n’avez pas un système fiable — vous avez une démo.
4. Si les groupes sont problématiques, fixez la topologie d’abord. Si vous devez utiliser ACS override, documentez le risque et gardez-le hors des environnements demandant de fortes garanties d’isolation.

La condition de victoire est ennuyeuse : groupes cohérents, binding prévisible, démarrages/arrêts de VM reproductibles. Quand ça devient ennuyeux, c’est que vous avez bien fait.