Écran noir en passthrough GPU Proxmox : UEFI/OVMF, ROM, bugs de reset et solutions éprouvées

Playbook de diagnostic rapide (vérifiez ceci d’abord)

Ceci est la séquence « arrêtez de tourner en rond ». Elle est optimisée pour obtenir un premier signal rapidement et évite les gouffres comme trifouiller des options QEMU aléatoires avant d’avoir confirmé les bases.

1) Confirmer si l’invité est vivant ou mort

• Si Windows démarre et que vous pouvez vous connecter via RDP : vous avez probablement un problème d’initialisation d’affichage (firmware/ROM/affichage primaire), pas un échec total du passthrough.
• Si la VM ne démarre pas du tout : suspectez IOMMU, liaison VFIO, ou un blocage/réinitialisation dure.

2) Vérifier qu’IOMMU est réellement activé et que les groupes sont cohérents

Si IOMMU n’est pas activé, vous ne faites pas du passthrough ; vous faites de la danse interprétative.

3) Vérifier que le GPU est lié à vfio-pci sur l’hôte

Les écrans noirs arrivent fréquemment quand le pilote hôte a attrapé la carte en premier, laissant VFIO avec des restes (ou un périphérique partiellement initialisé).

4) Assortir le firmware aux besoins du GPU : OVMF pour les cartes GOP UEFI

Les GPU modernes, surtout si vous voulez le GPU comme affichage primaire dans l’invité, se comportent généralement mieux avec OVMF + Q35.

5) Décider si vous avez besoin d’un fichier ROM

Si le GPU n’affiche rien jusqu’à ce que le pilote invité se charge (ou n’affiche jamais rien), vous devrez peut‑être fournir un ROM propre avec une section GOP valide — ou empêcher l’hôte de le poster.

6) Si ça a fonctionné une fois mais échoue après redémarrage de la VM : supposez un bug de reset

Succès au premier démarrage suivi d’un écran noir aux démarrages suivants est le signe classique « le GPU ne s’est pas réinitialisé ». Traitez‑le comme tel jusqu’à preuve du contraire.

Ce que signifie réellement un « écran noir » en passthrough

« Écran noir » est un symptôme paresseux. Vous devez déterminer exactement lequel des cas suivants vous voyez :

• Aucun signal vers le moniteur : le GPU ne pilote jamais le connecteur (initialisation non effectuée, mauvais périphérique primaire, ou GPU toujours détenu par l’hôte/firmware).
• Signal présent mais image noire : le lien est actif, mais aucun framebuffer n’est affiché (mauvais appariement firmware/driver, mauvaise résolution, invité bloqué avant le transfert graphique).
• Affiche le splash OVMF puis devient noir : l’initialisation du firmware a réussi ; le passage au système invité/au pilote échoue (conflits de pilotes Windows, Code 43, problèmes de modesetting Linux).
• Fonctionne uniquement après cold boot : bug de reset ou problème d’état d’alimentation (FLR absent, transitions D3cold, comportement de reset spécifique au fournisseur).
• Fonctionne seulement avec un dongle HDMI dummy : problèmes de détection EDID/moniteur, surtout pour les sessions distantes ou configurations sans écran.

Règle opérationnelle : séparez « succès d’assignation du périphérique » et « succès de l’affichage ». VFIO peut assigner un GPU parfaitement pendant que l’invité ne parvient jamais à allumer l’écran.

Exactement une citation, parce qu’elle s’applique ici : la fiabilité vient d’opérations disciplinées et de l’élimination des classes de défaillance, pas du dépannage héroïque à 2 h du matin de James Hamilton.

Faits intéressants et contexte historique (parce que ce bazar a une histoire)

1. Le passthrough PCI existe depuis des décennies, bien avant le « homelab GPU passthrough ». Les hyperviseurs d’entreprise utilisaient l’assignation directe de périphériques pour les NIC et les HBA bien avant que les joueurs ne découvrent VFIO.
2. UEFI GOP a changé la donne pour l’affichage en early‑boot. Les ROM option VGA héritées suffisaient à l’époque du BIOS ; le firmware UEFI préfère un ROM compatible GOP pour une initialisation graphique propre.
3. OVMF est essentiellement l’UEFI pour QEMU. C’est le firmware open source qui rend les VM UEFI pratiques dans les environnements KVM.
4. IOMMU a été poussé autant pour la sécurité DMA que pour la virtualisation. Sans remappage DMA, un périphérique peut écrire n’importe où en mémoire. Le passthrough sans IOMMU est un cauchemar de sécurité.
5. ACS (Access Control Services) existe pour isoler le trafic PCIe. Les cartes mères grand public rognent souvent sur ça, ce qui explique pourquoi certains activent ACS override et ensuite s’étonnent d’une isolation imparfaite.
6. « Reset » n’est pas un mécanisme unique. FLR, reset de bus, transitions d’état d’alimentation et resets spécifiques aux fournisseurs se comportent différemment.
7. Certaines cartes GPU sont des périphériques multi‑fonction. La fonction audio (HDMI/DP) et le contrôleur USB (sur certaines cartes) doivent être passés ensemble, sinon vous obtenez des comportements étranges.
8. L’historique du Code 43 de NVIDIA a façonné la culture du passthrough. Le comportement des pilotes en environnements virtualisés a poussé aux contournements, puis vers des configurations mieux supportées.
9. Resizable BAR a changé les attentes. Les gros mappings BAR peuvent solliciter le firmware/host et parfois révéler des bugs d’initialisation plateforme.

Blague 1 : Le passthrough GPU est le seul hobby où « J’ai changé une ligne dans GRUB et redémarré huit fois » compte comme une soirée tranquille.

UEFI/OVMF vs SeaBIOS : choisissez en fonction de la réalité

Si vous retenez une chose : ne choisissez pas SeaBIOS parce que ça semble « plus simple ». Choisissez le firmware selon ce que le GPU et le système invité attendent.

Quand OVMF est le bon choix

• Vous voulez Windows 11, Secure Boot activé/désactivé, ou un démarrage UEFI moderne.
• Vous voulez que le GPU passé soit l’affichage primaire de l’invité.
• Le ROM option du GPU est UEFI‑first (courant sur les cartes récentes).
• Vous souhaitez un comportement plus propre avec le type de machine Q35 et la topologie PCIe.

Quand SeaBIOS peut encore fonctionner

• GPU plus anciens avec ROM VGA legacy robustes.
• Installations d’invités anciennes conçues pour démarrage BIOS.
• Cas particuliers où l’initialisation GOP UEFI pose problème et où l’init legacy marche mieux.

Pièges courants d’OVMF qui ressemblent à un « GPU cassé »

• Mauvais ordre des périphériques d’affichage : si vous laissez un VGA virtuel (comme SPICE/QXL) et que l’invité l’utilise comme primaire, votre GPU passé peut ne pas s’afficher avant le chargement des pilotes — ou jamais.
• Problèmes de variable store OVMF : un fichier NVRAM corrompu peut vous coincer dans des états de démarrage étranges. Recréez‑le plutôt que de négocier avec lui.
• Attentes CSM : les invités UEFI‑only peuvent ne pas démarrer depuis des disques formatés BIOS ; cela peut se faire passer pour un « pas d’affichage GPU ».

Fichiers ROM, GOP, et pourquoi votre GPU a parfois « besoin d’un ROM »

Un ROM GPU (option ROM) est le blob firmware qui initialise la carte pendant le démarrage précoce. En passthrough, QEMU peut tenter d’utiliser le ROM du périphérique, mais plusieurs facteurs entrent en jeu :

• Le firmware de l’hôte peut déjà avoir posté le GPU, le laissant dans un état inattendu pour le firmware invité.
• Le périphérique peut ne plus exposer une région ROM lisible une fois que le pilote hôte lui est lié.
• Certains ROM fournisseurs incluent à la fois VGA legacy et GOP UEFI ; d’autres incluent l’un ou l’autre ; certains sont… « créatifs ».

Quand fournir un fichier ROM est une solution éprouvée

• Écran noir au démarrage, mais le GPU fonctionne sur d’autres machines ou en bare metal.
• OVMF n’affiche jamais son splash sur la sortie du GPU.
• Le GPU n’est pas l’affichage primaire au démarrage et n’est jamais initialisé correctement.
• Configurations multi‑GPU où l’hôte poste un GPU et vous passez l’autre.

Quand un fichier ROM aggrave la situation

• Vous utilisez un ROM extrait d’un SKU différent ou d’une révision de carte différente.
• Le ROM contient des straps spécifiques à la carte qui ne correspondent pas exactement à votre carte.
• Vous tronquez ou « corrigez » le ROM incorrectement (surtout sur les cartes NVIDIA avec en‑têtes).

En termes de production : un fichier ROM est un outil chirurgical, pas un talisman porte‑bonheur. Si vous n’avez pas de raison, n’introduisez pas une variable supplémentaire.

Bugs de reset PCIe : FLR, D3hot/D3cold, et le problème AMD

Le reset est l’endroit d’où proviennent la plupart des histoires « ça fonctionnait hier ». Un GPU peut être passé proprement, utilisé, puis ne pas revenir après un redémarrage invité ou un arrêt/démarrage de VM.

Trois motifs de reset que vous verrez

1. Fonctionne seulement au cold‑boot : le GPU marche après un cycle d’alimentation complet de l’hôte, pas après un redémarrage de VM. C’est un écart d’initialisation/reset.
2. Contamination par le pilote hôte : le pilote hôte se lie une fois (même brièvement), initialise le GPU, et plus tard VFIO remet un périphérique mal configuré à l’invité.
3. Reset de fonction partiel : la fonction graphique se réinitialise, mais la fonction audio (ou USB) ne le fait pas, provoquant des problèmes d’énumération ou des comportements de pilote étranges.

FLR n’est pas garanti

Function Level Reset est optionnelle. Certaines GPUs la déclarent, d’autres ne l’implémentent pas correctement, et certaines plateformes ne la propagent pas proprement. Vous ne pouvez pas « croire » en FLR.

La réalité du « bug de reset » AMD

Les anciennes cartes AMD (et quelques‑unes pas si vieilles) sont tristement célèbres pour ne pas se réinitialiser dans un état propre pour une réutilisation par VFIO. Les solutions communautaires vont du module vendor‑reset au basculement des états d’alimentation ; les résultats varient selon les versions du noyau, les générations de cartes et le comportement de la carte mère.

Blague 2 : Le moyen le plus rapide de tester si vous avez un bug de reset est de redémarrer la VM — votre GPU demandera immédiatement le divorce.

Liaison hôte, vfio-pci, et la lutte des pilotes

L’hôte ne doit pas « aider ». Si l’hôte attrape le GPU avec nvidia, amdgpu ou nouveau avant que VFIO ne le fasse, vous obtenez souvent un écran noir, ou pire : un GPU qui fonctionne à moitié puis se bloque plus tard.

À quoi ressemble le « correct »

• Au démarrage, les fonctions GPU sont liées à vfio-pci.
• La console hôte utilise un GPU différent, un iGPU, ou une console série.
• Proxmox démarre la VM, QEMU réclame le périphérique PCIe, et le pilote invité voit un GPU propre et exclusif.

À quoi ressemble le « presque correct »

• Le GPU est lié à vfio-pci, mais le pilote framebuffer de l’hôte l’a encore mappé.
• La fonction audio HDMI est encore liée à snd_hda_intel.
• Il y a un groupe IOMMU avec un contrôleur USB ou SATA collé au GPU, et vous n’avez passé que le GPU.

Q35 vs i440fx, GPU primaire, et périphériques d’affichage qui vous sabotent

Dans Proxmox, vous choisissez un type de machine. Traitez‑le comme du matériel.

Q35 est généralement le choix sensé

Q35 modélise un chipset plus moderne avec des root ports PCIe. Cela compte pour les GPU qui attendent un comportement PCIe, et peut influencer le reset et l’ordre d’énumération des périphériques.

i440fx est compatibilité legacy

Parfois on l’utilise parce qu’un ancien invité l’attend. Pour le passthrough GPU moderne, Q35 tend à réduire les bizarreries.

Passthrough du GPU primaire : supprimez les affichages virtuels concurrents

Si vous voulez que votre GPU passé soit l’affichage de démarrage, ne laissez pas un périphérique VGA virtuel comme primaire évident. En termes Proxmox : définir vga: none si vous comptez vraiment utiliser le GPU physique pour la sortie console.

Tâches pratiques (commandes, ce que signifie la sortie, et la décision à prendre)

Ce sont de vraies opérations. Exécutez‑les sur l’hôte Proxmox sauf indication contraire. Chacune inclut le « et alors ? » parce que la sortie sans décision n’est que journalisation pour le plaisir.

Task 1: Confirmer que le CPU et le noyau voient les extensions de virtualisation

cr0x@server:~$ egrep -m1 '(vmx|svm)' /proc/cpuinfo
flags		: fpu vme de pse tsc ... vmx ...

Sens : vmx (Intel) ou svm (AMD) doit apparaître. Si ce n’est pas le cas, aucun parcours IOMMU/VFIO ne se terminera bien.

Décision : Si absent, corrigez les réglages BIOS (VT‑x/AMD‑V) avant de toucher aux configs Proxmox.

Task 2: Confirmer qu’IOMMU est activé dans la ligne de commande du noyau

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-2-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt

Sens : Cherchez intel_iommu=on ou amd_iommu=on. iommu=pt est courant pour réduire l’overhead des périphériques non‑passthrough.

Décision : Si absent, éditez GRUB et redémarrez ; n’avancez pas tant que c’est absent.

Task 3: Vérifier que DMAR/IVRS montre que IOMMU est initialisé

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|IVRS' | head -n 8
[    0.824112] DMAR: IOMMU enabled
[    0.824980] DMAR: Host address width 39
[    0.835010] DMAR: DRHD base: 0x000000fed90000 flags: 0x0

Sens : Vous voulez « IOMMU enabled » et pas d’erreurs fatales.

Décision : Si vous voyez des messages de désactivation ou des fautes, corrigez le BIOS (VT‑d/AMD‑Vi) ou les paramètres du noyau avant de continuer.

Task 4: Identifier le GPU et toutes ses fonctions (graphique + audio + extras)

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|audio|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116 [GeForce GTX 1660] [10de:2184]
01:00.1 Audio device [0403]: NVIDIA Corporation TU116 High Definition Audio Controller [10de:1aeb]

Sens : Notez les IDs et fonctions. La fonction audio n’est pas optionnelle en pratique ; passez‑la aussi.

Décision : Prévoyez de passer 01:00.0 et 01:00.1.

Task 5: Vérifier les groupes IOMMU (la vérité sur l’isolation)

cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do echo "$(basename "$(dirname "$d")") $(lspci -nns ${d##*/})"; done | sort -n | sed -n '1,18p'
1 00:01.0 Host bridge [0600]: Intel Corporation Device [8086:1237]
12 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116 [GeForce GTX 1660] [10de:2184]
12 01:00.1 Audio device [0403]: NVIDIA Corporation TU116 High Definition Audio Controller [10de:1aeb]

Sens : Vos fonctions GPU devraient idéalement être dans un groupe seul (ou au moins seulement entre elles).

Décision : Si le groupe inclut des périphériques non liés (USB/SATA), il vous faut un autre emplacement/réglage de carte mère, ou accepter le risque ACS override (voir plus loin).

Task 6: Confirmer quel pilote possède actuellement le GPU

cr0x@server:~$ lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116 [GeForce GTX 1660] [10de:2184]
	Subsystem: Micro-Star International Co., Ltd. [MSI] TU116 [1462:12a3]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Sens : « Kernel driver in use » doit être vfio-pci. Les modules listés sont simplement disponibles, pas nécessairement chargés.

Décision : S’il affiche nvidia ou amdgpu, corrigez la liaison des pilotes (Tâche 7/8).

Task 7: Charger les modules VFIO et vérifier leur présence

cr0x@server:~$ lsmod | egrep 'vfio|kvm'
vfio_pci               16384  0
vfio_pci_core          90112  1 vfio_pci
vfio_iommu_type1       40960  0
vfio                   69632  2 vfio_iommu_type1,vfio_pci_core
kvm_intel             376832  0
kvm                  1105920  1 kvm_intel

Sens : Si les modules VFIO ne sont pas chargés, Proxmox peut encore les charger à la demande, mais explicite vaut mieux que mystique.

Décision : Si absent, assurez‑vous que les modules vfio sont dans /etc/modules et reconstruisez initramfs.

Task 8: Lier le GPU à vfio-pci en utilisant les IDs des périphériques (méthode durable)

cr0x@server:~$ cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:2184,10de:1aeb disable_vga=1

Sens : Cela indique au noyau de lier ces IDs PCI à VFIO tôt. disable_vga=1 peut aider à réduire le conflit d’arbitrage VGA legacy.

Décision : Si vous changez ce fichier, reconstruisez initramfs et redémarrez (Tâche 9).

Task 9: Reconstruire initramfs et confirmer la mise à jour

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.12-2-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..

Sens : Votre environnement d’early boot connaît maintenant les règles de liaison VFIO.

Décision : Redémarrez avant de retester ; les changements à chaud ne sont pas un test fiable ici.

Task 10: Vérifier si l’hôte a encore un framebuffer sur le GPU

cr0x@server:~$ dmesg | egrep -i 'fb0|framebuffer|efifb|simplefb|vesafb' | tail -n 8
[    0.612345] simple-framebuffer simple-framebuffer.0: framebuffer at 0xe0000000, 0x300000 bytes
[    0.612400] fb0: simplefb registered!

Sens : Si l’hôte utilise le GPU passé pour une console framebuffer, vous pouvez obtenir des écrans noirs ou des resets qui ne fonctionnent plus correctement.

Décision : Préférez une console headless (série), un iGPU, ou un second GPU pour l’hôte. Si nécessaire, désactivez l’utilisation du framebuffer hôte (selon la plateforme).

Task 11: Confirmer que la config VM utilise OVMF + Q35 et ne vole pas l’affichage primaire

cr0x@server:~$ qm config 101
boot: order=scsi0;ide2;net0
bios: ovmf
machine: q35
scsi0: local-lvm:vm-101-disk-0,size=128G
hostpci0: 0000:01:00.0,pcie=1,x-vga=1
hostpci1: 0000:01:00.1,pcie=1
vga: none

Sens : bios: ovmf et machine: q35 sont la combinaison « fonctionne plus souvent ». vga: none évite que Proxmox ajoute un affichage concurrent.

Décision : Si vous voyez bios: seabios et GPU/OS modernes, passez à OVMF et réinstallez ou convertissez le mode de démarrage si nécessaire.

Task 12: Surveiller les erreurs QEMU/VFIO au démarrage de la VM

cr0x@server:~$ journalctl -u pvedaemon -u pve-qemu-server --since "10 min ago" | tail -n 60
... vfio-pci 0000:01:00.0: vfio_bar_restore: reset recovery - restoring BARs
... qemu-system-x86_64: vfio: Unable to power on device, stuck in D3
... start failed: QEMU exited with code 1

Sens : « stuck in D3 » est un problème d’état d’alimentation/reset. Ce n’est pas un problème de pilote Windows ; c’est le comportement du host/périphérique.

Décision : Traitez‑le comme un bug de reset : envisagez des mises à jour du noyau, déplacer la carte de slot, désactiver ASPM, ou des approches vendor‑reset (Tâche 16/17).

Task 13: Dumper le ROM GPU (seulement si vous avez une raison)

cr0x@server:~$ echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/rom
1
cr0x@server:~$ sudo cat /sys/bus/pci/devices/0000:01:00.0/rom > /root/gpu.rom
cr0x@server:~$ echo 0 | sudo tee /sys/bus/pci/devices/0000:01:00.0/rom
0
cr0x@server:~$ ls -lh /root/gpu.rom
-rw-r--r-- 1 root root 256K Jan  8 12:14 /root/gpu.rom

Sens : Vous obtenez une image ROM de taille plausible. Si cela échoue avec « Operation not permitted » ou des zéros, le périphérique peut être lié/posté d’une manière qui bloque la lecture.

Décision : Si vous pouvez dumper, essayez‑le comme ROM. Si vous ne pouvez pas, n’usez pas de force — corrigez d’abord la liaison/le posting hôte.

Task 14: Attacher le fichier ROM à la VM (expérience ciblée)

cr0x@server:~$ qm set 101 --hostpci0 0000:01:00.0,pcie=1,x-vga=1,romfile=gpu.rom
update VM 101: -hostpci0 0000:01:00.0,pcie=1,x-vga=1,romfile=gpu.rom

Sens : Proxmox transmettra ce ROM à QEMU. Le ROM doit exister sous /usr/share/kvm/ ou être référencé correctement selon les attentes de Proxmox ; placez‑le avant de redémarrer la VM.

Décision : Si cela corrige l’affichage early boot, conservez‑le. Si cela casse l’initialisation du pilote, retirez‑le et réévaluez (ROM incorrect ou inutile).

Task 15: Vérifier les consommateurs « en cours d’utilisation » qui bloquent le passthrough

cr0x@server:~$ fuser -v /dev/nvidia0 2>/dev/null || true
                     USER        PID ACCESS COMMAND
/dev/nvidia0:        root       1321 F....  nvidia-persistenced

Sens : Si le démon de persistance NVIDIA ou un gestionnaire d’affichage utilise le GPU, l’assignation VFIO sera contaminée.

Décision : Arrêtez/désactivez les consommateurs sur l’hôte. Les hôtes de passthrough ne doivent pas exécuter des stacks desktop sur le même GPU que celui que vous passez.

Task 16: Inspecter la capacité de reset et les indices de gestion d’alimentation

cr0x@server:~$ lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta|ASPM|FLR|PM' | head -n 30
LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <8us
LnkSta:	Speed 8GT/s, Width x16
Capabilities: [b0] MSI-X: Enable+ Count=32 Masked-
Capabilities: [d0] Power Management version 3
Kernel driver in use: vfio-pci

Sens : Vous cherchez des indices : présence d’ASPM, version de gestion d’alimentation, et si la plateforme force des états d’alimentation agressifs.

Décision : Si vous voyez des erreurs répétées liées à D3 dans les logs, envisagez de désactiver ASPM dans le BIOS ou via les paramètres du noyau comme test.

Task 17: Détecter le bug « fonctionne une fois » à l’aide d’une boucle de redémarrage contrôlée

cr0x@server:~$ qm start 101
started VM 101
cr0x@server:~$ sleep 30
cr0x@server:~$ qm shutdown 101 --timeout 90
stopping VM 101 (shutdown)
cr0x@server:~$ qm start 101
started VM 101

Sens : Si le premier démarrage affiche et que le deuxième donne un écran noir, vous venez de reproduire un bug de reset sans superstition.

Décision : Passez aux atténuations de reset : mise à jour noyau, changement de slot, éviter le posting par l’hôte, ou module vendor‑reset pour les GPU AMD concernés.

Task 18: Valider que vous avez passé tout le groupe IOMMU lorsque c’est requis

cr0x@server:~$ ls -l /sys/kernel/iommu_groups/12/devices/
total 0
lrwxrwxrwx 1 root root 0 Jan  8 12:20 0000:01:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
lrwxrwxrwx 1 root root 0 Jan  8 12:20 0000:01:00.1 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.1

Sens : Seulement le GPU et son audio sont dans le groupe. C’est bon. S’il y en avait plus, le passthrough pourrait nécessiter de passer tout le groupe (souvent inacceptable).

Décision : Si le groupe inclut « d’autres choses », soit passez tout (souvent inacceptable), soit changez de matériel/topologie.

Trois mini-histoires d’entreprise (anonymisées, plausibles, techniquement exactes)

Incident causé par une mauvaise hypothèse : « UEFI est optionnel »

Une entreprise de taille moyenne voulait des VMs Windows avec GPU pour une équipe CAO. L’équipe virtualisation utilisait Proxmox, et quelqu’un avait déjà passé un HBA avec succès, donc l’ambiance était « même chose, périphérique PCI différent ». Ils ont créé un template VM avec SeaBIOS parce que ça correspondait aux anciens templates serveur. Ça a démarré sur SPICE, donc ils ont considéré que c’était bon.

Le jour du déploiement, ils ont ajouté des GPU. Écrans noirs partout sur les écrans physiques, mais RDP fonctionnait. Ils ont d’abord accusé les pilotes, puis les câbles, puis les moniteurs, puis les mises à jour Windows — spirale classique de déresponsabilisation.

Le vrai problème était simple : le GPU passé ne devenait jamais l’affichage early boot parce que le chemin firmware ne correspondait pas aux attentes de la carte. SeaBIOS + le comportement du ROM de la carte + un VGA virtuel concurrent signifiaient que l’invité n’initialisait jamais la sortie d’une manière compatible avec leur flux physique.

La correction était ennuyeuse : passer à OVMF, définir Q35, retirer le VGA virtuel (vga: none), et passer le GPU comme primaire avec x-vga=1. Ils ont aussi reconstruit le template VM pour éviter de répéter l’erreur. Le postmortem contenait une ligne clé : « Nous avons supposé que le choix du firmware était cosmétique. »

Optimisation qui s’est retournée contre eux : ACS override comme « raccourci »

Une autre organisation utilisait Proxmox sur des cartes grand public pour raison de budget. Leurs groupes IOMMU étaient nuls : GPU groupé avec un contrôleur USB et un contrôleur NVMe derrière le même root complex. L’équipe voulait du passthrough GPU pour un service d’inférence IA, et le voulait pour hier.

Ils ont activé ACS override pour séparer les groupes et ont célébré quand l’interface a montré une isolation propre. Ils l’ont poussé en production rapidement. Ça a marché. Pendant un certain temps.

Des semaines plus tard, ils ont eu des freezes hôtes intermittents pendant les redémarrages de VM. Les logs montraient des erreurs PCIe et des accrochages filesystem occasionnels sur le NVMe « séparé ». ACS override n’a pas magiquement ajouté l’isolation matérielle ; il a changé la manière dont le noyau prétendait que les périphériques étaient isolés. Sous certains motifs de trafic, les périphériques interagissaient toujours de façon que le groupement IOMMU essayait d’ignorer.

La solution finale n’était pas un paramètre noyau malin. Ils ont déplacé la charge vers une plateforme avec vraie isolation PCIe et validé les groupes avant le déploiement. ACS override est resté un outil de labo avec un grand panneau d’avertissement : « Peut fonctionner ; peut aussi créer des modes de panne nouveaux. »

Pratique ennuyeuse mais correcte qui a tout sauvé : discipline cold‑boot et contrôle des changements

Une équipe gérant des VMs GPU pour traitement vidéo avait pour habitude : chaque fois qu’ils changeaient la liaison VFIO, le type de firmware, ou les réglages ROM, ils effectuaient un redémarrage complet de l’hôte et documentaient les sorties « avant/après » de lspci -nnk et de la config VM. Pas de « hot swapping » de la plomberie bas niveau.

Ça paraissait lent. Ça l’était. Ça les a aussi empêchés d’empiler plusieurs changements non vérifiés et ensuite deviner lequel avait importé.

Quand ils ont rencontré un écran noir après une mise à jour du noyau Proxmox, leur rollback a été propre : ils ont comparé les sorties « known good », vu que le GPU était maintenant réclamé par un framebuffer durant l’early boot, et l’ont corrigé de façon décisive au lieu de « essayer un autre ROM parce que pourquoi pas ».

L’effet net a été du calme opérationnel. Ils ont traité les changements de passthrough comme des changements de stockage : mesurer, changer une chose, redémarrer, vérifier la propriété, puis continuer.

Erreurs fréquentes : symptôme → cause racine → correctif

1) Symptom: VM démarre (RDP fonctionne) mais l’écran physique reste noir

Cause racine : VGA virtuel est primaire ; le GPU passé n’est pas initialisé comme affichage de démarrage, ou l’invité choisit le mauvais adaptateur.

Correctif : Utilisez bios: ovmf, machine: q35, définissez vga: none, et activez x-vga=1 sur le GPU. Confirmez que le moniteur est connecté au GPU passé, pas à la sortie de l’hôte.

2) Symptom: Écran noir jusqu’au chargement de l’OS, puis parfois fonctionne

Cause racine : Initialisation GOP manquante/quirky au niveau firmware ; le pilote invité active plus tard l’affichage.

Correctif : Préférez OVMF, envisagez de fournir un fichier ROM avec un GOP valide, et assurez‑vous de ne pas utiliser SeaBIOS avec un ROM UEFI‑first.

3) Symptom: Fonctionne après cold boot hôte ; échoue après redémarrage de la VM

Cause racine : Bug de reset (pas de FLR, périphérique bloqué en D3, reset incomplet de fonctions).

Correctif : Mettez à jour le noyau/Proxmox, essayez un autre slot PCIe, désactivez la gestion d’alimentation agressive/ASPM en test, et passez toutes les fonctions GPU ensemble. Pour certaines générations AMD, envisagez une approche vendor‑reset.

4) Symptom: VM échoue à démarrer, « stuck in D3 » ou erreurs de restauration BAR

Cause racine : L’état d’alimentation du GPU ne peut pas être remonté par VFIO ; la plateforme refuse de le remettre sous tension proprement après usage préalable.

Correctif : Évitez la liaison du pilote hôte, assurez une extinction propre, testez le cold boot, ajustez les réglages d’alimentation BIOS, et envisagez de déplacer le GPU vers un slot avec un comportement de power gating différent.

5) Symptom: Instabilité aléatoire sous charge après activation d’ACS override

Cause racine : Isolation factice ; les périphériques partagent toujours un chemin et peuvent interférer ; les hypothèses d’isolation DMA échouent sous contention.

Correctif : Utilisez du matériel avec vraie isolation. Traitez ACS override comme dernier recours et évitez‑le pour des charges critiques.

6) Symptom: L’invité voit le GPU mais le pilote échoue (Windows affiche une erreur ou tombe en fallback)

Cause racine : Politique du pilote, détection de virtualisation problématique, ou topologie de périphérique incorrecte.

Correctif : Utilisez Q35 + OVMF, masquez KVM quand approprié dans les réglages CPU Proxmox, et évitez de mixer adaptateurs d’affichage virtuels avec un passthrough primaire.

7) Symptom: Pas de sortie sur un port DP/HDMI, fonctionne sur un autre

Cause racine : Ordre d’initialisation des ports et quirks de link training pendant l’early boot ; certaines cartes préfèrent certains ports pour la sortie pré‑OS.

Correctif : Testez d’abord des ports/câbles alternatifs. Sérieusement. Ce n’est pas élégant, mais c’est réel.

8) Symptom: Console VM dans Proxmox vide après avoir mis vga: none

Cause racine : C’est attendu — il n’y a pas de console virtuelle.

Correctif : Utilisez un moniteur physique sur le GPU, ou comptez sur RDP/SSH. Si vous avez besoin d’un accès d’urgence, ajoutez temporairement un périphérique d’affichage virtuel pour débogage, puis retirez‑le.

Listes de vérification / plan étape par étape

Checklist A: Passthrough GPU pour la première fois avec le moins de surprises

1. Activez VT‑d/AMD‑Vi dans le BIOS/UEFI.
2. Activez IOMMU dans GRUB (intel_iommu=on ou amd_iommu=on) et redémarrez.
3. Vérifiez que IOMMU est activé via dmesg.
4. Identifiez les fonctions GPU via lspci -nn et notez les IDs GPU + audio.
5. Vérifiez un groupement IOMMU propre ; si les groupes sont confus, stoppez et repensez matériel/topologie.
6. Lie les fonctions GPU à vfio-pci via /etc/modprobe.d/vfio.conf.
7. Reconstruisez initramfs, redémarrez, confirmez Kernel driver in use: vfio-pci.
8. Créez la VM avec bios: ovmf et machine: q35.
9. Ajoutez le GPU en hostpci avec pcie=1 et (si primaire) x-vga=1.
10. Définissez vga: none si vous voulez que le GPU physique soit la console.
11. Démarrez la VM, testez la sortie physique, puis installez les pilotes invités.

Checklist B: Déboguer un écran noir sans cargo‑cult

1. Confirmez que l’invité démarre via RDP/SSH. Si non, concentrez‑vous d’abord sur les erreurs VFIO/IOMMU.
2. Vérifiez les logs Proxmox pour plaintes VFIO power/reset.
3. Confirmez que le GPU est lié à vfio-pci et que l’hôte ne l’utilise pas comme framebuffer.
4. Retirez le VGA virtuel concurrent (vga: none) et utilisez OVMF + Q35.
5. Passez toutes les fonctions GPU (audio, USB si présent) ensemble.
6. Si ça ne fonctionne qu’après cold boot, arrêtez de trifouiller les ROMs et traitez le comportement de reset.
7. Ensuite seulement essayez un fichier ROM, et seulement depuis votre carte exacte.
8. Si vous avez utilisé ACS override, considérez toute instabilité comme « attendue » et planifiez une remediation matérielle.

Checklist C: Stabiliser des GPUs sensibles au reset en production

1. Évitez les boucles arrêt/démarrage de VM ; privilégiez suspend/reprise seulement si validé.
2. Utilisez des arrêts contrôlés et une période d’attente avant redémarrage ; certaines cartes se comportent mieux après une mise au repos propre.
3. Gardez le noyau Proxmox raisonnablement à jour ; la gestion du reset s’améliore avec le temps.
4. Documentez les combinaisons connues bonnes : version noyau, version Proxmox, type de machine VM, usage ROM, slot.
5. Pour les cartes « non réinitialisables », prévoyez des cycles d’alimentation hôte dans les fenêtres de maintenance (laid, mais fiable).

FAQ

1) Pourquoi RDP fonctionne mais l’affichage physique est noir ?

L’OS invité tourne, mais le GPU passé n’est pas l’affichage primaire ou n’a jamais été initialisé pour l’early boot. Corrigez le firmware/topologie : OVMF + Q35, retirez le VGA virtuel, utilisez x-vga=1 si approprié.

2) Ai‑je toujours besoin d’un fichier ROM GPU ?

Non. La plupart des configurations stables n’en ont pas besoin. N’utilisez un ROM que si vous avez un problème d’initialisation précoce spécifique et que vous pouvez dumper le ROM correct de votre carte exacte.

3) Que signifie « stuck in D3 » dans les logs Proxmox ?

Le GPU est dans un état basse consommation et VFIO/QEMU ne peut pas le réveiller. C’est un problème de reset/gestion d’alimentation/plateforme, pas un bug de pilote invité.

4) Dois‑je utiliser Q35 ou i440fx ?

Utilisez Q35 pour le passthrough GPU moderne sauf si vous avez une exigence de compatibilité spécifique. Il modélise mieux la topologie PCIe.

5) Puis‑je passer uniquement la fonction GPU et ignorer l’audio HDMI ?

Parfois « ça marche », mais c’est une mauvaise habitude. Passez toutes les fonctions du groupe IOMMU, surtout la fonction audio. Le passthrough partiel est une excellente façon d’obtenir des comportements intermittents étranges.

6) Pourquoi ça fonctionne après reboot hôte mais pas après redémarrage de la VM ?

Bug de reset classique. Le GPU ne se réinitialise pas proprement entre assignations. Concentrez‑vous sur les atténuations de reset : mises à jour noyau, changement de slot, tweaks de gestion d’alimentation, et contournements connus pour votre génération de GPU.

7) L’ACS override est‑il sûr ?

C’est un compromis : il peut rendre le passthrough possible sur des cartes grand public, mais il peut aussi réduire les garanties d’isolation que vous pensiez avoir. Utilisez‑le en labo. Soyez prudent en production.

8) J’ai mis vga: none et maintenant la console Proxmox est vide. Ai‑je cassé quelque chose ?

Non. Vous avez retiré le périphérique d’affichage virtuel, donc la console Proxmox n’a rien à afficher. C’est voulu si le GPU physique est la console.

9) Dois‑je activer Resizable BAR ?

Si vous recherchez la stabilité, laissez‑le désactivé tant que le passthrough n’est pas stable. ReBAR ajoute une couche de complexité plateforme/firmware. Activez‑le plus tard comme changement contrôlé.

10) Dois‑je pinner les cœurs CPU ou tweaker hugepages pour résoudre un écran noir ?

Presque jamais. Ce sont des réglages de performance. L’écran noir provient généralement du firmware, de la liaison VFIO, du groupement IOMMU, ou du comportement de reset.

Conclusion : prochaines étapes pratiques

Si vous fixez un écran noir, arrêtez de deviner. Commencez par le playbook de diagnostic rapide : confirmez IOMMU, confirmez la liaison VFIO, confirmez OVMF + Q35, retirez le VGA virtuel concurrent, et passez toutes les fonctions GPU. Cette séquence résout une grande partie des cas réels sans folklore.

Si ça fonctionne une fois puis échoue au redémarrage, considérez‑le comme un bug de reset jusqu’à preuve du contraire. Ce n’est pas du pessimisme ; c’est de la reconnaissance de motif. Stabilisez avec des choix de plateforme, des mises à jour du noyau, et une propriété de périphérique propre. Utilisez les fichiers ROM comme outils ciblés, pas comme rituels.

Étapes à faire dès aujourd’hui :

• Exécutez la Tâche 5 (groupes IOMMU) et la Tâche 6 (propriété du pilote). Si l’un ou l’autre est incorrect, corrigez‑le avant de toucher autre chose.
• Alignez la VM selon la Tâche 11 (OVMF/Q35/vga none) et retestez.
• Reproduisez le comportement de reset avec la Tâche 17 et décidez si vous êtes en « mode atténuation reset ».