Une mise à jour du noyau a cassé le passthrough ? Diagnostiquer rapidement l’IOMMU

Playbook de diagnostic rapide (faire cela en premier)

Si vous êtes de garde, vous n’avez pas besoin d’une philosophie IOMMU. Vous avez besoin d’un embranchement rapide dans la route : est-ce le BIOS, les paramètres du noyau, le binding du driver, le grouping ou le comportement de reset du périphérique ? Travaillez du haut vers le bas et arrêtez-vous quand vous trouvez une contradiction nette.

Première étape : confirmer que l’IOMMU est vraiment activé et actif

1. Vérifiez les paramètres de démarrage du noyau pour les flags IOMMU.
2. Consultez dmesg pour l’initialisation de l’IOMMU.
3. Confirmez que vous avez des groupes IOMMU sous /sys/kernel/iommu_groups.

Décision : Si l’IOMMU n’est pas actif, ne touchez pas encore à VFIO, libvirt, QEMU ou Proxmox. Corrigez d’abord le firmware et les arguments du noyau.

Deuxième étape : confirmer que le périphérique est lié à vfio-pci (et pas au driver hôte)

1. lspci -nnk pour « Kernel driver in use ».
2. Vérifiez que vfio-pci est chargé et que les IDs du périphérique correspondent.
3. Validez que l’initramfs inclut les modules VFIO si vous avez besoin d’un binding précoce.

Décision : Si votre GPU/HBA est toujours revendiqué par amdgpu/nvidia/nouveau/ahci/megaraid_sas, la VM perdra. Réparez le binding avant de toucher aux groupes.

Troisième étape : vérifier les groupes IOMMU et les régressions d’isolation

1. Listez les groupes et voyez ce qui a bougé.
2. Recherchez les symptômes de « group grew » : votre GPU partage maintenant avec un contrôleur USB ou un périphérique audio que vous ne pouvez pas passer proprement.
3. Vérifiez si le comportement ACS/ARI a changé avec la mise à jour du noyau.

Décision : Si le grouping est le problème, soit (a) vous déplacez les slots, (b) vous ajustez les paramètres PCIe du BIOS, (c) vous acceptez le risque d’ACS override, soit (d) vous changez de carte mère. Choisissez-en un; ne « overridez » pas simplement en production sans modèle de menace.

Quatrième étape : inspecter les fautes DMA/IOMMU et les problèmes de reset

1. Cherchez dans dmesg les fautes IOMMU et les erreurs DMAR/AMD-Vi.
2. Vérifiez les quirks FLR/reset (surtout pour les GPU).
3. Validez que votre config VM ne demande pas d’impossibilités (comme un mismatch multifunction).

Décision : Si c’est un quirk de reset, vous pourriez avoir besoin de paramètres du noyau, d’un GPU différent, ou d’arrêter de redémarrer la VM comme si c’était un serveur web.

Blague courte #1 : Un groupe IOMMU est comme un open-space : un voisin bruyant et soudainement personne ne travaille plus.

Ce qui a probablement changé après une mise à jour du noyau

Les mises à jour du noyau ne « cassent » pas le passthrough au hasard. Elles modifient la façon dont le noyau énumère les périphériques, applique les quirks, gère les fonctionnalités PCIe, et parfois comment il privilégie sécurité vs commodité. L’échec semble aléatoire parce que votre modèle mental est obsolète.

Déclencheurs courants de régression après mise à jour du noyau

• Différente énumération de topologie PCIe : un driver de bridge ou un quirk change et votre périphérique se retrouve derrière un port racine différent en comportement.
• Changements dans la gestion ACS/ARI : les groupes peuvent fusionner ou se séparer quand le noyau décide qu’un port aval ne peut pas être jugé isolé.
• Changements de comportement VFIO : vérifications plus strictes autour des interruptions non sécurisées, de la taille des BAR ou du reset des périphériques.
• Différences d’initramfs : après l’installation d’un noyau, votre initramfs peut ne plus inclure le binding précoce vfio-pci ; l’hôte prend le périphérique en premier.
• Interactions signature module / Secure Boot : un module hors-arbre ne se charge plus, laissant des drivers de repli aux commandes.
• Mises à jour firmware/BIOS associées : les mises à jour « tant qu’on y est » peuvent changer des réglages de virtualisation ou réinitialiser des options PCIe.

Deux règles pour rester sain d’esprit

Règle 1 : Traitez le passthrough comme une chaîne de responsabilité. Le firmware expose, le noyau énumère, l’IOMMU isole, VFIO prend en charge, l’hyperviseur assigne. Les pannes arrivent à un maillon, pas dans l’abstrait.

Règle 2 : N’essayez pas de corriger le grouping avant d’avoir prouvé le binding et l’activation de l’IOMMU. Sinon vous « corrigerez » la mauvaise couche et n’apprendrez rien.

Faits intéressants et courte histoire qui aident vraiment

Connaître un peu de contexte vous aide à prédire quels boutons comptent et lesquels sont du placebo.

1. « VT-d » d’Intel et « AMD-Vi » d’AMD sont des marques différentes pour la même idée centrale : le remappage DMA pour empêcher les périphériques d’écrire n’importe où en RAM.
2. L’IOMMU n’était pas à l’origine une commodité pour la virtualisation ; c’était pour la sécurité et la correction quand des périphériques DMA dans la mémoire.
3. VFIO a remplacé les approches plus anciennes (comme les chemins d’assignation KVM legacy) en s’appuyant sur l’IOMMU pour l’isolation et sur le noyau pour la médiation.
4. ACS (Access Control Services) est une fonctionnalité PCIe qui peut aider à faire respecter les frontières d’isolation ; l’absence d’ACS explique pourquoi les plateformes grand public ont souvent des groupes « collants ».
5. ARI (Alternative Routing-ID Interpretation) affecte la façon dont les fonctions sont adressées derrière un bridge ; les changements dans la gestion ARI peuvent modifier les groupements et le comportement multifunction.
6. Le remappage des interruptions MSI/MSI-X compte : le passthrough est plus sûr quand la plateforme supporte le remappage des interruptions ; certains noyaux deviennent plus stricts en son absence.
7. FLR (Function Level Reset) est optionnel sur les périphériques PCIe ; beaucoup de périphériques « supportent le reset » en marketing mais se comportent mal après des redémarrages répétés de VM.
8. Le passthrough GPU est devenu plus simple et plus difficile avec le temps : meilleures fonctions VFIO et QEMU, mais GPU plus complexes, états d’alimentation et interactions firmware.
9. L’ACS override existe parce que la réalité est salement compliquée, pas parce que c’est une bonne pratique ; il force le noyau à faire semblant que l’isolation existe où le hardware ne la garantit pas.

Tâches pratiques de diagnostic (commandes, sorties, décisions)

Voici les tâches que j’exécute en production quand le passthrough casse après une mise à jour du noyau. Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision suivante. Exécutez-les dans l’ordre si vous voulez de la vitesse ; piochez si vous savez déjà quelle couche a échoué.

Task 1: Confirm your running kernel and last boot context

cr0x@server:~$ uname -r
6.8.0-48-generic

Ce que cela signifie : Vous déboguez le noyau en cours d’exécution. Si vous avez juste mis à jour mais pas redémarré, vous pourriez chasser des fantômes.

Décision : Si la version du noyau ne correspond pas à la fenêtre de changement « cassée », redémarrez sur le noyau suspect et reproduisez. Ne faites pas d’archéologie dans le mauvais runtime.

Task 2: Check the kernel command line for IOMMU parameters

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

Ce que cela signifie : Vous avez demandé Intel IOMMU et le « mode passthrough » pour les périphériques hôtes (iommu=pt) ce qui peut réduire l’overhead pour les périphériques non assignés.

Décision : Si vous êtes sur AMD, intel_iommu=on est décoratif. Utilisez amd_iommu=on. Si aucun n’est présent, ajoutez le bon et regénérez la config du bootloader.

Task 3: Prove IOMMU actually initialized (Intel DMAR / AMD-Vi)

cr0x@server:~$ dmesg -T | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 20
[Tue Feb  4 10:18:11 2026] DMAR: IOMMU enabled
[Tue Feb  4 10:18:11 2026] DMAR: Host address width 46
[Tue Feb  4 10:18:11 2026] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[Tue Feb  4 10:18:11 2026] DMAR: Intel(R) Virtualization Technology for Directed I/O

Ce que cela signifie : Le noyau indique que l’IOMMU est activé et a trouvé des unités DMAR.

Décision : Si vous voyez « IOMMU disabled » ou rien du tout, arrêtez. Allez dans le BIOS/UEFI : activez VT-d/AMD-Vi, et désactivez « Above 4G decoding » seulement si vous avez une plateforme spécifiquement cassée (rare ; généralement vous voulez qu’il soit activé).

Task 4: Confirm IOMMU groups exist

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups | head
0
1
10
11
12

Ce que cela signifie : Le grouping IOMMU est actif. L’absence de groupes signifie généralement que l’IOMMU n’est pas activé ou que vous êtes dans un mode qui n’a pas créé les entrées sysfs.

Décision : Si ce chemin est vide ou absent, revisitez les Tasks 2–3 et les réglages firmware. Ne perdez pas de temps sur le binding VFIO pour l’instant.

Task 5: Inventory devices and current driver binding

cr0x@server:~$ lspci -nnk | sed -n '1,120p'
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f] (rev 0a)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Device [1462:3771]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

Ce que cela signifie : Le GPU est revendiqué par le driver NVIDIA de l’hôte, et sa fonction audio est revendiquée par snd_hda_intel. Le passthrough échouera ou sera instable si l’hôte possède le périphérique.

Décision : Si votre objectif est de passer le GPU, liez les deux fonctions (VGA + audio) à vfio-pci. Si vous n’en liez qu’une, vous obtiendrez souvent des erreurs étranges ou une VM qui bloque au démarrage.

Task 6: Identify the IOMMU group membership for the target device

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename "$g")"; ls -1 "$g/devices" | sed 's/^/  /'; done | sed -n '1,60p'
Group 1
  0000:00:01.0
Group 2
  0000:01:00.0
  0000:01:00.1
Group 3
  0000:00:14.0
  0000:00:14.2

Ce que cela signifie : Les fonctions GPU partagent le Group 2 ensemble (bien), mais vous devez vérifier s’il y a d’autres périphériques dans ce groupe (mal). Ici ce sont seulement les deux fonctions GPU.

Décision : Si votre GPU partage un groupe avec d’autres périphériques que vous ne pouvez pas passer (comme un contrôleur SATA contenant votre disque root), vous avez un problème d’isolation. Passez à la remédiation du grouping, pas à la config VFIO.

Task 7: Spot what changed by comparing groups before/after (if you have logs)

cr0x@server:~$ journalctl -b -1 -k | egrep -i 'DMAR|IOMMU|ACS|vfio' | tail -n 20
Jan 31 09:12:02 server kernel: DMAR: IOMMU enabled
Jan 31 09:12:03 server kernel: vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)

Ce que cela signifie : Le boot précédent montre que le binding VFIO a eu lieu (ou a été tenté). Si le boot actuel ne montre pas des lignes similaires, quelque chose a changé dans l’ordre de chargement de l’initramfs/module ou dans les IDs des périphériques.

Décision : Si le boot précédent avait VFIO et que l’actuel non, concentrez-vous sur l’initramfs et la config modprobe plutôt que sur le BIOS ou ACS.

Task 8: Verify VFIO modules are loaded

cr0x@server:~$ lsmod | egrep 'vfio|kvm' | head
vfio_pci               163840  0
vfio_pci_core           73728  1 vfio_pci
vfio_iommu_type1        45056  0
vfio                    65536  2 vfio_pci_core,vfio_iommu_type1
kvm_intel              430080  0
kvm                  1335296  1 kvm_intel

Ce que cela signifie : Les éléments core VFIO sont présents. Si vfio_iommu_type1 manque, VFIO ne peut pas mapper le DMA en toute sécurité et l’assignation du périphérique échouera.

Décision : Si des modules manquent, chargez-les et fixez la persistance. Pour Debian/Ubuntu, mettez-les dans /etc/modules ou assurez-vous que votre initramfs les inclut.

Task 9: Bind a device to vfio-pci (temporary, runtime)

cr0x@server:~$ sudo modprobe vfio-pci
cr0x@server:~$ echo 10de 1e87 | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id
10de 1e87
cr0x@server:~$ sudo lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Device [1462:3771]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que cela signifie : Le périphérique est maintenant lié à vfio-pci (runtime). Cela prouve que le binding fonctionne sans reboot.

Décision : Si cela échoue parce que le périphérique est « in use », vous devez arrêter le service hôte qui le possède (display manager, persistence daemon, audio). Pour les GPU, les hôtes sans affichage sont vos amis.

Task 10: Make VFIO binding persistent (modprobe config + initramfs)

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1
EOF
cr0x@server:~$ sudo tee -a /etc/modules >/dev/null <<'EOF'
vfio
vfio_pci
vfio_iommu_type1
vfio_pci_core
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0-48-generic

Ce que cela signifie : Vous avez demandé à vfio-pci de réclamer des IDs de périphériques spécifiques, et vous avez assuré la présence des modules tôt. disable_vga=1 peut aider avec certains problèmes d’arbitrage VGA sur certaines plateformes.

Décision : Si après reboot l’hôte s’approprie encore le GPU, vous devrez probablement blacklister les drivers GPU hôtes (nouveau/nvidia/amdgpu) ou retirer les consoles framebuffer. Soyez délibéré ; ne blacklistez pas à la légère les drivers de stockage/réseau sauf si vous aimez les interventions manuelles.

Task 11: Validate blacklist status for conflicting GPU drivers

cr0x@server:~$ grep -R "blacklist nouveau\|blacklist nvidia\|blacklist amdgpu" /etc/modprobe.d || true
/etc/modprobe.d/blacklist-nouveau.conf:blacklist nouveau
/etc/modprobe.d/blacklist-nouveau.conf:options nouveau modeset=0

Ce que cela signifie : Nouveau est blacklisté. Cela réduit une course commune où le driver ouvert se lie en premier.

Décision : Si le driver propriétaire se lie toujours tôt, assurez-vous que ses paquets ne sont pas installés ou que ses services ne démarrent pas. Pour un GPU dédié au passthrough, l’hôte doit agir comme s’il n’existait pas.

Task 12: Check whether interrupt remapping is available (safety and stability)

cr0x@server:~$ dmesg -T | egrep -i 'interrupt remap|IR:' | head
[Tue Feb  4 10:18:11 2026] DMAR-IR: Enabled IRQ remapping in x2apic mode

Ce que cela signifie : Le remappage IRQ est activé. Cela compte pour l’assignation sûre des périphériques et peut influencer si VFIO signale des « unsafe interrupts ».

Décision : Si vous n’avez pas de remappage d’interruption, vous pouvez quand même exécuter le passthrough, mais vous êtes en territoire « ça marche jusqu’à ce que ça casse ». En environnement corporate, traitez l’absence de remappage IRQ comme un risque de plateforme, pas une nuisance paramétrable.

Task 13: Detect ACS capability and whether the kernel trusts the topology

cr0x@server:~$ sudo lspci -s 00:01.0 -vv | egrep -i 'ACSCap|ACSctl|ARI|SR-IOV' -n
82:	ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+
84:	ACSctl: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+

Ce que cela signifie : Le port upstream annonce des fonctionnalités ACS. Cela augmente les chances d’obtenir des groupes propres sans override.

Décision : Si l’ACS est absent sur des bridges clés, acceptez que des « groupes parfaits » puissent être impossibles sur cette carte. Déplacez les périphériques vers d’autres slots/root ports avant d’envisager un ACS override.

Task 14: Check for IOMMU faults during VM start

cr0x@server:~$ dmesg -T | egrep -i 'fault|DMAR:.*fault|AMD-Vi:.*Event|vfio.*error' | tail -n 20
[Tue Feb  4 10:26:44 2026] DMAR: DRHD: handling fault status reg 2
[Tue Feb  4 10:26:44 2026] DMAR: [DMA Read NO_PASID] Request device [01:00.0] fault addr 0x7f3c0000 [fault reason 0x06] PTE Read access is not set

Ce que cela signifie : Le périphérique a tenté un DMA vers une adresse non mappée dans les tables de pages IOMMU. Cela peut être une mauvaise configuration du guest, un périphérique buggy pendant le reset, ou un problème de mapping côté hôte.

Décision : Si des fautes apparaissent dès le démarrage de la VM, suspectez l’état de reset/firmware du périphérique ou un passthrough incomplet (fonction compagnon manquante). Si les fautes apparaissent en charge, suspectez des bugs driver/firmware ou des modules noyau hors-arbre interagissant mal.

Task 15: Verify the device supports reset behavior you can live with

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'Capabilities: \[.*\] Express|FLR|PowerCtl|LnkCtl' -n | head -n 30
10:	Capabilities: [60] Express (v2) Endpoint, MSI 00
45:	DevCtl: CorrErr- NonFatalErr+ FatalErr+ UnsupReq+
72:	Capabilities: [100] Advanced Error Reporting

Ce que cela signifie : Vous voyez des capacités PCIe Express, mais vous ne verrez pas forcément des lignes FLR explicites ici ; le support FLR peut varier, et certains GPU se comportent mal même quand ils déclarent un reset possible.

Décision : Si votre problème est « la première VM boote, la seconde échoue », vous faites probablement face à des quirks de reset. La correction consiste souvent à : éviter les redémarrages fréquents de VM, faire un cold reboot de l’hôte entre les assignations, ou choisir du matériel avec de meilleures sémantiques de reset.

Task 16: Validate QEMU/KVM sees the IOMMU and VFIO devices

cr0x@server:~$ sudo virsh nodedev-list | egrep 'pci_0000_01_00_[01]' || true
pci_0000_01_00_0
pci_0000_01_00_1

Ce que cela signifie : Libvirt voit les périphériques PCI comme des node devices. C’est la vérification d’inventaire au niveau hyperviseur.

Décision : Si libvirt ne peut pas les voir, votre environnement udev/libvirt est cassé ou les permissions sont incorrectes. Ne continuez pas à changer les IDs VFIO si la couche de gestion ne peut pas énumérer.

Task 17: Confirm vfio device node permissions and group ownership

cr0x@server:~$ ls -l /dev/vfio
total 0
crw-rw---- 1 root kvm  10, 196 Feb  4 10:20 0
crw-rw---- 1 root kvm  10, 196 Feb  4 10:20 2
crw-rw---- 1 root kvm  10, 196 Feb  4 10:20 vfio

Ce que cela signifie : Les devices caractère des groupes VFIO existent, et sont typiquement possédés par root:kvm. Si votre libvirt/QEMU tourne non privilégié, l’appartenance aux groupes compte.

Décision : Si les permissions sont incorrectes, corrigez les groupes du compte service hyperviseur ou les règles udev. Ne faites pas chmod 666 et appelez ça « résolu ». Ce n’est pas de l’ingénierie ; c’est la reddition.

Task 18: Check Secure Boot/module signing trouble (common after updates)

cr0x@server:~$ dmesg -T | egrep -i 'Lockdown|Secure boot|module verification|taint' | tail -n 10
[Tue Feb  4 10:18:12 2026] Lockdown: Loading of unsigned modules is restricted; see man kernel_lockdown.7

Ce que cela signifie : Le noyau est en mode qui restreint le chargement de modules non signés. Si votre configuration dépend de modules hors-arbre (commun pour les drivers GPU vendor), ils peuvent ne pas se charger après une mise à jour.

Décision : Soit vous enregistrez des clés/signez les modules correctement, soit vous évitez la dépendance hors-arbre sur l’hôte pour un GPU en passthrough. Si l’hôte a besoin des drivers vendor, traitez Secure Boot comme une exigence de premier plan, pas une surprise.

Trois mini-récits d’entreprise (douleur, arrogance, victoire ennuyeuse)

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

Ils avaient un petit cluster de virtualisation utilisé pour accélérer les builds : quelques VMs avec passthrough GPU pour des tests de rendu. Ce n’était pas « critique », ce qui dans le langage corporate signifie que ça devient critique à 2h du matin quand les dirigeants veulent une démo.

Une mise à jour du noyau a été déployée dans le cadre du patching de routine. Après reboot, la moitié des VMs ne démarraient plus. L’opérateur de garde a vu le GPU toujours listé sur l’hôte avec le driver vendor chargé et a supposé : « c’est bon ; la VM peut encore l’attacher. » Cette hypothèse transforme un bug résolvable en un incident de quatre heures.

Le vrai problème était plus simple : le binding précoce a changé. L’initramfs mis à jour avait cessé d’inclure les modules vfio-pci à cause d’une dérive de config dans leur pipeline d’image. L’hôte a saisi les GPUs avant que VFIO n’ait jamais eu la chance. Ils ont perdu du temps à changer des réglages BIOS et à échanger des slots PCIe parce que les groupes « semblaient différents », alors qu’en réalité les groupes allaient bien—le binding était faux.

Une fois qu’ils ont réajouté les modules VFIO à l’initramfs et épinglé les IDs vfio-pci, tout est revenu. Le post-mortem n’a pas porté sur VFIO. Il portait sur « vérifier la couche que vous changez ». Le correctif a été intégré dans le build d’image comme une vérification explicite : échouer la construction si les modules vfio ne sont pas présents dans l’initramfs pour les hôtes GPU.

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

Une équipe plateforme voulait réduire l’overhead de virtualisation. Ils ont poussé iommu=pt partout parce qu’ils l’avaient vu recommandé pour la performance. C’est un réglage valide dans le bon contexte. Ils l’ont déployé massivement sans comprendre les compromis.

Après une mise à jour du noyau, un SKU matériel a commencé à lancer des fautes DMA intermittentes sous une charge très spécifique : I/O élevée plus création/destruction rapide de VMs. Les logs de fautes pointaient vers des accès DMA du périphérique qui n’étaient pas mappés comme attendu. Leur réaction instinctive a été de blâmer le noyau.

Le vrai mode de défaillance était plus laid : la combinaison de « passthrough mode pour les périphériques hôtes » et d’un quirk de plateforme autour d’ATS/PRI (address translation services / page request interface) créait un comportement sensible au timing pendant les opérations d’attachement/détachement rapide. Sur les vieux noyaux, un quirk le masquait. Sur le nouveau noyau, ce quirk a changé. L’« optimisation » a mis à nu un problème de correction.

Ils ont retiré le flag de performance pour ce SKU, puis l’ont réintroduit uniquement après avoir validé l’ensemble des fonctionnalités PCIe et le comportement des périphériques sur leur flotte. La leçon : les flags de performance ne sont pas des décorations. Traitez-les comme des changements de code. Placez-les derrière des tests, pas des ressentis.

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

Une équipe stockage exploitait une petite flotte d’hyperviseurs faisant du passthrough HBA vers des VMs fournissant des services de stockage. Ils étaient conservateurs au point d’être ennuyeux : chaque mise à jour du noyau nécessitait un reboot dry-run sur un hôte canari, et ils capturaient toujours un « snapshot santé passthrough » avant de toucher quoi que ce soit.

Le snapshot était ennuyeux : version du noyau, /proc/cmdline, statut IOMMU depuis dmesg, liste complète des groupes IOMMU, et sortie lspci -nnk pour les HBAs. Puis ils stockaient ça avec la demande de changement. Personne n’aimait ce processus. Ce n’était pas glamour. Ça fonctionnait.

Une mise à jour a modifié le grouping IOMMU sur une révision spécifique de carte mère. Le reboot canari a immédiatement montré que le groupe HBA contenait maintenant un root port partagé avec une NIC. Cela aurait bloqué une assignation sûre et forcé un ACS override risqué. Ils ont arrêté le rollout, redirigé les workloads et ajusté le placement des slots sur ce modèle.

Il n’y a pas eu d’incident. Juste un ticket ennuyeux avec « déploiement en pause » et un court plan. C’est le genre d’ennui qui préserve vos weekends.

Erreurs courantes : symptôme → cause racine → correctif

Cette section est volontairement directe. Voici les principaux modes de défaillance après les mises à jour du noyau, cartographiés aux corrections qui referment réellement la boucle.

1) La VM ne démarre pas : « vfio: failed to setup container » ou « No such device »

Symptôme : Le démarrage de la VM échoue immédiatement ; les logs mentionnent VFIO container ou erreurs de mapping IOMMU type1.

Cause racine : IOMMU non activé dans le firmware/noyau, ou vfio_iommu_type1 manquant.

Fix : Activez VT-d/AMD-Vi dans le BIOS ; ajoutez les bons args noyau ; chargez les modules VFIO ; reconstruisez l’initramfs.

2) Le périphérique apparaît, mais le driver hôte se lie encore après reboot

Symptôme : lspci -nnk montre nvidia/amdgpu/snd_hda_intel toujours « in use ».

Cause racine : Le binding VFIO ne se produit pas assez tôt ; l’initramfs manque vfio-pci ; des drivers conflictent et se chargent avant.

Fix : Utilisez options vfio-pci ids=... et assurez-vous que les modules VFIO sont dans l’initramfs ; blacklistez les drivers conflictuels quand c’est approprié ; tenez l’hôte loin de la console GPU.

3) Les groupes IOMMU ont empiré après la mise à jour (périphériques fusionnés)

Symptôme : GPU/HBA partage un groupe avec un contrôleur USB, un contrôleur SATA ou un autre périphérique critique.

Cause racine : Le noyau a changé la confiance ACS/quirks ; des toggles BIOS ont modifié le routage PCIe ; la carte manque d’ACS sur les bridges.

Fix : Déplacez le périphérique vers un autre slot/root port ; activez ACS/ARI dans le BIOS si disponible ; évitez l’ACS override sauf si vous acceptez le risque d’isolation.

4) Le premier démarrage de VM fonctionne ; le second échoue ou le périphérique disparaît

Symptôme : La VM démarre une fois après reboot hôte ; les démarrages suivants bloquent ou le périphérique ne se rattache pas.

Cause racine : Quirks de reset du périphérique (GPU FLR, comportement D3cold), ou le driver du guest laisse le périphérique dans un mauvais état.

Fix : Préférez du hardware connu pour reset proprement ; faites un reboot complet de l’hôte entre les assignations si nécessaire ; ajustez l’arrêt du guest ; évitez les « boucles de redémarrage rapides ».

5) Fautes IOMMU aléatoires en charge

Symptôme : dmesg montre des fautes DMA quand le guest est sollicité ; perf chute ou la VM plante.

Cause racine : Firmware de plateforme instable, firmware/driver du périphérique buggy, ou situation de remappage d’interruptions non sécurisée.

Fix : Validez le remappage des IRQ ; mettez à jour le firmware de la carte mère ; testez avec un noyau différent ; retirez les flags de performance jusqu’à preuve de stabilité.

6) « ACS override l’a résolu » puis des choses bizarres se produisent plus tard

Symptôme : Vous avez forcé la séparation des groupes ; la VM démarre ; plus tard vous voyez des erreurs de bus étranges, des fautes DMA ou des inquiétudes de sécurité.

Cause racine : L’ACS override fait semblant d’isoler ; les périphériques peuvent toujours faire du DMA de façons que le hardware n’isole pas correctement.

Fix : Traitez l’ACS override comme dernier recours ; pour des environnements multi-tenant ou sensibles, ne l’utilisez pas. Corrigez la topologie matérielle à la place.

Blague courte #2 : L’ACS override, c’est comme mettre du ruban adhésif sur un disjoncteur—ça calme les choses jusqu’au jour où ça ne le fait plus.

Checklists / plan étape par étape

Checklist A : Le plan « je veux que ça remonte en 30 minutes »

1. Capturer les preuves : sauvegardez uname -r, /proc/cmdline, les lignes IOMMU de dmesg, lspci -nnk pour les périphériques ciblés, et la liste des groupes.
2. Prouver que l’IOMMU est actif : si pas de lignes DMAR/AMD-Vi, corrigez d’abord BIOS/args noyau.
3. Prouver le binding : le périphérique doit être vfio-pci dans lspci -nnk.
4. Prouver les groupes : le groupe du périphérique ciblé ne doit pas inclure de périphériques critiques non passables.
5. Tenter un démarrage de VM une fois : collectez les erreurs. Ne relancez pas en boucle ; cela masque les problèmes de reset.
6. Si vous suspectez un quirk de reset : faites un reboot propre de l’hôte, démarrez la VM une fois, puis évitez les redémarrages fréquents jusqu’à un fix permanent.

Checklist B : Le plan « rendre ça fixe »

1. Épingler les args noyau dans la config du bootloader et les documenter (Intel vs AMD compte).
2. Rendre le binding VFIO persistant via /etc/modprobe.d/vfio.conf et rebuild initramfs.
3. Blacklister les drivers conflictuels seulement quand vous êtes sûr que l’hôte n’en a pas besoin.
4. Enregistrer les groupes IOMMU de base et comparer après mises à jour sur un hôte canari.
5. Valider le remappage IRQ et traiter son absence comme un risque de plateforme.
6. Décider d’une politique ACS override (autorisé où ? jamais sur hôtes partagés ? seulement en labo ?). Écrivez-la.
7. Tester le comportement cold/warm reboot pour chaque classe de périphérique passthrough (GPU, HBA, NIC). Certains périphériques mentent sur la qualité de leur reset.
8. Automatiser les vérifications pour que la prochaine mise à jour ne devienne pas une chasse au trésor.

Checklist C : Snapshot minimal « santé passthrough » à stocker

• Version du noyau : uname -r
• Args de boot : cat /proc/cmdline
• Lignes d’activation IOMMU : dmesg -T | egrep -i 'DMAR|AMD-Vi|IOMMU' | head
• Liste des groupes : énumérer /sys/kernel/iommu_groups
• Binding des drivers : lspci -nnk filtré sur les périphériques assignés
• Vue hyperviseur : virsh nodedev-list ou l’équivalent de votre plateforme

Une idée de fiabilité à voler

Idée paraphrasée (de Werner Vogels, CTO Amazon) : « Vous l’avez construit, vous l’exploitez. » L’équipe qui publie le changement doit assumer l’issue opérationnelle.

Le passthrough n’est pas un « problème matériel » ou « problème noyau » que vous jetez par-dessus un mur. Si vous l’exploitez, vous devez avoir une checklist de régression et une voie de rollback.

FAQ

1) Mes groupes IOMMU ont changé après une mise à jour du noyau. Est-ce normal ?

Ce n’est pas rare. Le grouping est dérivé de la topologie PCIe plus de ce que le noyau croit concernant les fonctionnalités d’isolation (ACS/ARI/quirks). Si un noyau change la confiance qu’il accorde à un bridge, les groupes peuvent fusionner ou se séparer. Traitez-le comme une régression à trier, pas comme un « système hanté ».

2) Dois-je utiliser acs_override=downstream,multifunction pour corriger le grouping ?

Seulement si vous comprenez le compromis sécurité/correction. L’ACS override force le noyau à présumer que l’isolation existe. En labo, c’est peut-être acceptable. En environnement partagé ou sensible, évitez-le et corrigez la topologie (slots, plateforme, carte mère différente).

3) Quelle est la façon la plus rapide de dire si le passthrough échoue à cause du binding ?

lspci -nnk. Si « Kernel driver in use » n’est pas vfio-pci pour le périphérique que vous voulez passer (et ses fonctions compagnons), vous n’avez pas encore de passthrough. Tout le reste est secondaire.

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

Parce que c’est une fonction PCI distincte sur le même périphérique. La laisser sur l’hôte peut empêcher un reset propre, embrouiller le guest, ou déclencher des conflits de groupe/possession. Traitez GPU + audio GPU comme une paire sauf si vous avez une raison spécifique et la preuve qu’il est sûr de séparer.

5) Ma VM ne fonctionne que après un reboot complet de l’hôte. Que se passe-t-il ?

Comportement de reset. Certains périphériques ne se réinitialisent pas proprement quand ils sont détachés d’un guest, surtout les GPU grand public. Le périphérique se retrouve dans un état que le démarrage suivant de la VM ne peut pas récupérer. Les solutions incluent : éviter les redémarrages fréquents de VM, utiliser du hardware différent, ou accepter des reboots hôtes entre usages.

6) iommu=pt aide ou nuit ?

Ça peut aider la performance pour les périphériques possédés par l’hôte en réduisant la surcharge de traduction, mais ce n’est pas gratuit. Si vous rencontrez des quirks de plateforme ou des comportements périphériques complexes, retirez-le pendant le dépannage. Prouvez la correction d’abord, optimisez ensuite.

7) Comment Secure Boot et les mises à jour du noyau affectent-ils le passthrough ?

Si vous dépendez de modules hors-arbre (commun avec les drivers GPU vendor), Secure Boot peut les bloquer après une mise à jour à moins qu’ils ne soient signés/enregistrés correctement. Cela change le binding des drivers et peut casser votre configuration indirectement. Vérifiez dmesg pour les messages lockdown et verification des modules.

8) Je vois des fautes IOMMU dans dmesg. Est-ce toujours fatal ?

Pas toujours, mais ce n’est jamais « normal ». Les fautes signifient qu’un périphérique a tenté un DMA hors des mappings permis. Si c’est lié à votre périphérique passthrough, traitez cela comme un signal sérieux : passthrough incomplet, quirks de reset, drivers buggy ou instabilité de plateforme.

9) Puis-je hot-pluguer des périphériques passthrough en toute sécurité ?

Parfois, mais n’en faites pas une hypothèse. Le hot-plug ajoute de la complexité : états d’alimentation, sémantiques de reset et courses d’énumération. Pour la fiabilité en production, préférez l’assignation statique avec du hardware bien testé.

10) Que dois-je snapshotter avant les mises à jour du noyau sur des hôtes passthrough ?

Version du noyau, args de boot, lignes d’activation IOMMU, inventaire des groupes IOMMU, et binding des drivers pour les périphériques assignés. Si vous ne pouvez pas comparer « avant » et « après », vous devinerez, et deviner coûte cher.

Conclusion : prochaines étapes durables

Quand une mise à jour du noyau casse le passthrough, la meilleure stratégie est de refuser de faire de la panique. Vérifiez l’activation de l’IOMMU, puis le binding VFIO, puis les groupes, puis les fautes/quirks de reset. Cet ordre vous empêche de « réparer » trois choses non liées et de n’apprendre rien.

Faites ensuite :

1. Créez un script « snapshot santé passthrough » en une commande et stockez sa sortie avant et après les mises à jour.
2. Rebootez canari un hôte par SKU matériel avant de déployer les patches sur toute la flotte.
3. Rédigez une politique sur l’ACS override et respectez-la.
4. Pour les périphériques au mauvais comportement de reset, changez le mode opérationnel (moins de redémarrages, reboots à froid) ou changez de matériel. Les actions héroïques ne sont pas une stratégie.

Si vous ne faites rien d’autre : la prochaine fois que ça casse, ne commencez pas par la config de la VM. Commencez par dmesg, /proc/cmdline et lspci -nnk. La machine vous dit déjà la vérité. Votre travail est d’écouter dans le bon ordre.