Intel VT-d vs AMD‑Vi : lequel offre réellement le meilleur pass-through ?

février 18, 2026 • février 18, 2026 • Lecture : 31 min • Views: 0

Cet article vous a aidé ?

Le pass-through PCIe est une fonctionnalité qui paraît déterministe sur une diapositive et qui se comporte comme la météo en production.
Un jour votre VM GPU est un citoyen modèle ; le lendemain elle affiche un écran noir au redémarrage et votre fenêtre de maintenance se transforme en séance de thérapie de groupe.

La question « Intel VT-d est‑il meilleur qu’AMD‑Vi ? » est généralement posée juste après l’achat du matériel et juste avant de regretter au moins un réglage du BIOS.
La vraie réponse tient moins aux logos qu’aux comportements spécifiques de la plateforme : groupes IOMMU, remappage des interruptions, qualité du firmware et l’importance pour vous d’une isolation propre des périphériques.

Ce que signifie vraiment « meilleur pass-through »

« Meilleur pass-through » n’est pas une métrique unique. En production, vous vous souciez de quatre choses, à peu près dans cet ordre :

Exactitude de l’isolation : le périphérique est dans son propre groupe IOMMU, le DMA est contenu et les réinitialisations fonctionnent correctement.
Stabilité opérationnelle : les redémarrages, migrations à chaud (le cas échéant), rechargements de pilote et mises à jour du noyau ne deviennent pas des tickets d’incident.
Consistance des performances : faible gigue sous charge et latence prévisible, en particulier pour NVMe, cartes réseau et GPU.
Gestion : bonne visibilité des outils, journaux raisonnables et moins de « paramètres de démarrage spéciaux » qui deviennent un savoir tribal.

Si vous construisez un lab à la maison, vous pouvez tolérer des bricolages comme l’ACS override et « ne redémarrez pas la VM deux fois de suite ».
Si vous faites cela pour une activité—surtout pour des charges régulées—votre « solution de pass-through » est un système, pas une case cochée.

VT-d vs AMD‑Vi : résumé circonstancié

Intel VT-d et AMD‑Vi (l’IOMMU d’AMD) peuvent tous deux fournir un excellent pass-through. Les plus grandes différences que vous ressentirez ne sont pas théoriques.
Ce sont des détails d’implémentation de la plateforme : firmware de la carte mère, topologie PCIe, groupes IOMMU, et si le remappage des interruptions est solide.

Ma recommandation par défaut

Si vous avez besoin d’un pass-through ennuyeusement fiable et de qualité entreprise (NICs SR-IOV, HBA, NVMe, GPU en flotte) : choisissez la plateforme avec le meilleur historique carte + BIOS, pas le fournisseur du CPU.
En pratique, cela signifie souvent les plateformes Intel dans les serveurs certifiés par les vendeurs, et les plateformes AMD sur des serveurs EPYC modernes avec un firmware mature.
Si vous achetez du matériel grand public : les systèmes AMD offrent fréquemment plus de cœurs par dollar, mais aussi plus de variabilité dans les groupes IOMMU selon le chipset et le routage de la carte.
Les cartes Intel grand public peuvent être plus prévisibles, mais vous rencontrerez tout de même l’occasionnel « groupe de ports racines partagés » problématique.
Si vous dépendez d’une isolation IOMMU propre et ne pouvez pas tolérer l’ACS override : priorisez les plateformes qui exposent davantage de ports racines PCIe et une isolation en aval plus nette.
C’est moins une question « Intel vs AMD » qu’une question de « cette carte mère et cette génération de CPU spécifiques ».

Voici la version sans fard : le meilleur pass-through est celui que vous pouvez redémarrer.
Si vous ne pouvez pas redémarrer à froid l’hôte, redémarrer l’invité et rattacher le périphérique plusieurs fois sans comportement étrange, vous n’avez pas une solution—vous avez une démonstration.

Comment fonctionne réellement le pass-through IOMMU (et où ça échoue)

Le pass-through est un contrat en trois parties :

Le périphérique effectue des DMA et déclenche des interruptions.
L’IOMMU traduit les adresses DMA du périphérique via des tables de pages, en limitant quelles régions mémoire physique le périphérique peut toucher.
L’hyperviseur (KVM/QEMU via VFIO sur Linux, ou un hyperviseur de type 1) attache le périphérique à un invité et programme les mappages IOMMU.

Quand ça marche, votre invité pilote le périphérique presque comme s’il était sur du bare metal, mais l’hôte conserve des frontières de sécurité DMA.
Quand ça ne marche pas, les modes de défaillance sont… instructifs :

Mauvais regroupement : votre GPU et votre contrôleur USB partagent un groupe IOMMU ; vous ne pouvez pas passer l’un sans l’autre en toute sécurité.
Échec de réinitialisation : l’invité s’arrête, le périphérique ne se réinitialise pas correctement, et le démarrage suivant bloque sur « Starting bootloader… » ou affiche un écran noir.
Problèmes d’interruptions : la livraison MSI/MSI‑X devient étrange ; les performances chutent ou la latence bondit ; certains périphériques ne se comportent bien qu’avec certains paramètres du noyau.
Faults de page : des fautes IOMMU apparaissent dans dmesg ; le pilote invité est correct, mais les mappages ou les comportements ATS/PRI ne correspondent pas aux attentes.

Aussi : le pass-through est un problème de topologie.
Deux CPU identiques avec des cartes mères différentes peuvent se comporter comme des espèces différentes, parce que votre agencement PCIe détermine quels périphériques se trouvent derrière quels ports racines et ponts,
et cela détermine les groupements et les domaines de réinitialisation.

Blague n°1 : le pass-through PCIe est facile—jusqu’à ce que vous essayiez.

Faits et contexte historique intéressants (court et utile)

Ce ne sont pas des anecdotes pour le quiz du soir. Ils expliquent pourquoi certains bugs et particularités de plateforme existent.

VT-d est arrivé après VT-x : la virtualisation CPU (VT-x) ne suffisait pas pour un DMA sécurisé, donc VT-d a comblé le vide pour l’I/O dirigée.
AMD‑Vi apparaît comme « IOMMU » dans les logs Linux : Linux rapporte souvent l’implémentation d’AMD sous le nom générique IOMMU, et vous verrez « AMD‑Vi » dans dmesg sur de nombreux systèmes.
Le remappage des interruptions est une fonctionnalité de fiabilité : ce n’est pas seulement pour les performances—sans lui, vous pouvez être contraint à des modes d’interruption moins sûrs ou moins fonctionnels.
ACS est une fonctionnalité PCIe, pas IOMMU : Access Control Services peut aider à faire respecter l’isolation entre ports en aval ; l’absence d’ACS conduit souvent à des groupements disgracieux.
« ACS override » est un contournement Linux : il peut séparer les groupes IOMMU en faisant comme si l’isolation ACS existait. Parfois c’est acceptable ; parfois c’est contre‑productif.
SR-IOV a rendu l’IOMMU mainstream : dès que les NICs ont commencé à présenter des fonctions virtuelles multiples, la correction de l’IOMMU a cessé d’être une niche et est devenue indispensable en datacenter.
DMAR est la table ACPI d’Intel pour l’IOMMU : si les tables DMAR sont incorrectes, VT-d peut être « activé » mais effectivement peu fiable.
L’IOMMU d’AMD utilise les tables IVRS : de même, des entrées IVRS erronées peuvent conduire à des périphériques manquants, des mappages cassés ou une topologie de groupes déroutante.
La douleur des réinitialisations GPU est en partie historique : beaucoup de GPU n’ont jamais été conçus pour des réinitialisations fréquentes de niveau fonction en environnements virtualisés, donc vous héritez d’hypothèses matérielles du monde bare‑metal.

Différences de plateforme qui changent les résultats

1) Qualité des groupes IOMMU : le faiseur de rois silencieux

Votre meilleur scénario : chaque périphérique que vous voulez passer est seul dans son groupe IOMMU (ou ne partage qu’avec des fonctions inoffensives du même périphérique, comme l’audio d’un GPU).
Pire scénario : la moitié de la carte mère est un seul groupe parce que le firmware expose une topologie grossière ou que les switchs PCIe ne supportent pas ACS.

Intel vs AMD ici n’est pas un concours moral. Il s’agit de la combinaison de :
complexes racines PCIe intégrés au CPU, lignes du chipset, switchs/retimers PCIe à bord et routage de la carte.
Les cartes serveurs tendent à être plus nettes que les cartes grand public. Les cartes workstation peuvent être soit un paradis soit un carnaval.

2) Remappage des interruptions : la différence entre « ça va » et « pourquoi la latence fait des pics ? »

Avec le pass-through, vous voulez que les interruptions MSI/MSI‑X soient livrées proprement à l’invité. Le remappage des interruptions aide à garder cela sain et sécurisé.
Sans lui, vous pouvez voir des avertissements dans dmesg, des replis ou des restrictions. Quand les gens décrivent de la « gigue » sur des périphériques en pass-through, les interruptions sont souvent impliquées.

3) ATS/PRI et compagnons : quand les périphériques deviennent plus « intelligents »

Certains périphériques peuvent participer plus activement à la traduction d’adresses (ATS) ou demander des pages (PRI). En théorie, cela améliore les performances.
En pratique, cela élargit la surface d’interaction avec les particularités de la plateforme. Si vous chassez des fautes IOMMU rares sous charge, ces fonctionnalités peuvent être pertinentes.
Vous n’avez pas besoin de mémoriser les acronymes ; vous devez reconnaître les schémas et savoir où regarder.

4) Domaines de réinitialisation et support FLR

Le Function Level Reset (FLR) facilite grandement la gestion du cycle de vie en pass-through.
Si votre périphérique ne peut pas se réinitialiser proprement, vous aurez le symptôme classique : le premier démarrage fonctionne, le deuxième échoue jusqu’au redémarrage de l’hôte.
Cela affecte aussi bien les systèmes Intel qu’AMD car c’est souvent une limitation du périphérique, pas de l’IOMMU.

5) Maturité du firmware : le BIOS fait partie de votre hyperviseur

Sur le papier, VT-d et AMD‑Vi sont deux technologies matures. En réalité, la qualité du firmware varie du « solide » au « quelqu’un a expédié ça vendredi ».
Une carte peut annoncer le support IOMMU et avoir pourtant des tables IVRS/DMAR cassées ou des valeurs par défaut douteuses.
Mettez à jour le BIOS tôt, et considérez les notes de version comme des rétrospectives d’incident—parce que c’est ce qu’elles sont.

Performance : où se cachent les surcoûts

En pass-through, le débit brut est généralement proche du bare metal. Les tueurs sont :

Latence et gigue dues au traitement des interruptions, à l’ordonnancement et aux mauvais appariements NUMA.
Surcharge de mappage DMA quand la mémoire invitée est fragmentée ou quand la charge churn les mappages.
Mauvais placement NUMA : passer un périphérique connecté au nœud NUMA 1 dans une VM épinglée au nœud 0 est une chute lente et douloureuse.
Hugepages vs pas : les hugepages réduisent la pression sur la TLB et peuvent réduire la surcharge de mappage pour certaines charges.

Si vous comparez Intel et AMD uniquement sur la « performance de pass-through », vous testez probablement la mauvaise chose.
Le véritable différenciateur est la facilité avec laquelle vous pouvez rendre le système stable et prédictible sous votre charge et vos schémas de redémarrage.

Sécurité et fiabilité : ce que vous obtenez quand c’est correct

L’IOMMU est une frontière de sécurité. Sans elle, un périphérique capable de DMA peut lire/écrire la mémoire de l’hôte directement.
Avec elle, le périphérique est contraint à un mappage défini par le noyau/hyperviseur hôte.

Cela compte pour :

Hôtes multi‑locataires (même « locataires » au sein d’une même entreprise).
Pilotes non fiables dans les invités (en particulier les piles GPU et les accélérateurs niche).
Confinement des mauvais comportements de périphérique (bugs de firmware, DMA rogue, etc.).

Un cadrage utile de la fiabilité : le pass-through est sûr quand votre IOMMU est strict, vos groupes sont propres et vos réinitialisations de cycle de vie sont correctes.
Perdez un de ces éléments, et vous passerez votre temps à inventer des rituels au lieu d’exploiter des services.

Une citation pour rester honnête : L’espoir n’est pas une stratégie. — Rick Pitino

Tâches pratiques : commandes, sorties et décisions (12+)

Celles-ci sont centrées sur Linux, parce que c’est là que vit la plupart du pass-through VFIO/KVM et où vous déboguerez à 02:00.
Les commandes sont exécutables sur des distributions modernes ; ajustez les noms de paquets pour votre environnement.

Task 1: Confirm the CPU and virtualization flags

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

Ce que cela signifie : « Virtualization: VT-x » (Intel) ou « AMD-V » (AMD) vous indique que la virtualisation CPU existe. Cela ne prouve pas que l’IOMMU est activée.

Décision : Si la virtualisation n’est pas présente, arrêtez‑vous. Vous ne ferez pas de pass-through de façon raisonnable sur cet hôte.

Task 2: Confirm IOMMU is enabled in the kernel (Intel VT-d)

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|VT-d' | head -n 30
[    0.612345] DMAR: IOMMU enabled
[    0.612678] DMAR: Host address width 46
[    0.613210] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.615432] DMAR: Interrupt remapping enabled

Ce que cela signifie : « DMAR: IOMMU enabled » est la ligne déterminante. « Interrupt remapping enabled » est un bon signe que vous aurez moins de cas limites d’interruptions.

Décision : Si vous ne voyez pas de lignes DMAR, vérifiez les réglages du BIOS et les paramètres du noyau (tâches plus loin). Ne déboguez pas VFIO tant que ceci n’est pas correct.

Task 3: Confirm IOMMU is enabled in the kernel (AMD-Vi)

cr0x@server:~$ dmesg | egrep -i 'AMD-Vi|IOMMU|IVRS' | head -n 40
[    0.501234] AMD-Vi: IOMMU performance counters supported
[    0.501567] AMD-Vi: Lazy IO/TLB flushing enabled
[    0.504321] ivrs: IOAPIC[4] not in IVRS table

Ce que cela signifie : Les lignes AMD‑Vi indiquent que le pilote IOMMU d’AMD est actif. Les avertissements IVRS peuvent être bénins ou sentir le firmware selon la gravité.

Décision : Si les logs système répètent des plaintes IVRS/IOAPIC et que le pass-through est instable, mettez à jour le BIOS et envisagez une autre carte mère avant de perdre une semaine.

Task 4: Verify kernel command line (intel_iommu / amd_iommu)

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

Ce que cela signifie : intel_iommu=on (ou amd_iommu=on) active l’IOMMU. iommu=pt met les périphériques hôtes en mode pass-through pour réduire la surcharge tout en gardant la traduction pour les invités.

Décision : Pour les hôtes de virtualisation, iommu=pt est généralement un bon défaut. Si vous déboguez l’isolation ou des fautes de périphérique, vous pouvez temporairement le retirer pour comparer les comportements.

Task 5: Confirm IOMMU groups and spot “bad sharing”

cr0x@server:~$ find /sys/kernel/iommu_groups/ -maxdepth 2 -type l | sed 's#.*/##' | sort | head
0000:00:01.0
0000:00:14.0
0000:00:14.2
0000:01:00.0
0000:01:00.1

Ce que cela signifie : Cela liste les périphériques dans les groupes IOMMU. Vous devez inspecter le groupe de chaque périphérique et vérifier si votre périphérique cible est isolé.

Décision : Si votre GPU/NVMe/NIC cible partage un groupe avec des périphériques non liés que vous ne pouvez pas aussi passer, changez de slot, changez de carte mère, ou acceptez le risque d’ACS override.

Task 6: Print groups with human-readable names

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; for d in $g/devices/*; do lspci -nns ${d##*/}; done; echo; done | sed -n '1,40p'
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1234] (rev 02)

Group 1
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:5678] (rev 02)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba] (rev a1)

Ce que cela signifie : Vous recherchez « seulement les fonctions GPU » dans un groupe, pas le GPU plus SATA plus USB plus un pont aléatoire avec des amis.

Décision : Groupement propre ? Poursuivez avec VFIO. Groupement désordonné ? Envisagez un autre slot PCIe (cela change souvent le port racine), ou une autre carte mère.

Task 7: Check whether your device supports reset (FLR) signals

cr0x@server:~$ lspci -s 01:00.0 -vv | egrep -i 'Capabilities:|FLR|Reset' -n | head -n 20
45:Capabilities: [1b0] Vendor Specific Information: ID=0001 Rev=1 Len=024
78:Capabilities: [1e0] Device Serial Number 00-00-00-00-00-00-00-00
92:Capabilities: [250] Latency Tolerance Reporting
110:Capabilities: [300] Secondary PCI Express
132:Capabilities: [400] Physical Resizable BAR
160:Capabilities: [420] Data Link Feature

Ce que cela signifie : Tous les périphériques n’affichent pas clairement FLR dans un grep évident. Certains afficheront « Function Level Reset » explicitement ; d’autres non.

Décision : Si votre GPU montre un mauvais comportement de réinitialisation en pratique, prévoyez des mitigations : modules vendor-reset (lorsque disponibles), éviter les motifs de redémarrage à chaud, ou choisir un modèle de GPU connu pour bien se réinitialiser.

Task 8: Identify the driver currently bound to a PCI device

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5110
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que cela signifie : Si « Kernel driver in use » est le pilote du vendeur, vous ne l’avez pas encore donné à VFIO.

Décision : Pour le pass-through, attachez‑le à vfio-pci sur l’hôte et gardez la console hôte ailleurs (iGPU ou GPU séparé).

Task 9: Bind a device to vfio-pci (persistent via modprobe config)

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:2684,10de:22ba disable_vga=1
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0

Ce que cela signifie : Vous dites à l’hôte d’attacher ces IDs PCI à vfio-pci tôt au démarrage. La mise à jour de l’initramfs garantit que cela prend effet.

Décision : Si vous dépendez du GPU pour la console hôte, ne faites pas cela. Utilisez un iGPU ou l’accès série/BMC. Sinon vous vous verrouillerez hors du système de façon très pure.

Task 10: Confirm vfio-pci binding after reboot

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5110
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que cela signifie : « Kernel driver in use: vfio-pci » est ce que vous voulez. « Kernel modules » peut encore lister des modules vendeurs ; c’est acceptable.

Décision : Si ce n’est pas lié, vérifiez l’initramfs, blacklistez les pilotes conflictuels et confirmez la politique Secure Boot si elle interfère avec le chargement des modules dans votre environnement.

Task 11: Check for IOMMU faults and DMA remapping errors

cr0x@server:~$ sudo dmesg -T | egrep -i 'DMAR|IOMMU|fault|vfio|remapping' | tail -n 30
[Tue Feb  4 01:12:11 2026] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[Tue Feb  4 01:13:09 2026] DMAR: [DMA Read] Request device [01:00.0] fault addr 0x7f2b0000 [fault reason 05] PTE Read access is not set

Ce que cela signifie : Les fautes DMA indiquent des problèmes de mappage ou un comportement du périphérique qui viole les mappages actuels. Parfois c’est un pilote invité mal configuré ; parfois ce sont des particularités de plateforme.

Décision : Si les fautes corrèlent avec des plantages d’invité ou des blocages de périphérique, priorisez la stabilité plutôt que l’optimisation. Revérifiez l’isolation des groupes, la version du noyau, et envisagez de désactiver des fonctionnalités avancées (comme ATS) si votre plateforme le permet.

Task 12: Confirm hugepages (latency hygiene for guests)

cr0x@server:~$ grep -i huge /proc/meminfo | head
AnonHugePages:    1048576 kB
HugePages_Total:      256
HugePages_Free:       200
HugePages_Rsvd:        10
Hugepagesize:       2048 kB

Ce que cela signifie : Cela montre si des hugepages explicites sont provisionnées. Beaucoup de charges sensibles à la latence en pass-through se comportent mieux avec un backing mémoire prévisible.

Décision : Si vous observez des saccades sous charge sur une VM GPU ou une VM de traitement paquet, les hugepages sont un levier raisonnable—après avoir corrigé les groupes IOMMU et le placement NUMA.

Task 13: Check NUMA locality for a passed-through device

cr0x@server:~$ cat /sys/bus/pci/devices/0000:01:00.0/numa_node
1

Ce que cela signifie : Le périphérique vit sur le nœud NUMA 1. Si les vCPU et la mémoire de votre VM sont sur le nœud 0, vous payez une pénalité inter‑socket.

Décision : Épinglez les vCPU et la mémoire de la VM sur le nœud NUMA du périphérique quand c’est possible. Si vous ne pouvez pas, reconsidérez le slot du périphérique (certains slots mappent vers différents racines CPU).

Task 14: Inspect PCIe topology to understand grouping causes

cr0x@server:~$ lspci -t
-[0000:00]-+-00.0
           +-01.0-[01]----00.0
           +-14.0
           \-1c.0-[02]----00.0-[03]----00.0

Ce que cela signifie : Cela montre l’arbre des bridges. Les périphériques derrière le même bridge descendant se retrouvent souvent dans le même groupe IOMMU à moins qu’ACS soit disponible et activé.

Décision : Si votre GPU partage un bridge avec des périphériques critiques pour l’hôte, déplacez‑le vers un slot connecté à un port racine différent, ou vous devrez négocier avec la physique.

Task 15: Verify VFIO is loaded and which modules are active

cr0x@server:~$ lsmod | egrep 'vfio|kvm' | head
vfio_pci               65536  0
vfio_pci_core          90112  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   45056  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             409600  0

Ce que cela signifie : Le noyau VFIO core et IOMMU type1 sont chargés. S’ils manquent, votre hôte n’est pas prêt pour le pass-through même si le BIOS est configuré.

Décision : Chargez les modules, corrigez l’initramfs et confirmez que votre configuration du noyau supporte VFIO. N’essayez pas de configurer des invités tant que la base hôte n’est pas stable.

Task 16: Check whether the kernel is using interrupt remapping

cr0x@server:~$ dmesg | egrep -i 'interrupt remapping|IR:' | head
[    0.615432] DMAR: Interrupt remapping enabled

Ce que cela signifie : Sur Intel, c’est explicite. Sur AMD, vous verrez un libellé différent. Quoi qu’il en soit, vous cherchez des signes que le traitement moderne des interruptions est activé.

Décision : Si le remappage des interruptions est désactivé et que vous observez de l’instabilité ou des avertissements de sécurité, examinez les options BIOS liées à VT-d/AMD IOMMU et au remappage des interruptions, puis retestez.

Playbook de diagnostic rapide

Quand le pass-through est cassé, vous ne commencez pas par réécrire votre config QEMU. Vous commencez par prouver que la plateforme est capable d’être correcte.
Voici le flux « trouver le goulot vite » que j’utilise.

Première étape : L’IOMMU est‑il réellement activé et sain ?

Vérifiez /proc/cmdline pour intel_iommu=on ou amd_iommu=on.
Vérifiez dmesg pour « IOMMU enabled » et toute plainte sur les tables DMAR/IVRS.
Vérifiez que les modules VFIO se chargent.

Deuxième étape : Les groupes IOMMU sont-ils acceptables ?

Énumérez les groupes sous /sys/kernel/iommu_groups.
Vérifiez que votre périphérique cible est isolé ou uniquement groupé avec ses propres fonctions.
Si ce n’est pas le cas : changez de slot, désactivez des périphériques intégrés inutilisés, ou acceptez que la carte mère ne convienne pas à cette exigence.

Troisième étape : S’agit‑il d’une bizarrerie de reset/firmware plutôt que d’un « réglage VFIO » ?

Le premier démarrage VM fonctionne mais les démarrages suivants échouent ? Cela sent le problème de reset/FLR.
Faut‑il un redémarrage de l’hôte pour récupérer le périphérique ? C’est un problème de domaine de réinitialisation.
Mettez à jour le BIOS. Ensuite mettez à jour le noyau. Puis retestez. Ne changez pas douze variables à la fois.

Quatrième étape : Est‑ce de la latence NUMA/interruption qui se déguise en « pass-through lent » ?

Vérifiez le nœud NUMA du périphérique et alignez l’épinglage VM en conséquence.
Cherchez l’état du remappage des interruptions et les problèmes MSI/MSI‑X dans les logs.
Ce n’est qu’après cela qu’il faut envisager hugepages, isolation CPU et réglages d’ordonnanceur.

Blague n°2 : L’IOMMU ne s’est pas « cassée au hasard ». Elle a attendu que vous soyez confiant.

Erreurs courantes : symptôme → cause racine → correction

1) « VFIO fonctionne une fois, puis écran noir au second démarrage »

Symptôme : L’invité démarre et utilise le GPU une fois. Après arrêt/redémarrage, le GPU ne s’initialise plus jusqu’au redémarrage de l’hôte.

Cause racine : Le périphérique ne supporte pas une FLR propre ou la réinitialisation ne se propage pas à travers le bridge ; fréquent avec certains GPU grand public.

Correction : Préférez des GPU connus pour leur compatibilité virtualisée ; essayez un slot différent (change le domaine de reset) ; mettez à jour le BIOS ; envisagez un module de contournement reset si approprié ; évitez les boucles de redémarrage rapides.

2) « Le périphérique est dans un énorme groupe IOMMU avec SATA/USB ; impossible de passer en sécurité »

Symptôme : Votre GPU partage un groupe IOMMU avec le contrôleur SATA du chipset et le contrôleur USB.

Cause racine : Pas d’isolation ACS sur le chemin descendant concerné ; la carte route plusieurs fonctions derrière un pont ; le firmware expose un groupement grossier.

Correction : Déplacez la carte dans un slot lié au CPU‑root ; désactivez les périphériques intégrés inutilisés ; choisissez une autre carte mère avec une meilleure isolation PCIe. N’utilisez ACS override que si vous acceptez explicitement le compromis de sécurité et de stabilité.

3) « Débit élevé mais latence/gigue épouvantable »

Symptôme : Les benchmarks NVMe semblent corrects, mais la latence applicative fait des pics ; les temps de frame GPU sont irréguliers ; le traitement paquet NIC est en rafales.

Cause racine : Mauvais appariement NUMA, problèmes de gestion d’interruptions, contention hôte, absence de hugepages.

Correction : Alignez vCPU+mémoire de la VM sur le nœud NUMA du périphérique ; assurez‑vous que le remappage des interruptions et MSI/MSI‑X fonctionnent ; isolez des CPU hôtes pour les invités sensibles à la latence ; utilisez des hugepages pour l’invité.

4) « L’IOMMU est activée mais aucun groupe n’apparaît »

Symptôme : dmesg mentionne IOMMU, mais /sys/kernel/iommu_groups est vide ou absent.

Cause racine : Noyau démarré sans paramètres IOMMU ; virtualisation désactivée dans le BIOS ; ou vous êtes en mismatch de mode noyau/démarrage (rare, mais cela arrive).

Correction : Vérifiez les bascules BIOS (VT-d/AMD IOMMU) ; vérifiez /proc/cmdline ; mettez à jour le noyau ; assurez‑vous de ne pas exécuter un noyau minimaliste dépourvu de fonctionnalités.

5) « Fautes IOMMU sous charge »

Symptôme : Des fautes DMAR/AMD‑Vi apparaissent dans dmesg lors d’I/O intensif ; l’invité gèle ou le périphérique se déconnecte.

Cause racine : Bugs de firmware plateforme, lien PCIe instable, ou interactions défavorables des fonctionnalités avancées de traduction.

Correction : Mettez à jour le BIOS et le noyau ; réinstallez la carte ; réduisez la vitesse du lien PCIe à titre de test ; vérifiez l’alimentation ; envisagez de désactiver des fonctionnalités avancées si votre stack propose des bascules sûres. Si cela persiste, remplacez la carte mère avant de normaliser le problème.

6) « L’hôte perd le réseau ou le stockage quand la VM démarre »

Symptôme : Le démarrage d’une VM avec pass-through fait mourir des services hôtes.

Cause racine : Vous avez passé le mauvais périphérique (ou le bon périphérique se trouve dans le même groupe que des composants critiques pour l’hôte) parce que le groupement a été ignoré.

Correction : Revérifiez les groupes IOMMU, attachez uniquement les IDs de périphérique cibles, et gardez les contrôleurs critiques de l’hôte hors des groupes pass-through. Si vous ne pouvez pas, le matériel n’est pas adapté à ce design.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne voulait du pass-through GPU pour quelques stations de travail d’annotation ML fonctionnant en VM.
Le plan semblait simple : un hôte par équipe, un GPU par VM, montée en charge facile.
Les achats ont commandé une série de machines « prêtes pour la virtualisation » parce que la fiche technique CPU indiquait VT-d ou AMD‑Vi.

La première semaine s’est bien passée. La deuxième semaine, après des patchs de routine, les tickets ont commencé : écrans noirs après redémarrage de VM, coupures USB aléatoires, et un hôte qui refusait de démarrer une VM si un hub USB spécifique était branché.
L’équipe a supposé que c’était « un problème de pilote » et a passé des jours à blâmer les mises à jour du système invité.

La vraie défaillance était topologique : le GPU et le contrôleur USB se trouvaient dans le même groupe IOMMU sur cette carte mère.
La « correction » qu’ils appliquaient par accident était de redémarrer fréquemment l’hôte, ce qui nettoyait temporairement l’état de reset et masquait le problème.
Une fois qu’ils ont corrélé les pannes avec les groupes IOMMU, le schéma est devenu gênamment cohérent.

Ils ont fini par déplacer les GPU vers d’autres slots quand c’était possible, et pour une sous‑population d’hôtes, remplacer entièrement le modèle de carte mère.
La leçon n’était pas « Intel vs AMD ». La leçon était : une fiche technique CPU n’est pas une garantie de pass-through. La carte est le produit.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation faisait tourner une VM d’appliance de stockage virtualisée avec un HBA passé en pass-through, plus une NIC haute performance passée pour le trafic de réplication.
Ils poursuivaient quelques pourcentages de débit et ont décidé « d’optimiser » en activant toutes les options de performance dans le BIOS : réglages d’alimentation agressifs, états C plus profonds, et quelques knobs de performance IOMMU.

Le débit a progressé dans un benchmark synthétique. La latence a empiré en production.
Les fenêtres de réplication ont commencé à rater leurs cibles, et pire : la VM de stockage enregistrait parfois des timeouts I/O sous peak load.
Rien n’était complètement cassé, ce qui a rendu le débogage plus cher parce que ça ressemblait à « le réseau qui fait des siennes ».

La cause racine était une combinaison de gestion d’énergie et de latence d’interruption interagissant mal avec la NIC en pass-through.
Les vCPU de la VM étaient aussi épinglés sur le mauvais nœud NUMA par rapport à la NIC, donc chaque interruption devenait une petite négociation inter‑socket.
Ils avaient optimisé la mauvaise métrique puis déployé sur la métrique qui compte : la latence perçue par l’utilisateur.

Rétablir les réglages « optimisés », aligner l’épinglage NUMA et utiliser un profil d’alimentation conservateur a restauré la stabilité.
La partie la plus drôle (façon sèche) était que le système d’origine fonctionnait ; leur parade de benchmark a créé l’incident.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers exploitait un cluster d’hôtes de virtualisation avec des charges mixtes, incluant quelques VM avec NICs en pass-through pour la capture de paquets spécialisée.
Ils traitaient d’abord les hôtes de pass-through comme des animaux de compagnie—configurés à la main, peaufinés, et impossibles à reproduire.
Finalement, ils se sont lassés des surprises et ont standardisé.

La « pratique ennuyeuse » était une checklist de pré‑vol exécutée sur chaque nouvel hôte et après chaque mise à jour BIOS :
confirmer IOMMU activé, confirmer remappage des interruptions, dumper les groupes IOMMU, snapshotter la topologie PCIe, et enregistrer les paramètres noyau connus‑bons.
Rien de glamour. Juste de la discipline.

Puis une mise à jour BIOS fournisseur a silencieusement changé l’ordre d’énumération PCIe sur une sous‑population de machines.
Sans le pré‑vol, ils l’auraient découverte en fenêtre de maintenance production quand des périphériques se seraient attachés à des groupes différents et que les anciens bindings VFIO auraient saisi le mauvais contrôleur.
Avec le pré‑vol, ils l’ont détectée en staging, ajusté les bindings et expédié sans drame.

Leur système n’est pas devenu plus rapide. Il est devenu prévisible. En exploitation, c’est généralement le meilleur deal.

Listes de contrôle / plan étape par étape

Étape par étape : choisir le matériel pour le pass-through (pour n’acheter aucun regret)

Commencez par le modèle de carte mère, pas par le CPU. Vérifiez si des utilisateurs rapportent des groupes IOMMU propres pour vos périphériques ciblés.
Privilégiez les slots PCIe root‑CPU pour les périphériques pass-through (GPU, adaptateur NVMe, NIC). Les slots root‑chipset ont souvent un groupement plus agressif.
Évitez les plateformes qui nécessitent ACS override pour une isolation basique. Si vous devez l’utiliser, documentez explicitement l’acceptation du risque.
Planifiez l’accès console hôte : iGPU, BMC/IPMI, ou série. Ne comptez pas sur le GPU passé pour l’accès hôte.
Prévoyez des mises à jour firmware : choisissez des fournisseurs ayant un historique de maintenance BIOS pour la stabilité, pas seulement du microcode CPU.

Étape par étape : configuration de base de l’hôte (Linux + KVM/VFIO)

Activez VT-d/AMD IOMMU dans le BIOS/UEFI. Activez aussi tout réglage nommé « interrupt remapping » s’il existe.
Démarrez avec intel_iommu=on iommu=pt ou amd_iommu=on iommu=pt.
Confirmez que dmesg affiche IOMMU activé et aucune erreur sérieuse DMAR/IVRS.
Confirmez les groupes IOMMU ; vérifiez l’isolation du périphérique cible.
Attachez les IDs de périphérique cibles à vfio-pci dans l’initramfs.
Épinglez CPU/mémoire VM sur le nœud NUMA correct si la latence compte.
Testez le cycle de vie : démarrez la VM, lancez une charge, arrêtez, redémarrez. Répétez jusqu’à l’ennui. Être ennuyé est l’objectif.

Étape par étape : décider entre pass-through et périphériques paravirtualisés

Utilisez virtio quand vous le pouvez (disque, réseau). C’est plus simple et souvent « assez rapide ».
Utilisez le pass-through quand c’est nécessaire (fonctionnalités NIC spécialisées, calcul/graphisme GPU, pilotes vendeurs nécessitant un accès à la fonction physique, HBA pour appliances de stockage).
En cas de doute, évitez de passer des contrôleurs critiques pour l’hôte. Si vous passez le seul HBA contenant l’OS hôte, une erreur vous mènera à une réinstallation distante.

FAQ

1) Intel VT-d est‑il intrinsèquement plus stable qu’AMD‑Vi ?

Pas intrinsèquement. La stabilité dépend surtout de l’implémentation plateforme : tables firmware (DMAR/IVRS), topologie PCIe et comportement de reset des périphériques.
Sur des plateformes serveur certifiées, les deux peuvent être très stables. Sur des cartes grand public, les deux peuvent être chaotiques—simplement de manières différentes.

2) Pourquoi mes groupes IOMMU sont‑ils « pires » sur une carte mère que sur une autre ?

Parce que le groupement est influencé par les bridges PCIe, les switchs et la capacité ACS le long du chemin.
Une carte qui route plusieurs slots derrière un même bridge descendant (sans ACS) collera les périphériques ensemble dans un seul groupe.
Une autre carte avec plus de ports racines ou une meilleure isolation ACS produira des groupes plus propres.

3) Dois‑je utiliser ACS override ?

Seulement si vous comprenez le compromis : cela peut faire paraître des groupes isolés alors que le matériel n’applique pas une séparation complète.
Pour les labs à la maison, c’est souvent acceptable. Pour des environnements demandant une isolation stricte, c’est un risque à ne pas normaliser.

4) Est‑ce que `iommu=pt` réduit l’isolation des invités ?

Il met généralement les mappages DMA de l’hôte en identité/pass-through pour la performance tout en continuant d’utiliser la traduction pour les périphériques assignés aux invités.
C’est couramment utilisé sur les hôtes de virtualisation. Si vous déboguez ou validez la stricte sécurité, testez sans.

5) Pourquoi le pass-through GPU échoue après le redémarrage d’une VM ?

En général le comportement de reset : le GPU ne se réinitialise pas proprement (pas de FLR exploitable, ou la réinitialisation ne se propage pas), le laissant dans un état invalide.
Parfois c’est aussi une interaction pilote/firmware. La correction fiable est de choisir du matériel connu pour ses réinitialisations amicales à la virtualisation, plus une topologie correcte.

6) SR-IOV est‑il plus simple sur les plateformes Intel ou AMD ?

Le succès SR-IOV dépend fortement du modèle/firmware de la NIC, de la maturité du pilote et de la correction de l’IOMMU.
Les plateformes Intel et AMD peuvent bien exécuter SR-IOV. L’expérience « la plus simple » vient généralement des NICs entreprise et des cartes serveurs avec un BIOS mature.

7) Quelle est la manière la plus rapide de savoir si le pass-through sera indolore sur un hôte ?

Vérifiez les groupes IOMMU et testez les cycles de reboot. Si le périphérique est proprement isolé et que vous pouvez redémarrer l’invité de manière répétée sans redémarrer l’hôte, vous êtes à 80 % du chemin.
Les 20 % restants sont l’optimisation de performance et la gestion des cas limites.

8) Les versions du noyau importent‑elles pour le pass-through VT-d/AMD‑Vi ?

Oui. IOMMU, VFIO et les quirks PCIe reçoivent des corrections au fil du temps. Si vous chassez des fautes rares ou des problèmes de reset, des noyaux plus récents peuvent aider.
Mettez à jour de manière méthodique : une variable à la fois, avec un plan de retour arrière.

9) Passer un disque NVMe est‑ce une bonne idée ?

Cela peut être excellent pour les performances et pour les appliances de stockage qui veulent le contrôle direct.
Mais les NVMe peuvent partager des groupes IOMMU avec d’autres périphériques chipset sur certaines cartes, et vous devez éviter de passer quoi que ce soit dont l’hôte a besoin pour démarrer.

10) Dois‑je choisir Intel ou AMD pour une build Proxmox/KVM avec pass-through ?

Choisissez la carte mère + plateforme qui produit des groupes propres pour vos périphériques cibles et qui a un bon support firmware.
Si vous possédez déjà le matériel, évaluez‑le avec les tâches d’inspection de groupes ci‑dessus avant de concevoir le service autour.

Prochaines étapes pratiques

Si vous hésitez entre Intel VT-d et AMD‑Vi pour le pass-through, ne le traitez pas comme une préférence de marque.
Traitez‑le comme un problème de chaîne d’approvisionnement : choisissez une plateforme où la topologie de la carte et la maturité du firmware correspondent à vos besoins d’isolation.

Pour de nouvelles constructions : présélectionnez des cartes, puis vérifiez la qualité rapportée des groupes IOMMU pour vos types de périphériques et slots exacts.
Pour des hôtes existants : exécutez les tâches d’énumération de groupes, confirmez le remappage des interruptions et testez les cycles de redémarrage sous charge.
Pour les déploiements en production : standardisez une checklist de pré‑vol, contrôlez les mises à jour BIOS et noyau, et documentez quels slots sont « sûrs pour le pass-through ».

La condition de victoire n’est pas « débit maximal ». C’est « pas de surprises au redémarrage ». Quand vous y arrivez, VT-d et AMD‑Vi paraissent tous deux excellents.