Meilleures cartes mères pour des groupes IOMMU propres : quoi vérifier avant d’acheter

Ce que « groupes IOMMU propres » signifie réellement (et pourquoi vous devez vous en soucier)

Un groupe IOMMU est l’ensemble minimal de périphériques PCIe que votre plateforme peut isoler de manière fiable pour les accès DMA (accès direct à la mémoire). Si deux périphériques partagent un groupe, le noyau suppose qu’ils ne peuvent pas être séparés en toute sécurité, parce que le matériel ne fournit pas les frontières de contrôle d’accès nécessaires entre eux.

En pratique, des groupes « propres » signifient :

• Votre périphérique cible est seul dans son groupe (ou seulement associé à une fonction inoffensive que vous pouvez aussi passer, comme la fonction audio HDMI d’un GPU).
• Pas de colocataires surprises comme un contrôleur SATA, un contrôleur USB ou le port racine du chipset qui entraîne la moitié de la carte dans le même groupe.
• Des groupements stables au redémarrage, après mise à jour du BIOS et mises à jour du noyau — parce que votre hôte de production ne doit pas avoir de problèmes de confiance.

Pourquoi c’est important : le passthrough VFIO dépend de la justesse des frontières IOMMU. Si vous passez un périphérique qui partage un groupe IOMMU avec un périphérique utilisé par l’hôte, vous êtes forcé vers trois mauvaises options :

1. Ne pas le passer (l’option « triste mais sûre »).
2. Passer tout le groupe (parfois acceptable, souvent impossible).
3. Utiliser ACS override pour simuler la séparation (parfois ça marche, cela réduit les garanties d’isolation et peut créer des modes d’échec délicieusement confus).

Des groupes propres sont une caractéristique de la carte mère, pas un tour de Linux. Linux ne fait que rapporter ce que la plateforme expose.

Blague #1 : Si votre GPU partage un groupe IOMMU avec votre contrôleur USB, félicitations — votre souris est maintenant un « accessoire graphique ».

Comment les groupes IOMMU se forment : ports racine CPU, chipset et ACS

Le modèle mental : un arbre, avec des postes de péage

PCIe est une hiérarchie. Votre CPU fournit des complexes racine et des ports racine. Votre chipset (PCH chez Intel, « chipset » sur les plateformes AMD grand public) s’accroche au CPU et ajoute d’autres ports en aval, SATA, USB et d’autres contrôleurs intégrés.

Les groupes IOMMU sont influencés par l’endroit où les périphériques se trouvent dans cet arbre et par le fait que les switches/bridges entre eux implémentent ACS (Access Control Services). ACS est la façon dont le tissu empêche que des périphériques fassent du DMA peer-to-peer autour de la frontière IOMMU. Si ACS n’est pas présent (ou n’est pas activé), le noyau regroupe les périphériques parce qu’il ne peut pas prouver l’isolation.

Lignes CPU : le meilleur emplacement

Les périphériques directement attachés aux ports racine du CPU forment généralement de meilleurs groupes que les périphériques derrière le chipset. C’est pourquoi « GPU dans le premier slot x16 câblé au CPU » n’est pas seulement une recommandation de performance — c’est une recommandation d’isolation.

Sur les plateformes modernes, le CPU offre typiquement :

• Un x16 (souvent bifurquable en x8/x8 ou x8/x4/x4) pour GPU/HBA/porteurs NVMe
• Un ou plusieurs liens x4 pour NVMe
• Un lien vers le chipset

Chacun de ces chemins est un endroit naturel où des frontières de groupes IOMMU peuvent se former.

Lignes du chipset : plus de ports, plus de partage

Le chipset est un dispositif de répartition connecté au CPU par un seul uplink (DMI chez Intel, concept similaire chez AMD). Beaucoup de périphériques intégrés sont accrochés au chipset : slots NVMe supplémentaires, contrôleurs SATA, contrôleurs USB, Wi‑Fi, 2.5GbE, parfois même un slot PCIe.

Cela signifie deux choses :

• Les périphériques connectés au chipset peuvent être plus susceptibles de finir dans des groupes IOMMU partagés, surtout si les bridges manquent d’ACS ou si la configuration du firmware est prudente.
• Même si les groupes sont « suffisamment propres », un I/O massif sur des périphériques du chipset peut saturer l’uplink et ressembler à un problème IOMMU alors qu’il s’agit en réalité d’une saturation.

ACS : la fonctionnalité que vous voulez, l’option que vous n’obtenez pas toujours

ACS existe sous plusieurs formes (validation d’origine, redirection de requêtes P2P, redirection des complétions, forwarding en amont). En termes pratiques pour VFIO, vous voulez que la plateforme expose suffisamment d’ACS pour que les périphériques en aval puissent être séparés en groupes distincts.

Certaines cartes mères exposent des bascules dans le BIOS comme :

• Above 4G decoding (souvent requis pour les GPU avec de larges BAR et pour un passthrough stable)
• Resizable BAR (aide parfois les performances ; peut aussi compliquer les resets et le mapping sur certaines piles)
• IOMMU / SVM (AMD) ou VT-d (Intel)
• ACS enable/disable ou options « PCIe ARI/ACS » (plus rares sur les cartes grand public)
• Bifurcation PCIe par slot

Les constructeurs ne standardisent pas les noms. La moitié du travail consiste à connaître les synonymes à chercher dans le BIOS.

Ne confondez pas « groupement » et « câblage des lignes »

Le câblage des lignes détermine la bande passante et l’attachement (CPU vs chipset). Le groupement IOMMU concerne les frontières d’isolation. Ils sont corrélés, mais pas parfaitement. J’ai vu des cartes avec un câblage de lignes excellent mais un groupement médiocre parce que le firmware n’exposait pas correctement ACS. J’ai aussi vu l’inverse : des cartes grand public avec des groupes étonnamment décents parce que les ports racine CPU sont propres et que les bridges du chipset implémentent ACS correctement.

Signaux d’achat : quoi rechercher avant d’acheter

1) Priorisez les slots connectés au CPU pour les périphériques que vous prévoyez de passer

Avant d’acheter, définissez ce que vous passerez et cartographiez-le sur les lignes CPU :

• Passthrough GPU principal : premier slot x16 câblé au CPU.
• Second GPU / NIC haut débit : un deuxième slot câblé au CPU (x8) si disponible.
• Passthrough NVMe : M.2 attaché au CPU (souvent indiqué « from CPU » dans le manuel, si vous avez de la chance).
• Passthrough HBA : slot câblé au CPU si vous tenez à des groupes propres et à des réinitialisations prévisibles.

Si une carte n’a qu’un seul slot câblé au CPU et que tout le reste passe par le chipset, votre vie IOMMU se complique vite.

2) Exigez un support BIOS explicite pour IOMMU/VT-d et Above 4G decoding

Si le manuel, les captures d’écran du BIOS ou les forums de support n’affichent pas de bascules pour :

• IOMMU / SVM (AMD) ou VT-d (Intel)
• Above 4G decoding

…faites demi-tour. « Ça doit probablement être là » est la façon dont vous vous retrouvez à utiliser ACS override et à vous convaincre que c’est acceptable parce que le serveur « n’est pas exposé ». Ce n’est pas un modèle de sécurité ; c’est de l’optimisme.

3) Cherchez des fonctionnalités orientées workstation : bifurcation, SR-IOV, firmware stable

Les cartes grand public peuvent fonctionner. Beaucoup le font. Mais si c’est un hyperviseur de production (ou un homelab traité comme tel), les cartes destinées aux workstations/serveurs réduisent les bizarreries :

• Bifurcation PCIe par slot (x16 → x8/x8, x8/x4/x4) pour utiliser des cartes porteuses NVMe sans switch PCIe.
• Cadence firmware AGESA/ME stable où les mises à jour ne changent pas aléatoirement l’énumération PCIe.
• Meilleure journalisation des erreurs (logs WHEA, comportement AER) et moins de « optimisations gaming ».

4) Comprenez que les périphériques intégrés peuvent contaminer les groupes

Les cartes mères aiment regrouper des contrôleurs « à valeur ajoutée » derrière un bridge partagé : puces SATA supplémentaires, contrôleurs USB supplémentaires, Wi‑Fi, contrôleurs RGB, parfois même des ajouts Thunderbolt. Chacun est un périphérique de plus qui peut se coller dans un groupe que vous vouliez garder propre.

Conseils pratiques :

• Si vous voulez des groupes propres, n’achetez pas la carte avec le plus d’équipements. Achetez la carte avec le plus de choses ennuyeuses.
• Privilégiez les NIC Intel (ou Broadcom serveur) plutôt que des NIC gaming aléatoires si c’est sérieux. Pas strictement IOMMU, mais cela réduit le chaos des pilotes.
• Évitez les cartes qui routent le second « x16 » via le chipset tout en le vendant comme x16 mécanique. Mécanique n’est pas électrique.

5) Consultez les rapports communautaires sur les groupes, mais considérez-les comme des prévisions météo

Les rapports utilisateurs des groupes IOMMU sont utiles, mais pas sacrés. La version du BIOS, la génération CPU et même quels slots M.2 sont peuplés peuvent changer la topologie. Utilisez ces rapports pour établir une présélection, pas pour signer un bon de commande.

6) Décidez maintenant : acceptez-vous ACS override ?

ACS override dans Linux peut séparer des groupes en faisant comme si ACS existait là où il n’existe pas. C’est un outil ; c’est aussi un compromis. Dans des environnements où l’isolation compte (multi-tenant, charges non fiables, conformité), considérez que c’est inacceptable.

Dans un homelab mono-utilisateur où vous faites confiance à vos VM et cherchez la fonctionnalité, cela peut être « suffisant », mais traitez-le comme un échafaudage temporaire, pas comme une fondation.

7) Prévoyez les réinitialisations et la gestion des quirk (surtout pour les GPU)

Des groupes propres ne sont pas la seule partie « dépendante de la carte mère » du passthrough. Le comportement de reset GPU, le support FLR (Function Level Reset) et la gestion d’alimentation de la plateforme peuvent déterminer si une VM redémarre proprement ou bloque un périphérique jusqu’au reboot de l’hôte.

Si vous achetez spécifiquement pour le passthrough GPU, orientez-vous vers :

• Des plateformes connues pour bien se comporter avec votre fournisseur GPU (AMD/NVIDIA/Intel ARC) sous VFIO
• Des cartes avec moins de switches PCIe tiers et moins de partage « malin » des lignes

Conseils par plateforme : AMD vs Intel, grand public vs workstation vs serveur

AMD grand public (AM4/AM5) : souvent de bons groupes, parfois roulette firmware

Les plateformes grand public AMD peuvent être étonnamment amicales pour VFIO. Beaucoup de cartes AM4 ont acquis la réputation de bons groupements IOMMU, en particulier quand les GPU et le NVMe principal sont attachés au CPU. AM5 poursuit la tendance, mais introduit de nouveaux firmwares et des comportements PCIe 5.0 plus complexes.

À privilégier :

• Cartes qui documentent clairement quels slots M.2 sont CPU vs chipset
• BIOS qui exposent IOMMU, SVM, Above 4G et la bifurcation par slot
• Moins de contrôleurs intégrés si vous valorisez des groupements propres

À éviter :

• Cartes avec des bridges PCIe « supplémentaires » pour gonfler le nombre de slots
• Firmware qui cache les réglages PCIe avancés derrière un « EZ mode forever »

Intel grand public (LGA1200/1700/1851-ish) : VT-d est mûr ; le fan-out du chipset peut être brouillon

Intel VT-d est mature. La douleur n’est généralement pas VT-d lui‑même ; c’est la façon dont la carte route les périphériques via le PCH et si le firmware expose un comportement ACS suffisant. Les cartes Intel grand public ont souvent beaucoup de périphériques chipset : Wi‑Fi, plusieurs M.2, plusieurs contrôleurs USB, parfois le support Thunderbolt.

À privilégier :

• Cartes avec de fortes options BIOS pour VT-d, Above 4G decoding et bifurcation
• Diagrammes de câblage des slots clairs dans le manuel

À éviter :

• Extensions Thunderbolt si vous n’en avez pas besoin (elles apportent des bridges supplémentaires et des considérations de sécurité)
• Cartes « gaming » avec des contrôleurs packagés derrière des bridges partagés

Plateformes workstation (Threadripper/WRX80, Xeon W) : ennuyeuses, coûteuses et généralement correctes

Si vous avez besoin de plusieurs périphériques en passthrough sans compromis — plusieurs GPU, plusieurs NICs, HBA et NVMe — les plateformes workstation sont le choix adulte. Vous achetez plus de lignes CPU, plus de ports racine et une plateforme qui attend l’existence de la virtualisation.

Ce que vous obtenez :

• Plus de slots PCIe attachés au CPU (moins de dépendance au fan-out du chipset)
• Meilleures chances d’avoir des groupes propres sans ACS override
• Souvent meilleur support pour SR-IOV et NICs d’entreprise

Ce que ça coûte :

• De l’argent, bien sûr
• Complexité de refroidissement et de puissance
• Parfois un rythme de nouveautés consommateur plus lent (la stabilité est la fonctionnalité)

Plateformes serveur : meilleure isolation, mais n’assumez pas « serveur » = « passthrough-friendly »

Les cartes serveur offrent souvent une excellente isolation, mais le public cible est généralement des périphériques PCIe gérés par l’hôte, pas passés à des VM desktop aléatoires. Vous pouvez faire face à :

• Des valeurs par défaut BIOS qui favorisent la gestion à distance et la stabilité plutôt que la commodité consommateur
• Des périphériques intégrés que vous ne pouvez pas facilement désactiver (BMC, bridges supplémentaires)
• Des étrangetés avec les GPU grand public (états d’alimentation, initialisation, absence de support d’option ROM)

Si vous faites du passthrough GPU sur une carte serveur, validez le modèle exact de GPU et le comportement de reset tôt.

Prise de parti : Si votre plan implique plus d’un GPU en passthrough et un NVMe en passthrough, arrêtez d’essayer de « gagner » avec un chipset grand public. Comparez le prix du matériel workstation. Vous l’achèterez de toute façon — soit maintenant, soit après avoir payé la « taxe debug ».

Faits intéressants et brève histoire (pour comprendre les bizarreries)

• Fait 1 : IOMMU chez AMD est commercialisé sous le nom AMD-Vi ; l’équivalent Intel est VT-d. Les deux résolvent le même problème central : contrôler le DMA des périphériques.
• Fait 2 : PCIe ACS n’a pas toujours été courant sur le matériel grand public ; les premiers adopteurs de VFIO s’appuyaient souvent sur des quirks de chipset et des contournements noyau.
• Fait 3 : Le framework VFIO de Linux a émergé comme une voie plus propre que les méthodes héritées, en mettant l’accent sur l’affectation des périphériques avec l’IOMMU comme frontière de sécurité.
• Fait 4 : « Above 4G decoding » est ancien dans le concept : il existe parce que les périphériques PCIe ont besoin d’espace d’adressage pour les BAR MMIO, et les GPU modernes peuvent en avoir besoin beaucoup.
• Fait 5 : Resizable BAR (une fonctionnalité PCIe) est devenue courante avec les GPU modernes ; elle change la quantité de VRAM mappée dans l’espace d’adressage CPU, ce qui peut affecter les setups de passthrough.
• Fait 6 : La bifurcation PCIe n’est pas garantie par la forme du slot ; c’est une fonctionnalité plateforme/firmware. Deux devices x8 dans un slot x16 sont une décision du BIOS.
• Fait 7 : Un « uplink chipset » (Intel DMI ou équivalent) est un tuyau partagé ; un NVMe rapide derrière le chipset peut le saturer et provoquer des lenteurs.
• Fait 8 : FLR (Function Level Reset) est une capacité PCIe qui rend les périphériques en passthrough plus robustes lors des redémarrages VM. Beaucoup de périphériques ne l’implémentent pas bien.
• Fait 9 : La composition d’un groupe IOMMU peut changer lorsque vous peuplez certains slots M.2 car la carte peut rerouter des lignes ou activer différents bridges.

Une idée paraphrasée que les opérationnels répètent parce qu’elle reste vraie : une mauvaise organisation battra une bonne personne à chaque fois — W. Edwards Deming (paraphrasé).

Prévol opérationnel piloté par commandes : 12+ tâches pratiques et comment décider à partir des sorties

Ces tâches supposent un hôte Linux (style Debian/Ubuntu/Proxmox). Elles sont conçues pour répondre rapidement à trois questions :

1. L’IOMMU est-il réellement activé ?
2. Quels sont les groupes IOMMU ?
3. Puis-je lier en toute sécurité le périphérique cible à vfio-pci sans casser l’hôte ?

Tâche 1 : Confirmer les flags de virtualisation du CPU

cr0x@server:~$ lscpu | egrep 'Virtualization|Vendor ID|Model name'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Core(TM) i9-13900K
Virtualization:                  VT-x

Ce que ça signifie : VT-x/AMD-V est la virtualisation CPU. C’est nécessaire mais pas suffisant pour le passthrough de périphériques.

Décision : Si la virtualisation manque, activez la virtualisation CPU dans le BIOS d’abord. Ne pensez même pas à l’IOMMU avant cela.

Tâche 2 : Confirmer le support IOMMU et s’il est activé au démarrage

cr0x@server:~$ dmesg | egrep -i 'iommu|dmar|amd-vi' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.210000] DMAR: Intel(R) Virtualization Technology for Directed I/O

Ce que ça signifie : « DMAR: IOMMU enabled » (Intel) ou « AMD-Vi: IOMMU enabled » (AMD) est le feu vert.

Décision : Si vous voyez « IOMMU disabled » ou rien de pertinent, activez VT-d/IOMMU dans le BIOS et définissez les paramètres du noyau.

Tâche 3 : Vérifier que la ligne de commande du noyau inclut les bons paramètres IOMMU

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

Ce que ça signifie : Sur Intel, intel_iommu=on. Sur AMD, typiquement amd_iommu=on. iommu=pt est souvent utilisé pour réduire l’overhead des périphériques hôtes (mode pass-through pour les périphériques non assignés).

Décision : Si c’est absent, ajoutez-le dans la configuration du chargeur de démarrage et redémarrez. Si vous déboguez des problèmes d’isolation, retirez temporairement quiet.

Tâche 4 : Énumérer les groupes IOMMU (la commande la plus utile)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}"; for d in "$g"/devices/*; do lspci -nn -s "${d##*/}"; done; echo; done | less
IOMMU Group 16
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]

IOMMU Group 17
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]

IOMMU Group 18
00:14.0 USB controller [0c03]: Intel Corporation USB 3.2 Controller [8086:7ae0]
00:14.2 RAM memory [0500]: Intel Corporation Shared SRAM [8086:7aa7]

Ce que ça signifie : Votre GPU est propre (seules ses propres fonctions). Le NVMe est seul. Le contrôleur USB est groupé avec une fonction du chipset (normal).

Décision : Passez en passthrough les périphériques qui sont seuls ou seulement groupés avec leurs propres fonctions. Si votre cible partage un groupe avec quelque chose dont l’hôte a besoin, arrêtez et redesign.

Tâche 5 : Mapper un slot physique à une adresse PCIe

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvme|ethernet'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a80a]
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533]

Ce que ça signifie : Les adresses PCI (domain:bus:slot.function) sont la façon d’identifier les périphériques pour le binding et le passthrough.

Décision : Notez les adresses des périphériques que vous comptez passer.

Tâche 6 : Confirmer quel pilote possède actuellement le périphérique

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070]
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 3901
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que ça signifie : L’hôte utilise actuellement le GPU via nvidia.

Décision : Si vous voulez le passthrough, l’hôte ne doit pas utiliser le périphérique. Prévoyez de le binder sur vfio-pci tôt dans le démarrage.

Tâche 7 : Identifier les vendor/device IDs pour le binding vfio-pci

cr0x@server:~$ lspci -nn -s 01:00.0 -s 01:00.1
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484]
01:00.1 Audio device [0403]: NVIDIA Corporation GA104 High Definition Audio Controller [10de:228b]

Ce que ça signifie : Vous lierez 10de:2484 et 10de:228b à vfio-pci.

Décision : Liez toujours toutes les fonctions du même groupe (par ex. GPU + audio) sauf raison précise contraire.

Tâche 8 : Vérifier que les modules VFIO sont disponibles et chargés

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          73728  1 vfio_pci
vfio_iommu_type1       40960  0
vfio                   24576  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             442368  0
kvm                  1306624  1 kvm_intel

Ce que ça signifie : Le noyau a VFIO chargé.

Décision : Si VFIO n’est pas présent, installez le bon noyau/modules ou activez-les dans votre distribution.

Tâche 9 : Simulation de binding avec driver_override (test runtime)

cr0x@server:~$ echo vfio-pci | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver_override
vfio-pci
cr0x@server:~$ echo 0000:01:00.0 | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver/unbind
0000:01:00.0
cr0x@server:~$ echo 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/vfio-pci/bind
0000:01:00.0

Ce que ça signifie : Vous pouvez binder le périphérique à vfio-pci à chaud. Si ça échoue, le périphérique peut être en cours d’utilisation ou bloqué par des contraintes de groupe.

Décision : Si le binding à chaud échoue, ne passez pas à « rendre ça permanent » tout de suite. Réglez la raison (console utilisant le GPU, framebuffer, audio, etc.).

Tâche 10 : Confirmer que le périphérique est désormais contrôlé par vfio-pci

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3070]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que ça signifie : Le pilote hôte n’est plus attaché ; vfio-pci contrôle le périphérique.

Décision : Vous pouvez maintenant configurer votre hyperviseur pour l’assigner à une VM.

Tâche 11 : Chercher des indices ACS/AER/PCIe dans les logs noyau quand les groupes semblent incorrects

cr0x@server:~$ dmesg | egrep -i 'ACS|AER|PCIe|Downstream|Upstream' | head -n 40
[    0.812345] pci 0000:00:1c.0: PCIe Downstream Port
[    0.812678] pci 0000:00:1c.0: ACS not supported
[    0.900123] pcieport 0000:00:1c.0: AER enabled with IRQ 122

Ce que ça signifie : Un port downstream ne supporte pas ACS ; cela peut forcer le groupement.

Décision : Si le périphérique que vous ciblez est derrière un bridge sans ACS, préférez le déplacer vers un slot attaché au CPU ou changez de carte/platforme. L’ACS override reste le dernier recours.

Tâche 12 : Déterminer si un périphérique supporte le reset (FLR) et son comportement

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'Capabilities: \[.*\] Express|FLR|Reset' -n
45:Capabilities: [68] Express (v2) Endpoint, MSI 00
92:	DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
130:	Capabilities: [100] Advanced Error Reporting
161:	Capabilities: [250] Latency Tolerance Reporting

Ce que ça signifie : Tous les périphériques n’annoncent pas FLR explicitement via un simple grep, et des quirks de reset GPU sont courants.

Décision : Si vous voyez un comportement répété « périphérique bloqué » au redémarrage d’une VM, vous pouvez avoir besoin de modules de reset fournisseur, d’un autre modèle de GPU ou d’un firmware/slot différent.

Tâche 13 : Vérifier la presence de BARs volumineuses / pression d’espace d’adressage (commun avec les GPU modernes)

cr0x@server:~$ dmesg | egrep -i 'BAR|resizable|MMIO|above 4g' | head -n 50
[    1.234567] pci 0000:01:00.0: BAR 0: assigned [mem 0x6000000000-0x600fffffff 64bit pref]
[    1.234890] pci 0000:01:00.0: BAR 2: assigned [mem 0x6010000000-0x6011ffffff 64bit pref]
[    1.235012] pci 0000:01:00.0: enabling device (0000 -> 0003)

Ce que ça signifie : Les mappings BAR larges nécessitent un support firmware approprié. Si l’assignation d’adresses échoue, le passthrough peut échouer ou des périphériques peuvent disparaître.

Décision : Si vous voyez des échecs d’allocation de BAR ou des périphériques qui ne s’énumèrent pas, activez Above 4G decoding ; envisagez de désactiver Resizable BAR temporairement pendant le débogage.

Tâche 14 : Vérifier quels périphériques sont derrière le chipset vs CPU (vue topologique)

cr0x@server:~$ sudo lspci -t
-[0000:00]-+-00.0  Intel Corporation Device 1234
           +-01.0-[01]----00.0  NVIDIA Corporation GA104 [GeForce RTX 3070]
           +-02.0-[02]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller
           +-14.0  Intel Corporation USB 3.2 Controller
           \-1c.0-[03]----00.0  Intel Corporation I210 Gigabit Network Connection

Ce que ça signifie : La vue en arbre vous aide à voir si un périphérique est accroché à un port racine/bridge particulier. Les périphériques derrière le même port downstream sont plus susceptibles de partager un groupe si ACS est faible.

Décision : Privilégiez les périphériques en passthrough qui apparaissent directement sous des ports racine distincts.

Tâche 15 : Vérifier que votre initramfs liera vfio tôt (empêcher l’hôte d’attraper les périphériques)

cr0x@server:~$ grep -R "vfio" /etc/modprobe.d /etc/modules /etc/initramfs-tools 2>/dev/null | head
/etc/modules:vfio
/etc/modules:vfio_iommu_type1
/etc/modules:vfio_pci
/etc/modprobe.d/vfio.conf:options vfio-pci ids=10de:2484,10de:228b disable_vga=1

Ce que ça signifie : La configuration existe pour binder des IDs à vfio-pci tôt.

Décision : Si c’est absent, ajoutez-le et reconstruisez l’initramfs pour que les pilotes graphiques/audio de l’hôte ne se lient pas en premier.

Tâche 16 : Rebuild initramfs et confirmer que ça s’est bien passé

cr0x@server:~$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-amd64

Ce que ça signifie : Votre environnement d’early boot inclut maintenant la config de binding VFIO.

Décision : Redémarrez et re-vérifiez les Tâches 6/10 pour vous assurer que vfio-pci possède le périphérique au démarrage.

Mode dʼemploi pour diagnostic rapide : quoi vérifier en premier/deuxième/troisième pour trouver le goulot rapidement

Premier : l’IOMMU est-il réellement activé et fonctionnel ?

• Vérifiez /proc/cmdline pour intel_iommu=on ou amd_iommu=on (Tâche 3).
• Vérifiez dmesg pour DMAR/AMD-Vi activé (Tâche 2).
• Si absent : bascules BIOS (VT-d/IOMMU, Above 4G) et paramètres noyau. Redémarrez.

Deuxième : les groupes IOMMU rendent-ils le passthrough possible ?

• Dump des groupes IOMMU (Tâche 4).
• Identifiez le groupe de votre périphérique cible et listez tout ce qu’il contient.
• Si le groupe contient des périphériques critiques de l’hôte (contrôleur USB nécessaire pour le clavier sur une machine headless, NVMe de boot, NIC primaire) : n’allez pas plus loin.

Troisième : le comportement de reset/binding du périphérique est-il stable ?

• Vérifiez la propriété du pilote (lspci -k) (Tâche 6/10).
• Essayez le bind/unbind à chaud (Tâche 9).
• Surveillez dmesg pendant le démarrage/arrêt de la VM pour des erreurs (Tâche 11/13).
• Si le redémarrage de la VM bloque le périphérique : vous avez un problème de reset, pas de groupement.

Quatrième : est-ce vraiment un problème IOMMU, ou un problème de bande passante/latence ?

• Utilisez lspci -t pour voir si vos périphériques « rapides » sont tous derrière l’uplink du chipset (Tâche 14).
• Si vous saturez le lien chipset, déplacez les périphériques haut I/O vers des lignes CPU ou acceptez la limite.

Erreurs courantes : symptômes → cause racine → correction

1) Symbole : votre GPU partage un groupe avec USB/SATA/NIC

Cause racine : Le GPU est derrière un port downstream sans ACS ou un bridge chipset qui ne peut pas isoler les périphériques ; parfois le slot est câblé au chipset.

Correction : Déplacez le GPU vers un slot câblé au CPU. Désactivez les contrôleurs intégrés inutilisés dans le BIOS si possible. Si le groupement persiste, changez de carte mère/plateforme. Utilisez ACS override seulement si vous acceptez une isolation plus faible.

2) Symbole : les groupes IOMMU semblent corrects, mais le démarrage de la VM échoue avec « device is in use »

Cause racine : Le pilote hôte a attrapé le périphérique tôt (framebuffer, audio, pilote GPU fournisseur).

Correction : Lie les IDs de périphérique à vfio-pci dans la conf modprobe et reconstruisez l’initramfs (Tâche 15/16). Assurez-vous que l’hôte n’utilise pas ce GPU pour la console.

3) Symbole : la VM boot une fois ; au second boot ça bloque ou le GPU disparaît jusqu’au reboot de l’hôte

Cause racine : Problèmes de reset/FLR ; courant avec certains GPUs et certains comportements de gestion d’alimentation PCIe de la carte mère.

Correction : Essayez un slot différent (un root port différent). Désactivez ASPM agressif dans le BIOS. Envisagez des modules de reset fournisseur quand applicables. Dans le pire des cas, choisissez un autre GPU connu pour se réinitialiser proprement.

4) Symbole : activer Above 4G decoding casse le démarrage ou masque des périphériques

Cause racine : Bug firmware ou réglages conflictuels (CSM, option ROM legacy, mapping PCIe étrange).

Correction : Désactivez CSM/boot legacy, utilisez UEFI. Mettez à jour le BIOS. Si ça échoue encore, la carte vous dit qui elle est — croyez-la.

5) Symbole : le passthrough NVMe fonctionne, mais les performances sont erratiques sous charge

Cause racine : NVMe attaché au chipset et contention sur l’uplink ; pas un problème de groupement IOMMU.

Correction : Déplacez le NVMe vers un M.2 attaché au CPU ou utilisez un slot PCIe attaché au CPU avec une carte porteuse (et bifurcation). Ou acceptez la limite d’uplink et ajustez vos attentes.

6) Symbole : SR-IOV « fonctionne » mais les VFs tombent dans des groupes étranges ou ne s’assignent pas

Cause racine : Contraintes firmware/driver du NIC, limites de mapping IOMMU, ou comportement ACS de la plateforme autour du PF/VFs.

Correction : Mettez à jour le firmware du NIC. Vérifiez IOMMU activé et le comportement iommu=pt. Privilégiez des cartes serveur/workstation et des NICs connus pour la stabilité SR-IOV.

Blague #2 : L’ACS override, c’est comme étiqueter votre tiroir à bazar « organisé ». Ça réduit peut-être le stress, mais ça ne change pas la physique.

Checklists / plan étape par étape

Étape 1 : Définissez ce que vous passez (soyez précis)

• Quels GPU(s) ? Inclure la fonction audio.
• Quels NVMe ? Boot vs passthrough.
• Quels NIC(s) ? Besoins SR-IOV ?
• Un contrôle USB en passthrough (pour VR, dongles, clés de licence) ?

Étape 2 : Choisissez une plateforme selon les besoins en lignes, pas selon le feeling

• Un GPU + un NVMe en passthrough : beaucoup de cartes grand public peuvent le faire.
• Deux GPU + plusieurs NVMe/NIC/HBA en passthrough : orientez-vous workstation (plus de lignes CPU, plus de ports racine).
• Conformité ou VMs non fiables : évitez l’ACS override comme stratégie.

Étape 3 : Checklist carte mère (avant achat)

• Le manuel montre le câblage des slots (CPU vs chipset) et les règles de partage de lignes.
• Le BIOS supporte : IOMMU/VT-d, Above 4G decoding, bifurcation par slot.
• Moins de contrôleurs tiers à moins d’en avoir réellement besoin.
• Rapports de groupes IOMMU propres sur des versions CPU/BIOS similaires (comme indice, pas preuve).
• Dispositif physique supporte le refroidissement quand vous remplissez plusieurs slots PCIe.

Étape 4 : Montez et validez sur banc (avant toute migration importante)

1. Installez l’OS hôte.
2. Activez les réglages BIOS (IOMMU/VT-d, 4G decoding, boot UEFI).
3. Démarrez et exécutez les Tâches 2–4 pour vérifier les groupes IOMMU.
4. Binder un périphérique non critique d’abord (une NIC de rechange ou un contrôleur USB) pour tester le flux VFIO.
5. Ensuite seulement, liez le GPU/NVMe qui vous intéresse.

Étape 5 : Verrouillez tout (rendez la procédure reproductible)

• Notez la version BIOS et les réglages (captures d’écran ou texte).
• Verrouillez la version du noyau si la stabilité prime sur la nouveauté.
• Gardez une entrée de démarrage connue et fonctionnelle dans votre chargeur de démarrage.
• Documentez les adresses PCI et les groupes IOMMU comme partie des notes de build de l’hôte.

Trois mini-histoires du monde de l’entreprise (ce qui tourne réellement mal)

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

Ils construisaient un petit cluster de virtualisation pour une chaîne graphique interne : quelques hôtes costauds, quelques GPU chacun, et une deadline déjà émotionnellement instable. Quelqu’un a choisi une carte mère basée sur des critiques disant « parfaite pour le gaming, plein de slots PCIe ». Elle avait, en fait, beaucoup de slots. Électriquement, elle avait moins d’ambitions.

Le premier hôte est arrivé et l’équipe a fait ce que tout le monde fait : activé VT-d/IOMMU, activé Above 4G decoding, installé l’hyperviseur, et essayé de passer les GPU. Un GPU paraissait correct. Le second GPU partageait un groupe IOMMU avec un contrôleur USB et un contrôleur SATA. Passer tout le groupe aurait emporté le disque de boot de l’hôte et son clavier distant.

Ils ont supposé qu’un tweak noyau réglerait ça. Ils ont activé ACS override. Ça « a marché » dans le sens où ils pouvaient assigner des GPU aux VMs. Puis une VM a planté sous charge et l’hôte a perdu un périphérique de stockage. Pas de corruption de données, heureusement — juste un passage en lecture seule laid et un reboot forcé en production. La cause racine n’était pas une VM malveillante ; c’était la plateforme qui manquait d’isolation réelle et le noyau qui était prié de faire semblant.

Le postmortem fut simple et douloureux : l’équipe avait supposé que le nombre de slots impliquait des ports racine indépendants et des frontières ACS. Ce n’est pas le cas. Les slots mécaniques x16 sont bon marché ; des frontières IOMMU propres coûtent plus cher.

Ils ont remplacé les cartes par des modèles workstation qui avaient moins de « fonctionnalités » et plus de lignes. Tout est devenu ennuyeux. Personne ne regrette le RGB.

Histoire 2 : L’optimisation qui a mal tourné

Une autre équipe gérait un cloud privé avec un mélange de nœuds compute et stockage. Ils voulaient maximiser la densité : plus de NVMe, plus de NICs, et garder un slot pour tests de passthrough GPU occasionnels. L’« optimisation » était d’utiliser une carte switch PCIe pour répartir les lignes et caser plus de périphériques dans moins de ports racine CPU.

Sur le papier, c’était élégant : un slot x16 devient quatre x4 NVMe plus un NIC ailleurs. En pratique, le switch PCIe a introduit un comportement de groupement qui les a surpris. Plusieurs endpoints se sont retrouvés dans le même groupe IOMMU parce que le port upstream n’exposait pas ACS comme Linux l’attendait. Les plans de passthrough se sont rapidement compliqués.

Ils ont essayé de tenir : passer des groupes entiers, déplacer des périphériques, basculer des réglages BIOS, et débattre de l’impact de performance de « iommu=pt » pour leur charge. Finalement, ils ont obtenu quelque chose qui fonctionnait — mais chaque update noyau est devenu un risque. L’ordre d’énumération a changé une fois, et une config VM qui supposait une adresse de périphérique a fini par cibler le mauvais NVMe. Ça a été repéré en staging, mais ça a été un avertissement sonore.

La correction a été presque ennuyeuse : ils ont cessé d’optimiser pour la densité de slots et ont optimisé pour l’isolation. Moins de switchs, plus de lignes CPU directes, et acceptation d’un encombrement hôte un peu plus grand. Le résultat business a été une meilleure disponibilité et moins de nuits blanches « pourquoi le groupe 27 a changé ? ».

Histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation liée à la finance exploitait un petit ensemble d’hyperviseurs hébergeant des desktops internes avec accélération GPU. Rien d’exposé à Internet, mais quand même sensible. Leur lead SRE avait une règle : chaque plateforme hardware passe un « test d’acceptation matérielle » avant d’être admise dans la flotte.

Le test n’était pas glamour. C’était un script qui dumpait les groupes IOMMU, capturait lspci -t, enregistrait les réglages BIOS, et validait que les périphériques cibles pouvaient se binder à vfio-pci sans ACS override. Ils exigeaient aussi un test de cycle VM complet : boot, charger le pilote, exécuter un court stress, redémarrer la VM, répéter. Si le GPU bloquait au redémarrage, ce modèle de GPU ou ce slot était disqualifié.

Un trimestre, un fournisseur a expédié une mise à jour du BIOS qui a changé le comportement PCIe. Le test d’acceptation a échoué sur un nouveau lot de machines : le second NVMe partageait désormais un groupe avec un contrôleur USB du chipset. Rien n’était « cassé » pour un usage desktop normal. Pour le passthrough, c’était inacceptable.

Comme ils avaient le test et l’exécutaient avant le déploiement en production, ils l’ont détecté tôt, ont bloqué la mise à jour BIOS et escaladé au fournisseur avec des preuves propres : cartes de groupes avant/après et topologie. La flotte est restée stable. Le changement a été corrigé dans un BIOS ultérieur. La partie la plus excitante de l’incident a été que personne n’a dû l’avoir.

Voilà le secret : des vérifications ennuyeuses préviennent des incidents excitants.

FAQ

1) Quel est un bon agencement de groupes IOMMU pour le passthrough GPU ?

Idéal : le GPU est seul avec sa fonction audio dans le même groupe. Acceptable : un GPU partage avec une fonction bridge en amont que vous pouvez aussi passer (rare et spécifique au cas). Mauvais : le GPU partage avec un USB/SATA/NIC dont l’hôte a besoin.

2) Une carte mère plus chère garantit-elle des groupes propres ?

Non. Le prix achète des fonctionnalités et parfois de la validation, mais ne garantit pas une topologie PCIe sensée. Les cartes workstation tendent à être meilleures parce qu’elles ont plus de lignes CPU et plus de ports racine, pas parce qu’elles ont de meilleurs dissipateurs.

3) L’ACS override est-il « dangereux » ?

Ça réduit les garanties d’isolation en faisant que le noyau traite des périphériques comme séparables même si le tissu ne peut pas l’appliquer. Dans des setups mono-utilisateur de confiance, cela peut être acceptable. Dans des environnements multi-tenant ou sensibles, considérez que c’est inacceptable.

4) Pourquoi mes groupes IOMMU changent-ils quand je peuple un slot M.2 ?

Parce que certaines cartes partagent des lignes entre les slots ou activent différents bridges selon la population. Ajouter un NVMe peut changer la construction de l’arbre PCIe, ce qui modifie le groupement.

5) Les périphériques connectés au chipset sont-ils toujours mauvais pour le passthrough ?

Pas toujours. Certains chipsets/cartes exposent un bon comportement ACS et produisent des groupes exploitables. Le risque majeur est la bande passante uplink partagée et la contamination de groupe par d’autres périphériques du chipset.

6) Ai-je besoin d’Above 4G decoding pour le passthrough ?

Souvent oui, surtout avec les GPU modernes (BARs larges) ou de nombreux périphériques PCIe. Sans cela, vous pouvez voir des périphériques qui ne s’énumèrent pas ou des erreurs d’allocation de BAR.

7) Puis-je passer uniquement le GPU et pas sa fonction audio ?

Vous pouvez essayer, mais il est généralement plus propre de passer toutes les fonctions du groupe. Séparer les fonctions peut créer des conflits de pilotes ou laisser des pilotes hôtes accéder au périphérique.

8) Pourquoi mon passthrough GPU fonctionne-t-il jusqu’au redémarrage de la VM ?

C’est typiquement un problème de reset (FLR non supporté ou cassé ; quirks de gestion d’alimentation). Essayez un slot différent, ajustez les réglages d’alimentation BIOS, ou choisissez du matériel connu pour se réinitialiser proprement.

9) Quelle est la façon la plus simple de « tester une carte mère » pour des groupes propres avant de s’engager ?

Bootez un environnement live Linux, activez IOMMU/VT-d et Above 4G dans le BIOS, puis exécutez le dump des groupes IOMMU (Tâche 4). Si votre périphérique cible est collé à des périphériques critiques de l’hôte, retournez la carte tant que vous le pouvez.

Étapes pratiques suivantes

1. Inventoriez vos périphériques de passthrough prévus et décidez lesquels doivent être attachés au CPU.
2. Présélectionnez des cartes qui documentent le câblage des lignes et exposent IOMMU + Above 4G + bifurcation dans le BIOS.
3. Testez sur banc la configuration exacte (y compris les slots M.2 peuplés) et capturez les groupes IOMMU.
4. Refusez les victoires fragiles : si vous avez besoin d’ACS override pour que le build fonctionne, acceptez explicitement le risque ou changez de matériel.
5. Rendez le processus reproductible : enregistrez la version et les réglages BIOS et conservez les sorties de commandes qui prouvent que l’hôte est correctement isolé.

Si vous voulez une règle simple qui tient sous pression : achetez pour la topologie, pas pour le marketing. Des groupes IOMMU propres ne sont pas une fonctionnalité que vous activez plus tard. C’est une propriété que vous payez dès l’achat.