IOMMU activé, mais les périphériques partagent un groupe ? Réparez votre topologie PCIe comme un pro

Le modèle mental : qu’est-ce qu’un groupe IOMMU réellement

Un groupe IOMMU est l’ensemble des fonctions PCIe qui ne peuvent pas être isolées de manière fiable les unes des autres pour le DMA. Si un périphérique d’un groupe peut initier des transactions DMA atteignant la mémoire mappée d’un autre périphérique sans être bloqué, le noyau les considère comme inseparables. VFIO ne « veut » pas de groupes ; il applique l’isolation que le matériel est capable de prouver.

Pourquoi « IOMMU activé » n’est pas la victoire que vous croyez

Activer l’IOMMU (Intel VT-d / AMD-Vi) donne à la plateforme la capacité de traduire et de restreindre le DMA. Cela ne garantit pas que chaque endpoint PCIe obtienne son propre bac à sable net. L’isolation dépend de la chaîne de confiance entre l’endpoint et le CPU : le port racine, tous les ports en aval, les switches PCIe éventuels et la disponibilité des Access Control Services (ACS) et des contrôles associés le long de ce chemin.

La frontière du groupe est généralement une frontière de bridge

En pratique, les frontières de groupes IOMMU s’alignent souvent sur les bridges/ports PCIe capables d’appliquer la séparation. Si vous avez un seul port aval alimentant plusieurs endpoints (ou un switch qui n’expose pas ou n’active pas correctement l’ACS), Linux peut les regrouper. Ce n’est pas Linux qui fait mauvais esprit. C’est Linux qui refuse de promettre une isolation qu’il ne peut pas prouver.

Idée paraphrasée de James Hamilton (Amazon) : « Mesurez tout, ne supposez rien. » Cela s’applique douloureusement bien aux groupes IOMMU — les hypothèses de topologie sont comment on finit par passer son contrôleur USB en même temps que son GPU.

Plan de diagnostic rapide (quoi vérifier en premier)

Première étape : confirmez que l’IOMMU est réellement actif, pas seulement « configuré »

• Vérifiez dmesg pour les lignes DMAR/AMD-Vi activées et l’état du remapping.
• Vérifiez que des groupes IOMMU existent sous /sys/kernel/iommu_groups.

Deuxième étape : identifiez précisément les périphériques qui vous intéressent et leur chemin en amont

• Mappez le GPU/HBA/NIC aux adresses PCI avec lspci -nn.
• Parcourez l’arbre PCIe avec lspci -tv et lspci -vv.
• Trouvez le bridge en amont et vérifiez si l’ACS est présent/activé.

Troisième étape : décidez si cela se corrige en matériel/firmware ou seulement avec des contournements

• Si les périphériques partagent un groupe parce qu’ils sont derrière le même port aval non-ACS : changez d’emplacement de slot, activez les fonctions du BIOS ou changez de plateforme.
• Si les périphériques partagent un groupe parce que le fabricant a câblé plusieurs slots derrière un seul root port : acceptez la réalité, redessinez la configuration, ou utilisez ACS override en connaissance de cause.

Règle : si vous faites cela pour de la fiabilité en production ou pour la conformité, considérez l’ACS override comme un dernier recours et documentez-le comme une substance réglementée.

Faits et histoire qui expliquent le bazar actuel

1. VT-d et AMD-Vi sont apparus bien après la virtualisation CPU. La virtualisation précoce se concentrait sur les niveaux de privilège CPU ; l’isolation DMA est arrivée plus tard et a mûri lentement selon les chipsets.
2. PCIe ACS est optionnel. ACS est une capacité que les périphériques/ports peuvent implémenter ou non. Les fonctionnalités optionnelles sont souvent source de problèmes.
3. Les groupes IOMMU sont une couche de politique Linux sur des réalités matérielles. Le noyau forme des groupes en fonction des garanties d’isolation ; ce n’est pas une « fonction passthrough », c’est une frontière de sécurité.
4. Beaucoup de cartes mères grand public optimisent les lanes, pas l’isolation. Fractionner un x16 en x8/x8 via le même root complex peut être acceptable pour les performances mais catastrophique pour les groupes.
5. Les switches PCIe ne sont pas des boîtes magiques d’isolation. Certains switches implémentent bien ACS ; d’autres non, ou la configuration firmware le laisse désactivé. Même référence matérielle, résultat différent selon la carte.
6. Les périphériques multifonctions peuvent être inseparables par conception. Un GPU avec fonction audio est typiquement un seul périphérique physique avec plusieurs fonctions ; ces fonctions restent souvent dans le même groupe IOMMU.
7. « ACS override » existe parce que les gens l’ont demandé. Le noyau a reçu des options pour assouplir le regroupement pour les cas d’utilisation de virtualisation. C’est pragmatique, pas idéologique.
8. Thunderbolt et PCIe externes apportent des bizarreries supplémentaires. Les bridges hotplug et les niveaux de sécurité compliquent la confiance DMA et le comportement de regroupement.
9. SR-IOV a changé les attentes. Dès que les NICs ont pu exposer plusieurs VFs, tout le monde a attendu une isolation propre — puis a découvert que la plateforme décide toujours des groupes.

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

Voici les vérifications que j’exécute quand quelqu’un envoie « IOMMU activé mais les groupes sont partagés ». Chaque tâche inclut : une commande, ce que vous pouvez voir, et ce qu’il faut faire ensuite.

Task 1: Confirm kernel sees an active IOMMU (Intel)

cr0x@server:~$ dmesg | grep -E "DMAR|IOMMU"
[    0.012345] DMAR: IOMMU enabled
[    0.012678] DMAR: Host address width 39
[    0.013210] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.015432] DMAR: Intel(R) Virtualization Technology for Directed I/O

Sens : la ligne « IOMMU enabled » est celle que vous voulez voir. Si vous ne voyez que les tables DMAR mais pas l’activation, vous ne faites pas réellement de remapping DMA.

Décision : Si elle manque, corrigez le BIOS (VT-d) et les arguments du noyau (intel_iommu=on) avant de perdre du temps sur les groupes.

Task 2: Confirm kernel sees an active IOMMU (AMD)

cr0x@server:~$ dmesg | grep -E "AMD-Vi|IOMMU"
[    0.010101] AMD-Vi: IOMMU performance counters supported
[    0.010202] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    0.010303] AMD-Vi: Interrupt remapping enabled

Sens : AMD-Vi trouvé plus le remappage d’interruptions activé est un bon signe pour l’assignation sûre des périphériques.

Décision : Si le remappage d’interruptions est désactivé, envisagez des mises à jour firmware et des options BIOS ; certaines configurations deviennent fragiles sans lui.

Task 3: Verify IOMMU groups exist

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups | head
0
1
2
3
4
5
6
7
8
9

Sens : Les groupes existent. Si le répertoire est vide ou absent, vous n’avez pas le groupement IOMMU actif.

Décision : Pas de groupes signifie stop et corrigez l’activation (BIOS/noyau). Des groupes présents signifie passez à la topologie.

Task 4: Print groups with device names (fast inventory)

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,35p'
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1234]
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:5678]

Group 1
00:14.0 USB controller [0c03]: Intel Corporation Device [8086:a36d]
00:14.2 RAM memory [0500]: Intel Corporation Device [8086:a36f]

Group 2
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:228b]

Sens : Cela vous dit si le GPU est isolé (il partage souvent sa fonction audio, ce qui est normal) ou piégé avec des périphériques non liés (mauvais).

Décision : Si votre périphérique cible partage avec des contrôleurs non liés, vous devez comprendre le port en amont et l’ACS.

Task 5: Identify the device and its kernel driver (who owns it)

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2484] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:xxxx]
	Kernel driver in use: nouveau
	Kernel modules: nouveau, nvidiafb

Sens : Si un pilote hôte est lié, le passthrough VFIO vous combattra au démarrage ou au lancement de la VM.

Décision : Liez à vfio-pci (ou stub) seulement après avoir confirmé que le groupe est acceptable. Ne « corrigez » pas le groupement en changeant les bindings ; ça ne résout pas la topologie.

Task 6: Show PCIe topology as a tree (find the parent bridge)

cr0x@server:~$ lspci -tv
-+-[0000:00]-+-00.0  Host bridge
 |           +-01.0-[01]----00.0  VGA compatible controller
 |           |            \-00.1  Audio device
 |           +-14.0  USB controller
 |           +-17.0  SATA controller
 |           \-1d.0-[02]----00.0  Ethernet controller

Sens : Votre GPU est derrière 00:01.0. Si plusieurs endpoints sont sous le même segment aval et regroupés, le port en amont peut ne pas isoler.

Décision : Si le slot GPU et un contrôleur embarqué sont sous le même bridge dans l’arbre, vous avez probablement une contrainte de câblage/topologie. Envisagez de déplacer les cartes/slots.

Task 7: Inspect ACS capabilities on the upstream port

cr0x@server:~$ sudo lspci -vv -s 00:01.0 | grep -A8 -i "Access Control Services"
	Access Control Services
		ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+
		ACSCtl: SrcValid+ TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-

Sens : La capacité existe, mais les contrôles peuvent être désactivés. Certaines plateformes laissent les bits ACSCtl à zéro.

Décision : Si ACSCap manque entièrement sur les ports concernés, vous avez peu de chances d’obtenir des séparations propres sans contournements ou matériel différent. Si présent mais désactivé, le firmware/noyau peut être capable de l’activer.

Task 8: Check whether your platform is using translation mode you expect

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0 root=UUID=... ro quiet intel_iommu=on iommu=pt

Sens : intel_iommu=on active le remappage. iommu=pt met le passthrough pour les périphériques hôtes (améliore souvent les performances pour les périphériques non assignés).

Décision : Si vous déboguez l’isolation, gardez les choses simples : activez explicitement l’IOMMU, évitez les paramètres exotiques jusqu’à ce que vous compreniez la base.

Task 9: Confirm interrupt remapping / posted interrupts state (sanity for passthrough)

cr0x@server:~$ dmesg | grep -E "Interrupt Remapping|IR|x2apic" | head -n 20
[    0.013333] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.013444] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.

Sens : Le remappage IRQ réduit la probabilité que des interruptions soient livrées au mauvais endroit lors d’une assignation.

Décision : S’il est désactivé, considérez le passthrough comme plus risqué ; priorisez les mises à jour firmware ou les changements de plateforme si c’est pour la production.

Task 10: Check whether your GPU is in a group with a bridge you don’t control

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

Sens : Confirme le numéro de groupe du point de vue du périphérique.

Décision : Si le groupe contient des périphériques que vous ne pouvez pas passer ensemble, votre prochaine étape est la remédiation de topologie, pas des réglages VFIO.

Task 11: Identify which devices share the group (the “who else is in the room” check)

cr0x@server:~$ G=$(basename $(readlink /sys/bus/pci/devices/0000:01:00.0/iommu_group)); for d in /sys/kernel/iommu_groups/$G/devices/*; do lspci -nnk -s ${d##*/}; echo; done
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2484] (rev a1)
	Kernel driver in use: nouveau
	Kernel modules: nouveau, nvidiafb

01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:228b] (rev a1)
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

Sens : GPU + sa fonction audio seulement ? C’est typiquement acceptable. GPU + USB + SATA ? C’est une contrainte de conception.

Décision : Si vous voyez des périphériques non liés, vous choisissez entre : déplacer les cartes/slots, paramètres BIOS, changer de carte/CPU, ou ACS override (avec risques).

Task 12: Check for a PCIe switch in the path (common in servers, sneaky in workstations)

cr0x@server:~$ lspci -nn | grep -i "PCI bridge\|PLX\|Broadcom\|PEX"
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:5678]
03:00.0 PCI bridge [0604]: Broadcom / PLX Device [10b5:8725]
03:01.0 PCI bridge [0604]: Broadcom / PLX Device [10b5:8725]

Sens : Les switches apparaissent souvent comme plusieurs fonctions bridge. Qu’ils isolent ou non dépend d’ACS et de la configuration.

Décision : Si un switch est impliqué, inspectez l’ACS sur ces ports aval, pas seulement sur le port racine.

Task 13: Validate the kernel’s view of isolation with a targeted ACS scan

cr0x@server:~$ for dev in 00:01.0 03:00.0 03:01.0; do echo "== $dev =="; sudo lspci -vv -s $dev | grep -A6 -i "Access Control Services"; done
== 00:01.0 ==
	Access Control Services
		ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+
		ACSCtl: SrcValid+ TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
== 03:00.0 ==
	Access Control Services
		ACSCap: SrcValid+ TransBlk- ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans-
		ACSCtl: SrcValid+ TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-

Sens : Les capacités varient selon le port. Certains ports peuvent faire la redirection de requêtes mais pas le forwarding en amont, etc.

Décision : Si les ports requis manquent d’ACS, vous n’obtenez pas d’isolation sûre, point final. Planifiez des changements matériels ou acceptez le regroupement.

Task 14: Check if the platform is forcing “above 4G decoding” / Resizable BAR effects

cr0x@server:~$ dmesg | grep -iE "Resizable BAR|Above 4G|pci 0000"
[    0.222222] pci 0000:01:00.0: BAR 0: assigned [mem 0x8000000000-0x800fffffff 64bit pref]
[    0.222333] pci 0000:01:00.0: BAR 2: assigned [mem 0x8010000000-0x8011ffffff 64bit pref]

Sens : Les grands mappings BAR ne sont pas un problème de regroupement, mais ils peuvent exposer des bugs firmware et des problèmes d’allocation de ressources qui se déguisent en douleur VFIO.

Décision : Si vous voyez des erreurs d’allocation de ressources ou des BAR manquantes, corrigez cela d’abord ; une initialisation de périphérique cassée peut vous faire courir après de faux « problèmes IOMMU ».

Task 15: Confirm VFIO viability without committing (dry-run thinking)

cr0x@server:~$ sudo dmesg | tail -n 20
[  120.123456] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[  120.123789] vfio-pci 0000:01:00.0: vfio_bar_restore: reset recovery - restoring BARs
[  120.124111] vfio-pci 0000:01:00.1: enabling device (0000 -> 0002)

Sens : Quand vous liez, le noyau journalise ce qu’il fait. Les erreurs ici indiquent souvent des quirks de reset, pas du regroupement.

Décision : Si le binding fonctionne proprement mais que le groupe est partagé, ne vous emballez pas. Vous ne pouvez toujours pas assigner en toute sécurité une partie d’un groupe partagé.

Blague #1 : Un groupe IOMMU, c’est comme une réservation de salle : si votre contrôleur USB arrive, tout le monde repart avec vos marqueurs du tableau blanc.

Clinique de topologie PCIe : ports racine, bridges, switches et ACS

Commencez par le chemin en amont, pas l’endpoint

Les gens s’obsèdent sur le modèle de GPU et oublient la partie ennuyeuse : le tissu PCIe. Votre périphérique endpoint n’est isolable qu’à la hauteur du bridge le moins capable entre lui et le CPU. Cela inclut :

• Port racine / root complex sur le CPU ou le chipset.
• Ports en aval (souvent partie d’un switch ou du tissu chipset).
• Switches PCIe (PLX/Broadcom, ASMedia, etc.).
• Endpoints intégrés (audio embarqué, contrôleurs USB, SATA, Wi‑Fi).

ACS : ce qu’il fait et pourquoi il change le regroupement

Access Control Services est un ensemble de fonctionnalités qui aident à prévenir ou contrôler le trafic peer-to-peer et à garantir que les requêtes sont correctement routées en amont là où l’IOMMU peut appliquer la politique. En termes simples : ACS aide à empêcher que des périphériques derrière le même switch/port communiquent entre eux hors du contrôle de l’IOMMU.

Linux utilise l’information ACS (et d’autres indices de topologie) pour décider si les périphériques peuvent être séparés en différents groupes IOMMU. Si la plateforme ne peut pas garantir l’isolation, le groupe reste grand.

Schémas typiques « pourquoi mon GPU est groupé avec X ? »

• Port aval du chipset qui dessert plusieurs périphériques : plusieurs contrôleurs embarqués sont derrière un seul port du chipset sans ACS, donc ils sont groupés.
• Switch partagé : deux slots physiques sont en réalité derrière un seul switch PCIe sans configuration ACS correcte.
• Muxing des lanes sur la carte mère : activer un second slot M.2 reroute les lanes et change quels périphériques partagent un root port.
• Périphériques multifonctions : vidéo GPU + audio GPU partagent. C’est normal et généralement souhaitable pour le passthrough.

Ce que « réparer la topologie » signifie réellement

Ce n’est pas mystique. C’est l’une de ces actions :

1. Déplacer la carte vers un autre slot qui dépend d’un autre root port (idéalement relié au CPU).
2. Arrêter d’utiliser un slot/M.2 qui force le partage de lanes avec quelque chose que vous devez isoler.
3. Activer les fonctions firmware qui exposent ACS ou un remapping correct (lorsqu’elles existent).
4. Utiliser du matériel qui supporte réellement l’isolation : cartes workstation/server, switches connus, CPUs avec suffisamment de lanes.
5. Accepter le regroupement et passer l’intégralité du groupe si c’est sûr et opérationnellement acceptable.

La plupart des « problèmes de groupe IOMMU » viennent du fait que votre carte mère vous dit silencieusement qu’elle a été conçue pour le RGB de gaming, pas pour des frontières DMA fiables.

Paramètres BIOS/firmware qui comptent (et ceux qui n’en valent pas la peine)

Paramètres qui comptent généralement

• Intel : VT-d (Directed I/O) doit être activé. VT-x seul ne suffit pas.
• AMD : SVM active la virtualisation CPU ; IOMMU (ou « AMD-Vi ») active le remappage DMA. Vous avez généralement besoin des deux pour le passthrough.
• Above 4G decoding : souvent requis pour les GPU modernes et plusieurs périphériques PCIe ; cela peut aussi influencer la façon dont le firmware alloue les ressources.
• SR-IOV : l’activer peut changer la configuration des ports aval et ARI ; pas nécessaire pour le passthrough pur, mais pertinent pour les VFs NIC.
• Bascules PCIe ACS / « PCIe ARI » : si votre BIOS expose quoi que ce soit ressemblant à ACS, activez-le. Si ARI est exposé, activez-le si vous utilisez SR-IOV intensivement.

Paramètres que les gens modifient par désespoir

• CSM (Compatibility Support Module) : le désactiver peut aider l’initialisation des GPU modernes et le sizing des BAR, mais ça ne divisera pas magiquement les groupes IOMMU.
• Forcer la vitesse PCIe Gen : règle parfois la stabilité du lien ; affecte rarement le regroupement.
• « Mode gaming » : si le BIOS propose ça, reculez prudemment.

Mises à jour firmware : la correction ingrate

Les mises à jour du BIOS de la carte mère et du BMC/UEFI serveur peuvent modifier l’exposition de l’ACS, les quirks de remapping et l’allocation des ressources PCIe. Ce n’est pas glamour. C’est aussi la différence entre « ça marche pendant des mois » et « panne DMA aléatoire à 3 h du matin ».

Paramètres noyau, ACS override et quand les refuser

Les paramètres que vous verrez dans la nature

• intel_iommu=on / amd_iommu=on : activation explicite.
• iommu=pt : mode passthrough pour les périphériques hôtes (compromis performance/latence).
• pcie_acs_override=downstream,multifunction : forcer le noyau à traiter certains ports comme si l’ACS séparait.

Ce que fait réellement ACS override

Il change les décisions de regroupement de Linux en faisant comme si certains composants PCIe fournissaient des frontières d’isolation alors qu’ils n’affichent pas les capacités ACS appropriées. Cela peut produire des groupes IOMMU plus petits et rendre VFIO content.

Cela peut aussi créer une frontière d’isolation qui n’est pas réelle. Dans un modèle de menace hostile ou en cas de périphérique compromis, ce n’est pas acceptable. En homelab, beaucoup prennent ce risque. En production, vous devez avoir une conversation sérieuse avec les responsables sécurité et risque.

Quand j’utilise ACS override

• Environnements de laboratoire où le seul « attaquant » est ma propre impatience.
• Validation temporaire sur une plateforme que nous prévoyons déjà de remplacer, pour prouver que la charge est viable.
• Situations où le périphérique passthrough est le seul endpoint DMA significatif dans le groupe et que les autres sont effectivement inertes (rare).

Quand je refuse ACS override

• Environnements multi‑locataires.
• Tout ce qui a des exigences de conformité autour de l’isolation.
• Systèmes où le groupe partagé contient du stockage ou du réseau dont l’hôte dépend pour survivre.

Blague #2 : L’ACS override, c’est comme mettre du ruban « Interdit d’entrer » sur une porte sans porte. Ça donne l’impression d’être plus en sécurité jusqu’à ce que quelqu’un passe au travers.

Spécificités de la pile de virtualisation : Proxmox/KVM, bare metal et machines « enterprise »

Reality check KVM/VFIO

VFIO est strict parce que c’est le dernier adulte dans la pièce. Si un groupe contient plusieurs périphériques, VFIO veut que vous assigniez l’intégralité du groupe à un seul invité, car le scinder est la façon dont vous vous retrouvez avec un comportement indéfini et des failles de sécurité.

En pratique, « j’ai besoin de passer seulement le GPU » signifie que le groupe du GPU doit contenir uniquement les fonctions du GPU (et peut‑être un contrôleur USB si vous passez intentionnellement tout un contrôleur pour des périphériques d’entrée).

Proxmox et piles similaires

Proxmox facilite la visualisation des groupes et la configuration de VFIO, mais il ne peut pas réparer une carte mère qui a soudé votre slot GPU au même port aval que votre contrôleur SATA. Si Proxmox montre un gros groupe, croyez‑y.

Cartes workstation vs server

Les serveurs ont souvent une meilleure distribution de lanes et des designs de switch PCIe plus prévisibles. Les workstations peuvent aussi être bonnes. Les cartes grand public sont le far west : parfois vous avez de la chance, parfois le tissu chipset est une navette de fête.

Note pour les ingénieurs stockage : ne partagez pas des groupes avec des HBA à la légère

Si le groupe contient votre HBA ou contrôleur NVMe utilisé par l’hôte, vous êtes à une mauvaise décision d’offrir votre contrôleur de stockage à une VM. Ce n’est pas « tuning de performance ». C’est la roulette de la perte de données.

Trois mini-récits d’entreprise du terrain

1) L’incident causé par une mauvaise hypothèse

Ils construisaient un petit cluster GPU interne pour accélérer les builds et faire un peu d’inférence ML. Rien d’exotique : KVM, VFIO, quelques GPU milieu de gamme et une carte mère standardisée parce que les achats aimaient « la standardisation ». Quelqu’un a vérifié que l’IOMMU était activé dans le BIOS et a vu DMAR dans dmesg. Ils ont déclaré la plateforme « prête pour le passthrough ».

Les deux premiers nœuds ont fonctionné parce que les GPU étaient installés dans un slot câblé directement aux ports racine CPU. Le troisième nœud a été assemblé légèrement différemment — même carte, mais une carte porteuse NVMe en plus. Ce carrier a changé la bifurcation des lanes et a poussé le slot GPU derrière un chemin de switch du chipset. Personne n’a remarqué car les GPUs apparaissaient toujours correctement dans lspci.

Sur ce nœud, le GPU se retrouvait dans le même groupe IOMMU qu’un contrôleur USB et un contrôleur SATA. L’ingénieur configurant VFIO a supposé que « les groupes sont juste une chose de Linux » et a forcé ACS override pour les séparer. Le système a passé les tests initiaux. Une semaine plus tard, pendant une période de builds intense, l’hôte a connu des erreurs SATA intermittentes puis un système de fichiers est passé en lecture seule. Le postmortem n’était pas glamour : ils avaient créé une frontière d’isolation factice, et un DMA intensif du GPU corrélait avec les anomalies I/O de l’hôte.

La correction a été douloureusement ordinaire : déplacer le GPU vers un slot différent, désactiver l’option de partage de lanes, et standardiser le build pour que chaque nœud ait la même topologie PCIe. Ils ont aussi banni l’ACS override en production sauf approbation. La vraie leçon n’était pas « ACS override est maléfique ». C’était que « IOMMU activé » n’équivaut pas à « isolation IOMMU atteinte », et la dérive de topologie est un bug de fiabilité.

2) L’optimisation qui s’est retournée contre eux

Une équipe voulait réduire la latence pour une VM de traitement de paquets à haut débit. Ils prévoyaient de passer un NIC et un GPU pour de l’inférence en ligne. L’hôte avait aussi un NVMe rapide utilisé pour le cache local. Quelqu’un a noté que le NIC et le NVMe étaient dans le même groupe IOMMU sur une génération de plateforme particulière.

Au lieu de changer le matériel, ils ont fait un mouvement « intelligent » : passer tout le groupe à la VM, en raisonnant que la VM était « la charge réelle » et que l’hôte pourrait booter depuis un DOM SATA miroir de toute façon. Sur le papier, ça réduisait l’overhead et évitait de gérer des splits de groupe. Ça donnait même de bons benchmarks.

Puis l’opération est arrivée avec les questions ennuyeuses. Comment patcher l’hôte si la VM possède le contrôleur de stockage utilisé pour le cache et les logs ? Comment capturer des crash dumps ? Que se passe-t-il si la VM se fige et maintient la fonction PCIe dans un mauvais état de reset ? La réponse : vous redémarrez et espérez. Ce n’est pas un plan, c’est un rituel.

L’optimisation a échoué quand la VM a rencontré un bug de pilote et a cessé de répondre. L’hôte était toujours « up » mais avait perdu l’accès aux périphériques passthrough, y compris le NVMe de cache. Le monitoring est devenu bruyant et le nœud a vacillé. Ils sont revenus à une conception moins « efficace » : séparer les groupes IOMMU en choisissant une disposition de slots différente et utiliser une plateforme avec plus de root ports, en tenant le stockage critique hors de tout groupe passthrough. Les performances ont légèrement baissé. La disponibilité a beaucoup augmenté. Personne n’a regretté les exploits.

3) La pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre organisation exécutait des charges mixtes : des VMs avec passthrough NIC (VFs SR-IOV), d’autres avec passthrough complet pour des accélérateurs spécialisés. Ils avaient déjà été brûlés, donc ils avaient une politique : chaque SKU matériel avait un « manifeste de topologie PCIe » enregistré dans le même repo que le code de provisioning.

Quand une nouvelle série de serveurs est arrivée, l’équipe des achats a substitué une révision de carte mère « compatible » à cause de contraintes d’approvisionnement. Même famille CPU, même châssis, même apparence pour un non‑expert. Le check du manifeste dans le CI a comparé les layouts attendus des groupes IOMMU avec ce qu’un nœud fraîchement booté rapportait. Ça a échoué immédiatement.

Au lieu de découvrir le problème en production après une mise à jour noyau nocturne, ils ont mis le lot en quarantaine. La cause racine était une configuration de switch PCIe différente sur la nouvelle révision : le slot d’accélérateur et un contrôleur RAID embarqué partageaient désormais un port aval sans séparation ACS utilisable. Le vendeur a pu fournir une mise à jour firmware pour certains, et pour d’autres la correction a été un riser différent.

La pratique était ennuyeuse : booter, collecter lspci, collecter les mappings de groupes, diff avec l’attendu, échouer vite. Ça a économisé des jours de débogage et empêché un incident. C’est le genre de « paperasse » qui augmente réellement la disponibilité des systèmes, ce pourquoi les gens la détestent jusqu’à ce qu’elle les sauve.

Erreurs courantes : symptôme → cause racine → correction

1) « J’ai activé l’IOMMU mais /sys/kernel/iommu_groups est vide »

Symptôme : Pas d’entrées dans le répertoire groups, VFIO se plaint, les guides disent « activez IOMMU ».

Cause racine : VT-d/AMD-Vi est désactivé dans le BIOS, ou les paramètres de démarrage du noyau ne l’activent pas, ou vous êtes dans un mode firmware qui cache le remapping.

Correction : Activez VT-d/AMD IOMMU dans le BIOS ; ajoutez intel_iommu=on ou amd_iommu=on ; mettez à jour le BIOS si les tables DMAR sont corrompues.

2) « Mon GPU partage un groupe avec USB/SATA/NIC sur la carte mère »

Symptôme : Le groupe inclut le GPU plus des contrôleurs embarqués non liés.

Cause racine : Les périphériques sont derrière le même port/switch aval sans isolation ACS ; le câblage de la carte mère privilégie le partage de lanes plutôt que l’isolation.

Correction : Déplacez le GPU sur un slot attaché au CPU ; désactivez les fonctions de partage de lanes ; évitez les combos M.2/riser qui reroutent les lanes ; choisissez une carte avec une meilleure distribution des root ports.

3) « J’ai utilisé ACS override et ça marche, mais j’ai des erreurs I/O hôtes aléatoires »

Symptôme : Le passthrough fonctionne, mais l’hôte subit des anomalies PCIe/SATA/NVMe intermittentes sous charge.

Cause racine : La séparation forcée a créé une frontière que le matériel n’applique pas ; les interactions peer-to-peer et DMA deviennent indéfinies.

Correction : Retirez l’ACS override ; redessinez la topologie ; isolez via de vrais ports ACS-capables ou passez l’intégralité du groupe réel si c’est sûr.

4) « Les problèmes de reset GPU ressemblent à des problèmes IOMMU »

Symptôme : L’arrêt d’une VM laisse le GPU inutilisable, le démarrage suivant échoue, erreurs dans dmesg concernant le reset.

Cause racine : Quirks de reset GPU (FLR mal pris en charge), comportement du pilote fournisseur, ou gestion des multifonctions — pas le regroupement IOMMU.

Correction : Utilisez des mécanismes de reset supportés par le fournisseur (si applicables), envisagez d’autres modèles de GPU, assurez-vous que les deux fonctions GPU sont liées correctement, évitez les réassignations à chaud en production.

5) « Les VFs SR-IOV sont dans des gros groupes et ne peuvent pas être assignées proprement »

Symptôme : Les VFs partagent des groupes avec les PFs et d’autres périphériques de façon inattendue.

Cause racine : Configuration ARI/ACS/firmware ; la plateforme les groupe parce que l’isolation ne peut pas être garantie.

Correction : Activez SR-IOV et le support ARI dans le BIOS si disponible ; assurez-vous que le firmware est à jour ; utilisez des NICs et plateformes connues pour bien se comporter avec VFIO.

6) « Tout est dans un seul groupe sur un laptop/mini PC »

Symptôme : Un groupe géant, pas de splits propres, rêves d’eGPU qui s’évanouissent.

Cause racine : Topologie intégrée avec ACS limité, tissu rooted au chipset, et modèle de sécurité non conçu pour une isolation déterministe.

Correction : Acceptez les limitations ; utilisez des périphériques paravirtualisés ; ou changez pour du matériel conçu pour cela.

Listes de contrôle / plan pas à pas

Étape par étape : passer de « groupe partagé » à « isolation propre »

1. Activation de base : confirmez DMAR/AMD-Vi activés dans dmesg et que des groupes existent.
2. Identifier les cibles : listez les adresses PCI des périphériques que vous voulez assigner.
3. Mapper les groupes : affichez l’appartenance aux groupes et confirmez qui partage avec qui.
4. Dessinez la chaîne en amont : utilisez lspci -tv pour localiser les bridges/ports en amont.
5. Vérifiez l’ACS sur chaque port pertinent : lspci -vv sur les ports root/downstream du chemin.
6. Tentez le correctif de topologie facile : déplacez la carte vers un autre slot ; retirez/déplacez les cartes M.2/riser qui causent des reroutages de lanes.
7. Re-vérifiez les groupes après chaque changement physique : ne faites pas plusieurs changements à la fois ; vous perdrez la causalité.
8. Paramètres firmware : activez VT-d/AMD IOMMU, Above 4G decoding, SR-IOV/ARI si pertinent ; mettez à jour le BIOS.
9. Décidez de votre position sur le risque : si vous devez utiliser ACS override, notez pourquoi, ce qui est dans le groupe, et quel est le rayon d’impact.
10. Liez les pilotes seulement après que l’isolation est correcte : assignez les périphériques à vfio-pci une fois les groupes sains.
11. Testez les chemins de reset : démarrez/arrêtez la VM plusieurs fois et surveillez le blocage des périphériques.
12. Operationalisez : capturez la topologie + le mapping des groupes comme artefact pour détecter la dérive future.

Checklist : préparation production pour le passthrough

• Les périphériques critiques pour l’hôte ne figurent dans aucun groupe que vous comptez assigner.
• Pas d’ACS override en production sauf approbation explicite et acceptation du risque.
• Versions firmware figées et testées avec contrôles de régression de topologie.
• Comportement de reset des périphériques validé (cold boot, warm reboot, cycles start/stop VM).
• Le monitoring inclut les erreurs AER PCIe, les fautes IOMMU et les resets des pilotes de périphérique.

Checklist : quand il faut arrêter et acheter du matériel différent

• Votre périphérique cible partage un groupe avec des SATA/USB/NVMe chipset critiques pour l’hôte, et il n’y a pas d’autre slot/root port disponible.
• Les ports en amont manquent de la capacité ACS et vous ne pouvez pas changer la topologie.
• Le firmware n’offre pas d’options pertinentes et les mises à jour n’améliorent rien.
• Le système nécessite ACS override pour fonctionner du tout, et vous êtes en environnement multi‑locataire ou soumis à la conformité.

FAQ

1) Si l’IOMMU est activé, pourquoi mes périphériques restent-ils dans le même groupe ?

Parce qu’activer n’est pas isoler. Le regroupement reflète la capacité du tissu PCIe à appliquer la séparation (ACS/comportement des bridges), pas uniquement la présence d’un remappage DMA en théorie.

2) Est‑il normal qu’un GPU et sa fonction audio partagent un groupe ?

Oui. C’est un périphérique physique exposant plusieurs fonctions PCI. Vous passez généralement les deux ensemble.

3) Puis‑je passer en passthrough seulement un périphérique d’un groupe partagé ?

Pas en toute sécurité. VFIO exige une assignation au niveau du groupe car n’importe quel périphérique du groupe pourrait faire du DMA affectant les autres. Si vous le scindez malgré tout (avec des bricolages), vous acceptez un comportement indéfini et un risque de sécurité.

4) Activer « Above 4G decoding » divisera‑t‑il mes groupes IOMMU ?

En général non. Ça aide l’allocation de ressources et le mapping des BAR pour les gros périphériques, ce qui peut corriger des problèmes de boot/probing, mais cela ne crée pas des frontières d’isolation en soi.

5) iommu=pt affecte‑t‑il le regroupement ?

Non. Il affecte la façon dont l’hôte mappe le DMA pour les périphériques que l’hôte conserve, souvent pour améliorer les performances. La formation des groupes dépend de la topologie et d’ACS, pas du mode passthrough vs translation.

6) Quelle est l’alternative la plus sûre si je ne peux pas obtenir des groupes propres ?

N’utilisez pas le passthrough complet. Servez‑vous de périphériques paravirtualisés (virtio), du partage GPU au niveau API (si disponible), ou passez à du matériel avec une meilleure isolation PCIe.

7) Pourquoi mes groupes IOMMU changent quand j’ajoute un disque NVMe ou j’utilise un autre slot M.2 ?

Partage et bifurcation des lanes. Beaucoup de cartes reroutent les lanes selon les sockets peuplés. Cela peut déplacer des périphériques derrière différents bridges/switches et changer l’isolation.

8) L’ACS override est‑il toujours peu sûr ?

Il relaxe les hypothèses d’isolation du noyau. Dans un modèle de menace strict, oui, il sape la garantie que vous croyez avoir. Dans un lab mono‑utilisateur, beaucoup l’acceptent. L’essentiel est d’être honnête sur la frontière que vous faites semblant d’avoir.

9) Mes groupes sont corrects, mais le passthrough échoue toujours. Et après ?

Vérifiez le binding des pilotes, le comportement de reset des périphériques, les erreurs d’allocation de ressources du firmware, et si le périphérique supporte FLR. Le groupement est nécessaire mais pas suffisant.

10) Pourquoi les serveurs « marchent » plus souvent que les desktops pour ça ?

Plus de root ports, un meilleur budget de lanes, des designs de switch plus cohérents et un firmware qui prend ACS et SR-IOV plus au sérieux. Aussi : les fournisseurs s’attendent à ce que les clients virtualisation se plaignent fort.

Conclusion : prochaines étapes qui font réellement avancer les choses

Si l’IOMMU est activé mais que vos périphériques restent dans le même groupe, arrêtez de traiter cela comme un puzzle de paramètres noyau. C’est une investigation de la topologie PCIe. Faites le travail ennuyeux : mappez l’arbre, identifiez les ports en amont, vérifiez les capacités ACS et changez la disposition physique ou la plateforme jusqu’à ce que le matériel puisse prouver l’isolation.

Étapes suivantes :

1. Exécutez la commande d’inventaire des groupes et identifiez les colocataires indésirables dans votre groupe cible.
2. Utilisez lspci -tv et lspci -vv pour trouver la chaîne de bridges en amont et vérifier si l’ACS existe là où ça compte.
3. Tentez un changement de topologie à la fois : déplacez la carte, changez la population M.2, basculez la bifurcation/paramètres PCIe, mettez à jour le firmware.
4. Si vous avez encore besoin d’ACS override, notez le risque, quels périphériques partagent le tissu et ce que signifie une défaillance — puis décidez comme un adulte.
5. Operationalisez : capturez vos groupes IOMMU connus‑bons comme test de régression pour qu’une « petite révision hardware » ne devienne pas votre prochain incident.