Pourquoi le passthrough GPU affiche un écran noir après le redémarrage (c’est souvent l’IOMMU)
février 10, 2026 • février 10, 2026 • Lecture : 26 min • Views: 0
Cet article vous a aidé ?
Ça fonctionnait. La VM démarrait, le pilote invité s’installait, vous avez même lancé un benchmark comme un adulte responsable.
Puis vous avez redémarré l’hôte et—écran noir. Pas de sortie. Peut-être que la VM « tourne » mais vous ne voyez rien.
Peut-être que l’hôte boote normalement mais que le GPU est mort pour l’invité. Bienvenue dans le passthrough GPU : où le succès d’hier n’est pas un contrat.
Quand cela survient après un redémarrage, la panne n’est souvent pas « la carte » en tant que telle. C’est presque toujours
l’une de trois choses : l’isolation IOMMU a changé, le mauvais pilote a pris le périphérique en premier, ou le périphérique ne s’est pas réinitialisé proprement.
L’astuce est d’arrêter de deviner et de commencer à collecter des preuves qui survivent au redémarrage.
Plan de diagnostic rapide
Si vous êtes d’astreinte ou juste fatigué, suivez cet ordre. Il est optimisé pour le temps jusqu’à la première vérité, pas pour l’élégance.
Faites ces vérifications sur l’hôte en premier ; votre invité ne peut pas vous dire la vérité s’il n’a jamais véritablement possédé le GPU.
1) Confirmer que le périphérique est toujours le même périphérique
Vérifiez que l’adresse PCI et les ID du périphérique n’ont pas changé (rare, mais ça arrive après des mises à jour du BIOS ou des changements de slot).
Confirmez que le GPU et sa fonction audio sont tous deux présents.
2) Confirmer que VFIO a effectivement lié le GPU au démarrage
Si le pilote du noyau hôte (nouveau, nvidia, amdgpu) se lie en premier, VFIO « perd » et votre VM obtient un fantôme.
Les problèmes de liaison sont courants après des mises à jour du noyau et des changements d’initramfs.
3) Confirmer que les groupes IOMMU restent isolés
Si votre GPU partage un groupe IOMMU avec quelque chose dont l’hôte a besoin, vous refuserez soit de démarrer soit vous démarrerez et aurez un écran noir.
L’appartenance aux groupes peut changer suite à des bascules du BIOS, des mises à jour du firmware, ou à des paramètres du noyau différents.
4) Vérifier les problèmes de réinitialisation / FLR
Si ça marche une fois mais échoue après un redémarrage ou après l’arrêt/démarrage de la VM, vous avez probablement une bizarrerie de réinitialisation.
Ces cas se manifestent par « la VM démarre, pas d’affichage » ou « le pilote invité se charge puis le périphérique disparaît ».
5) Confirmer que le chemin d’affichage ne vous trompe pas
Mauvaise entrée du moniteur, handshake DP bizarre, ou interrupteur KVM peuvent ressembler à une défaillance VFIO.
Testez via une sortie différente (HDMI vs DP) ou utilisez un faux adaptateur connu bon (dummy plug).
Blague #1 : le passthrough GPU est le seul endroit où « ça marchait hier » est considéré comme un modèle de menace.
Ce que signifie réellement « écran noir » en passthrough
« Écran noir » est un symptôme, pas un diagnostic. En VFIO GPU passthrough cela signifie typiquement une des situations suivantes :
L’invité n’a jamais obtenu le GPU : le pilote hôte l’a lié, ou QEMU n’a pas pu l’assigner à cause de conflits de groupes IOMMU.
L’invité a obtenu le GPU, mais il n’a jamais initialisé la sortie : option ROM manquante, mauvais mode de firmware (UEFI vs legacy), ou état de réinitialisation incorrect.
L’invité a initialisé, mais vous regardez la mauvaise sortie : confusion multi-écrans ou multi-sorties ; le GPU rend sur un autre port.
Le GPU est dans un état verrouillé : problème connu sur certains GPU grand public sans Function Level Reset (FLR) fiable.
Un modèle mental utile : le passthrough est une chaîne de garde. Le périphérique PCIe est « possédé » par quelque chose à tout moment :
firmware, pilote hôte, VFIO, QEMU, pilote invité. Les écrans noirs surviennent souvent quand la propriété change
mais que l’état ne se réinitialise pas proprement — ou que le mauvais propriétaire le saisit en premier.
Pourquoi l’IOMMU est généralement en cause
L’IOMMU (Intel VT-d / AMD-Vi) est le videur du club mémoire. Il restreint le DMA pour que les périphériques ne puissent pas lire ou écrire
de la RAM au hasard. Pour le passthrough, c’est non négociable : votre GPU invité doit faire du DMA uniquement dans la mémoire assignée à l’invité,
pas dans le cache de l’hôte ou les secrets de l’hyperviseur.
Ce qui vous mord après un redémarrage, c’est que la topologie IOMMU n’est pas juste « activée/désactivée ». Elle est façonnée par :
paramètres du BIOS, topologie PCIe, paramètres du noyau, capacités ACS, et parfois la créativité du fabricant de carte mère.
Cela signifie que vous pouvez avoir une configuration fonctionnelle qui devient silencieusement non isolée après un redémarrage,
une mise à jour du firmware, ou même un ordre de démarrage différent des périphériques.
Groupes IOMMU : la véritable unité d’isolation
VFIO remet des groupes IOMMU entiers aux invités, pas des périphériques uniques arbitraires (avec quelques nuances, mais traitez-le comme « le groupe »).
Si votre GPU est dans un groupe avec, par exemple, un contrôleur SATA ou un contrôleur USB dont l’hôte a besoin, vous avez un conflit :
soit vous passez trop de choses et vous perdez des fonctionnalités hôte, soit vous ne pouvez pas isoler le GPU en toute sécurité.
Après un redémarrage, l’appartenance aux groupes peut changer parce que le firmware a réénumé le bus PCIe différemment,
ou parce qu’un réglage BIOS a modifié le comportement ACS. Parfois une mise à jour « inoffensive » du BIOS décide que le port racine du chipset
doit se comporter différemment, et maintenant votre GPU est collé à la moitié de la machine.
ACS override : tentant, parfois nécessaire, toujours un compromis
Le paramètre noyau ACS override peut séparer des groupes que le matériel n’isole pas correctement.
Cela peut rendre le passthrough possible sur des plateformes grand public, et cela peut aussi créer un faux sentiment de sécurité :
vous dites au noyau de supposer une isolation qui peut ne pas exister électriquement.
Dans des environnements de production, je traite l’ACS override comme du ruban adhésif sur une durite de frein. Vous pourriez rentrer chez vous.
Ne bâtissez pas une flotte autour de ça.
Remappage des interruptions et pourquoi « IOMMU activé » ne suffit pas
Certaines plateformes ont besoin du remappage des interruptions pour un passthrough sûr. Sans cela, vous pouvez voir des échecs bizarres :
des périphériques qui semblent assignés mais agissent comme morts, des invités qui plantent lors de l’initialisation du pilote, ou des schémas « marche jusqu’au redémarrage ».
C’est là que « j’ai activé VT-d » devient un conte de fées. Vous devez vérifier que le noyau a réellement activé les fonctionnalités.
Faits intéressants et contexte historique
VFIO a remplacé les anciennes approches d’assignation de périphériques KVM en déplaçant l’accès aux périphériques dans un cadre plus sûr piloté par l’IOMMU plutôt que des mappages ad hoc.
L’IOMMU existe principalement pour l’isolation DMA ; la virtualisation l’a rendu célèbre, mais le problème de sécurité (les périphériques comme attaquants DMA) précède le boom des homelabs d’aujourd’hui.
PCIe ACS n’a pas été « conçu pour les joueurs » ; c’est une fonctionnalité serveur pour l’isolation et le contrôle de routage, et les chipsets grand public l’implémentent souvent partiellement ou pas du tout.
Beaucoup de GPU exposent plusieurs fonctions PCI (graphique + audio HDMI + parfois USB-C/VirtualLink). Vous devez souvent passer toutes les fonctions liées pour la stabilité.
Function Level Reset (FLR) n’est pas universel ; certains GPU grand public manquaient historiquement d’un comportement de réinitialisation fiable, causant des échecs de passthrough « marche une fois ».
UEFI GOP vs ROM VGA legacy importe : les GPU modernes préfèrent l’initialisation UEFI ; les chemins legacy CSM peuvent se comporter différemment selon les redémarrages et versions de firmware.
Resizable BAR a changé les attentes de taille de ressources PCIe ; l’activer/désactiver peut affecter comment les périphériques mappent la mémoire, et parfois comment le firmware énumère les périphériques.
L’arbitrage VGA précoce existe toujours : le concept de « GPU principal » influence quel firmware initialise en premier, ce qui affecte la liaison du pilote hôte et le passthrough.
Tâches pratiques : commandes, sorties, ce que ça signifie, quoi faire ensuite
Ci-dessous des tâches de terrain que vous pouvez lancer maintenant sur un hôte Linux KVM (y compris les hôtes de type Proxmox).
Chacune inclut : une commande, une sortie réaliste, ce que la sortie signifie, et la décision à prendre. Ne procédez pas par sélection. Exécutez les premières même si vous êtes « sûr » que c’est autre chose.
Task 1: Confirm IOMMU is actually enabled in the kernel
Signification : Vous demandez l’IOMMU Intel, le mode pass-through pour les périphériques non-passthrough (iommu=pt), et la pré-liaison VFIO à des IDs PCI spécifiques.
Décision : Si les paramètres manquent après le redémarrage, vous avez modifié la mauvaise entrée du chargeur de démarrage ou n’avez pas régénéré la configuration de démarrage. Corrigez le chargeur, puis reconstruisez l’initramfs si nécessaire.
Task 3: Identify the GPU and its functions (graphics + audio)
Signification : Votre GPU est à 01:00.0 et la fonction audio HDMI est 01:00.1. Elles doivent généralement être passées ensemble.
Décision : Si la fonction audio manque après le redémarrage, suspectez des changements d’énumération PCIe, un riser défectueux, ou un réglage BIOS « économie d’énergie PCIe » qui dysfonctionne.
Task 4: See what driver currently owns the GPU (the custody chain check)
Signification : Bon : Kernel driver in use: vfio-pci. L’hôte ne l’utilise pas activement.
Décision : Si vous voyez nouveau, nvidia ou amdgpu comme « in use », votre passthrough sera instable ou mort. Corrigez la liaison des pilotes avant de déboguer les groupes IOMMU.
Task 5: Verify IOMMU group membership (the isolation truth)
cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do g=$(basename $(dirname $d)); printf "Group %s: " "$g"; lspci -nns ${d##*/}; done | egrep '01:00'
Group 16: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
Group 16: 01:00.1 Audio device [0403]: NVIDIA Corporation GP104 High Definition Audio Controller [10de:10f0] (rev a1)
Signification : Idéal : les fonctions GPU sont seules ensemble dans un groupe.
Décision : Si le groupe inclut d’autres périphériques (contrôleur USB, SATA, NIC), décidez : déplacez le GPU dans un autre slot, changez les paramètres PCIe du BIOS, ou acceptez le risque d’ACS override.
Task 6: Detect ACS override being used (and admit the risk)
cr0x@server:~$ dmesg | egrep -i 'ACS|override' | head
[ 1.245678] PCI: Using ACS override for IOMMU isolation
Signification : Le noyau falsifie/divise l’isolation.
Décision : Dans un homelab, c’est peut-être acceptable. Dans un environnement avec de véritables modèles de menace, traitez cela comme une mesure temporaire le temps d’améliorer la topologie matérielle.
Task 7: Confirm VFIO modules loaded and not silently missing after an update
Décision : Si les modules ne sont pas chargés, vérifiez l’initramfs et les blacklists de modules. Les mises à jour du noyau peuvent réinitialiser votre configuration de façons ennuyeuses.
Signification : Vous configurez la liaison VFIO précoce via des options modprobe et vous assurez que les modules se chargent.
Décision : Si cela semble correct mais que le pilote hôte se lie encore en premier, régénérez l’initramfs et redémarrez. La liaison précoce fait la différence entre « stable » et « exaspérant ».
Task 9: Confirm the GPU is not the boot/console framebuffer device
cr0x@server:~$ dmesg | egrep -i 'fb0|framebuffer|efifb|vesafb' | head -n 20
[ 0.401234] efifb: probing for efifb
[ 0.401567] efifb: framebuffer at 0xc0000000, using 3072k, total 3072k
[ 0.401890] fb0: EFI VGA frame buffer device
Signification : L’hôte utilise le framebuffer EFI, qui peut ou non être sur votre GPU passthrough.
Décision : Si le GPU passthrough est le périphérique d’affichage principal, vous lutterez contre le firmware et la liaison du framebuffer de la console. Préférez un iGPU ou un GPU secondaire bon marché pour l’hôte.
Task 10: Look for “GPU fell off the bus” / AER / link errors after reboot
cr0x@server:~$ journalctl -b -k | egrep -i 'AER|pcie|fallen off|vfio|DMAR|amdgpu|nvidia' | tail -n 30
Feb 04 09:11:21 server kernel: vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
Feb 04 09:11:22 server kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Feb 04 09:11:22 server kernel: pcieport 0000:00:01.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
Signification : Vous avez des erreurs PCIe corrigées. Pas toujours fatales, mais si elles coïncident avec des écrans noirs, vous pouvez avoir des problèmes d’intégrité du signal ou de gestion d’alimentation.
Décision : Essayez un autre slot, désactivez ASPM dans le BIOS, mettez à jour le BIOS, ou retirez les risers. N’« optimisez » pas tant que ce n’est pas stable.
Task 11: Check QEMU/libvirt assignment errors (the “it never really attached” case)
cr0x@server:~$ journalctl -u libvirtd -b --no-pager | tail -n 30
Feb 04 09:15:02 server libvirtd[1123]: internal error: qemu unexpectedly closed the monitor: 2026-02-04T09:15:02.123456Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0: vfio 0000:01:00.0: group 16 is not viable
Feb 04 09:15:02 server libvirtd[1123]: internal error: qemu unexpectedly closed the monitor: 2026-02-04T09:15:02.123499Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0: Please ensure all devices within the iommu_group are bound to their vfio bus driver.
Signification : Classique : le groupe IOMMU contient quelque chose qui n’est pas lié à VFIO, donc QEMU refuse ou plante.
Décision : Soit liez tout le groupe à VFIO (dangereux s’il inclut des périphériques critiques de l’hôte), soit retravaillez l’isolation (préféré).
Task 12: Confirm the guest firmware mode and GPU ROM handling
Signification : La VM utilise OVMF (UEFI). ROM BAR est activé (ce n’est pas la même chose que fournir un fichier ROM, mais c’est pertinent).
Décision : Si vous utilisez le BIOS legacy (SeaBIOS) avec un GPU moderne et que vous observez des écrans noirs après redémarrage, passez à OVMF sauf raison spécifique contraire.
Task 13: Check for the classic “NVIDIA Code 43” and distinguish it from IOMMU issues
cr0x@server:~$ virsh qemu-agent-command win11-gpu '{"execute":"guest-get-osinfo"}'
{"return":{"id":"mswindows","name":"Microsoft Windows","pretty-name":"Microsoft Windows 11","version":"10.0"}}
Signification : L’agent invité répond ; le système invité est vivant même si vous affichez un écran noir.
Décision : Si l’invité est vivant, votre problème peut être l’initialisation de l’affichage, l’état du pilote, ou la sélection de sortie — pas un échec total d’attachement du périphérique.
Task 14: Validate that the GPU isn’t still “in use” by a host process
Signification : Le groupe VFIO est détenu par le processus QEMU. C’est attendu quand la VM est en cours d’exécution.
Décision : Si autre chose le tient (ou s’il est détenu après l’arrêt de la VM), vous avez un problème de nettoyage/réinitialisation. Corrigez les hooks d’arrêt, et envisagez un vendor-reset ou une politique de cycle d’alimentation complet.
Task 15: Force-check IOMMU feature flags for Intel platforms
Signification : Vous avez les éléments qui rendent le passthrough moins hanté.
Décision : Si le remappage d’interruptions manque, cherchez des options BIOS comme « Interrupt Remapping » ou « Posted Interrupt ». Certaines cartes l’enfouissent sous « Security ».
Task 16: Check whether the GPU supports and advertises reset capabilities
Signification : Cet extrait seul ne confirme pas FLR, mais lspci -vv est l’endroit où chercher les capacités et comportements liés à la réinitialisation.
Décision : Si vous voyez constamment « marche une fois » et que la carte manque de bon comportement de reset, prévoyez des mitigations : vendor-reset pour certains AMD, cycle d’alimentation complet de l’hôte après arrêt de la VM, ou choisissez un GPU différent.
Trois mini-récits d’entreprise depuis le terrain
Incident #1 : La mauvaise hypothèse (« Le redémarrage est un ardoise propre »)
Une entreprise de taille moyenne gérait une petite flotte VDI pour une équipe de designers. Rien d’exotique : KVM, VFIO, quelques GPU par hôte, invités Windows.
En staging ça marchait depuis des semaines. Puis le premier patch Tuesday est arrivé, et tout le monde a redémarré les hôtes pendant le week-end.
Lundi matin : un tiers des VMs étaient revenues avec écran noir.
L’hypothèse intégrée à leur runbook était simple : un redémarrage hôte réinitialise le matériel, donc le GPU reviendra toujours propre.
Cette hypothèse était fausse à deux égards. Premièrement, le GPU était le périphérique d’affichage principal dans le BIOS sur certains hôtes,
donc le firmware et le framebuffer de la console hôte l’avaient touché avant que VFIO puisse le réclamer. Deuxièmement, un réglage BIOS
(« fast boot ») a changé le timing d’initialisation PCIe et modifié quels périphériques atterrissaient dans quels groupes IOMMU.
Le diagnostic a pris plus de temps que nécessaire parce que l’équipe chassait les logs côté invité.
Ces logs étaient réels, mais pas causaux. Le GPU n’avait jamais vraiment appartenu à l’invité dans les cas échoués.
La preuve était dans lspci -nnk : le pilote hôte possédait le GPU sur les hôtes défaillants.
La correction a été ennuyeuse et efficace : standardiser les paramètres du BIOS, forcer l’iGPU comme principal pour l’hôte,
et s’assurer que la liaison VFIO se produit dans l’initramfs avec les IDs corrects pour le GPU et la fonction audio.
Après cela, les redémarrages sont redevenus prévisibles — ce qui est le seul type de redémarrage souhaitable en production.
Incident #2 : L’optimisation qui s’est retournée contre eux (« Activons tous les réglages performance »)
Un autre service voulait un maximum de performance GPU pour des charges de calcul dans les invités. Quelqu’un (bien intentionné)
a activé Resizable BAR, Above 4G decoding, et quelques réglages de gestion d’alimentation PCIe à travers la flotte.
Sur le papier, cela peut aider certaines charges. En réalité, cela a introduit une disposition de ressources PCIe incohérente au démarrage.
Le symptôme immédiat n’était pas la performance. C’était des écrans noirs intermittents après redémarrage, concentrés sur un modèle de carte mère.
Certains hôtes redémarraient avec le GPU dans un groupe IOMMU qui incluait maintenant un pont PCIe et un contrôleur USB.
QEMU refusait parfois de démarrer, d’autres fois la VM démarrait mais le GPU n’initialisait pas la sortie.
L’équipe a perdu une journée parce que les changements étaient des « réglages de performance », et personne n’a mentalement relié cela à l’isolation.
Le postmortem a été franc : si votre plateforme n’est pas validée pour ces bascules, traitez-les comme des fonctionnalités expérimentales.
Ils ont annulé les changements de gestion d’alimentation en premier, puis validé Resizable BAR hôte par hôte.
La stabilité est revenue. La performance aussi — parce que la performance arrive après la fiabilité, pas à la place d’elle.
Blague #2 : Si vous activez tous les commutateurs BIOS étiquetés « turbo », vous ne peaufinez pas — vous auditionnez pour la ligue de la roulette des redémarrages.
Incident #3 : La pratique ennuyeuse qui a sauvé la journée (« Preuve de référence après chaque changement »)
Une équipe plus disciplinée gérait un petit programme « hôte doré ». À chaque changement de firmware, noyau, ou paquets d’hyperviseur,
ils capturaient un lot de référence : /proc/cmdline, les lignes dmesg confirmant IOMMU, les listings de groupes IOMMU, et lspci -nnk pour le GPU. Ils stockaient ça avec le ticket de changement. Personne n’a célébré.
C’était de la paperasse avec des sorties de commandes.
Puis une mise à jour de noyau routinière a coïncidé avec un problème d’écran noir après redémarrage sur deux hôtes.
Au lieu de débattre pour savoir si c’était « le pilote GPU », ils ont diffé les bundles de référence.
La preuve est apparue immédiatement : la cmdline n’avait plus les IDs VFIO attendus sur les hôtes affectés.
Un fragment de config du chargeur de démarrage avait été écrasé pendant une transition de paquet.
La correction a été rapide parce qu’ils n’avaient pas besoin de redécouvrir le système ; ils devaient juste le restaurer.
Ils ont corrigé la config de démarrage, reconstruit l’initramfs, et redémarré une fois. Les VMs sont revenues.
La grande victoire n’était pas un génie technique — c’était d’avoir la preuve de ce à quoi ressemblait « fonctionnel ».
C’est la réalité non-glamour de l’exécution de virtualisation en production : vous n’empêchez pas toutes les pannes.
Vous empêchez celles qui vous font perdre du temps.
Erreurs courantes : symptôme → cause racine → correctif
1) Écran noir seulement après redémarrage ; premier démarrage après coupure complète OK
Cause racine : Bizarrerie de reset du GPU. Le périphérique ne revient pas dans un état propre après des warm boots ou des arrêts/démarrages de VM.
Fix : Préférez des GPU avec FLR fiable ; essayez un contournement de reset via noyau/module (si applicable), ou imposez un cycle d’alimentation hôte après arrêt de VM. Évitez les états de « suspend » pour l’hôte.
2) La VM démarre, l’invité est joignable (RDP/SSH), mais le moniteur physique reste noir
Cause racine : Mauvaise sortie, désaccord d’initialisation UEFI/ROM, ou le pilote invité choisit un autre chemin d’affichage.
Fix : Passez la VM à OVMF ; assurez-vous que la gestion du ROM GPU est correcte ; testez une autre sortie ; retirez les affichages virtuels supplémentaires ; vérifiez que l’invité voit le GPU et la sortie sélectionnée.
3) QEMU/libvirt signale « group is not viable » après redémarrage
Cause racine : Le groupe IOMMU contient des périphériques non liés à VFIO, ou le groupe a changé après une mise à jour du firmware.
Fix : Re-vérifiez l’appartenance au groupe ; déplacez le GPU dans un autre slot ; changez les paramètres PCIe du BIOS ; évitez ACS override sauf si vous acceptez le risque ; ne liez tout le groupe que si c’est sûr.
4) Le GPU se lie à nouveau à nouveau à nouveau à nouveau nouveau (nouveau/nvidia/amdgpu) sur l’hôte après redémarrage
Cause racine : La liaison VFIO ne se produit pas assez tôt ; initramfs manque votre config vfio ; les blacklists ne sont pas appliquées au démarrage.
Fix : Mettez les IDs vfio-pci dans la config modprobe ; blacklistiez les pilotes GPU hôte si nécessaire ; reconstruisez l’initramfs ; confirmez avec lspci -nnk après redémarrage.
5) Tout marchait jusqu’à ce que vous activiez « fast boot » ou changiez CSM/UEFI
Cause racine : Le chemin d’initialisation du firmware a changé ; la sélection du GPU principal a changé ; le comportement de l’option ROM a changé.
Fix : Désactivez le fast boot pour les hôtes de passthrough ; standardisez le mode UEFI ; définissez un GPU non-passthrough comme principal si possible.
6) Le pilote invité se charge puis crash ; le périphérique disparaît ou génère des erreurs
Cause racine : Remappage d’interruptions ou fonctionnalités IOMMU manquantes ; parfois des bizarreries MSI/MSI-X.
Fix : Vérifiez le remappage d’interruptions dans dmesg ; mettez à jour le BIOS ; assurez-vous que VT-d/AMD-Vi est complètement activé ; testez un noyau plus récent.
7) Écran noir coïncide avec du spam AER PCIe après redémarrage
Cause racine : Intégrité du signal (câbles riser), gestion d’alimentation (ASPM), PSU limite, ou problèmes d’entraînement de ligne du slot.
Fix : Retirez les risers ; essayez un autre slot ; désactivez ASPM ; mettez à jour le BIOS ; validez l’alimentation.
Listes de vérification / plan étape par étape
Checklist de base (faites ceci quand ça marche)
Capturez /proc/cmdline et gardez-la avec vos notes de changement.
Capturez les lignes dmesg confirmant IOMMU + remappage d’interruptions.
Capturez l’appartenance aux groupes IOMMU pour les fonctions GPU.
Capturez lspci -nnk montrant vfio-pci comme « in use » pour le GPU et l’audio.
Capturez le mode de firmware de la VM (OVMF vs SeaBIOS) et le mapping hostdev.
Plan de récupération quand vous avez redémarré et que c’est maintenant noir
Arrêtez la VM (si elle tourne) pour éviter des tentatives d’init répétées du périphérique qui compliquent les logs.
Confirmez que les adresses PCI du GPU n’ont pas changé (lspci -nn).
Vérifiez la propriété des pilotes (lspci -nnk -s 01:00.0 et 01:00.1).
Vérifiez les groupes IOMMU et confirmez que le groupe est viable.
Consultez les logs du noyau pour AER et erreurs VFIO (journalctl -b -k).
Vérifiez le mode de firmware (OVMF recommandé pour invités modernes) et retirez les périphériques d’affichage virtuels en conflit.
Si c’est un problème de reset, essayez un cycle d’alimentation complet de l’hôte (pas un simple redémarrage). Si cela règle le problème, traitez le comportement de reset comme la cause racine et planifiez des mitigations.
Plan de durcissement (rendre les redémarrages ennuyeux à nouveau)
Standardisez les paramètres BIOS à travers les hôtes : VT-d/AMD-Vi activé, remappage d’interruptions activé, fast boot désactivé.
Préférez un périphérique d’affichage dédié pour l’hôte (iGPU ou GPU secondaire bon marché) afin que le firmware n’initialise pas votre GPU passthrough.
Liez VFIO dans l’initramfs, pas « tard » au démarrage. La liaison tardive est une course que vous finirez par perdre.
Évitez ACS override dans les environnements nécessitant une isolation sérieuse ; si vous devez l’utiliser, documentez et revoyez.
Après tout changement de BIOS/noyau, revalidez les groupes IOMMU. Traitez-le comme une migration de schéma, parce que c’en est une.
Une idée paraphrasée souvent attribuée à Werner Vogels : vous construisez la fiabilité en attendant l’échec et en concevant pour lui, pas en espérant que le chemin heureux reste heureux.
FAQ
1) Pourquoi ça marche jusqu’à ce que je redémarre l’hôte ?
Le redémarrage change la chaîne de garde. Le firmware peut initialiser le GPU différemment, le pilote hôte peut se lier plus tôt,
et les groupes IOMMU peuvent être énumérés différemment. Les warm boots ne réinitialisent pas toujours proprement les GPU grand public.
2) L’IOMMU est-il toujours requis pour le passthrough GPU ?
Pour un passthrough sûr et correct sur les systèmes modernes : oui. Sans IOMMU, l’isolation DMA n’est pas appliquée,
et VFIO ne peut pas assigner le périphérique en toute sécurité à un invité.
3) Quelle est la différence entre intel_iommu=on et iommu=pt ?
intel_iommu=on active l’IOMMU Intel. iommu=pt met les périphériques non-passthrough en mode pass-through pour réduire la surcharge.
Vous conservez l’isolation pour les périphériques liés à VFIO ; vous ne forcez simplement pas la traduction pour tout le reste.
4) Dois-je passer aussi la fonction audio du GPU ?
En général, oui. Beaucoup de GPU sont des périphériques multifonctions et se comportent mieux quand toutes les fonctions liées dans le même groupe IOMMU sont assignées ensemble.
Sauter la fonction audio peut causer des comportements étranges à l’initialisation ou lors du reset.
5) Si mon groupe IOMMU contient d’autres périphériques, puis-je quand même passer seulement le GPU ?
Pratiquement : parfois, avec ACS override ou des configurations non sûres. Correctement : le groupe est l’unité d’isolation.
Si le groupe inclut des périphériques critiques de l’hôte, votre correctif à long terme est matériel/slot/topologie, pas « forcer » le passage.
6) L’ACS override est-il sûr ?
Cela peut être acceptable dans un environnement personnel. C’est un compromis de sécurité et de correction : vous dites au noyau de supposer une séparation qui peut ne pas exister.
Si vous tenez aux garanties d’isolation, évitez-le et corrigez la plateforme à la place.
7) Pourquoi la VM tourne mais je n’ai pas de vidéo ?
Parce que « la VM tourne » signifie seulement que QEMU est vivant. La sortie vidéo dépend de l’initialisation du GPU, du mode firmware, et de la sélection de la sortie.
Vérifiez que l’invité voit le GPU, et essayez OVMF plus un chemin de sortie physique différent.
8) Dois-je utiliser OVMF (UEFI) ou SeaBIOS ?
Pour Windows modernes et les GPU récents, OVMF est généralement la voie la moins douloureuse. SeaBIOS peut fonctionner, mais augmente le risque de bizarreries ROM/init.
Si vous pourchassez des écrans noirs post-redémarrage, passer à OVMF est souvent un avantage net.
9) Que faire si l’hôte n’a pas d’iGPU et qu’il n’y a qu’un seul GPU ?
Vous pouvez toujours le faire, mais vous choisissez le « mode difficile ». L’hôte initialisera probablement ce GPU pour la sortie console.
Attendez-vous à lutter contre la liaison précoce et la propriété du framebuffer. Un GPU secondaire bon marché économise souvent du temps.
10) Quelle est la commande la plus utile pour déboguer ceci ?
lspci -nnk sur les fonctions GPU. Elle vous dit qui possède le périphérique en ce moment. La propriété est l’histoire.
Si votre passthrough GPU affiche un écran noir après redémarrage, arrêtez de le traiter comme un caprice mystique de la carte.
Traitez-le comme un problème système : vérifiez que l’IOMMU est activé et pleinement fonctionnel, vérifiez que VFIO se lie tôt,
vérifiez que les groupes IOMMU sont stables et isolés, et ce n’est qu’ensuite que vous poursuivez les bizarreries de reset et les chemins d’affichage.
Prochaines étapes pratiques :
Exécutez les Tasks 1–5 et enregistrez les sorties. C’est votre baseline et votre cible de diff.
Rendez la liaison VFIO déterministe au démarrage (initramfs), pas « éventuellement ».
Revérifiez les groupes IOMMU après tout changement de BIOS ou noyau. Considérez qu’ils ont changé jusqu’à preuve du contraire.
Si votre plateforme nécessite ACS override pour fonctionner, considérez cela comme un problème de sélection matérielle — pas une victoire de tuning du noyau.
Si vous confirmez un problème de reset, planifiez une politique de mitigation (cycle d’alimentation, GPU différent, ou un outil de réinitialisation fournisseur quand approprié) au lieu de redémarrer en espérant.
L’objectif n’est pas de le faire fonctionner une fois. L’objectif est de le faire survivre au prochain redémarrage sans cérémonie.