Passage en passthrough d’un contrôleur USB réellement stable (IOMMU + réacheminement des interruptions)
février 28, 2026 • février 28, 2026 • Lecture : 30 min • Views: 1
Cet article vous a aidé ?
Vous avez passé en passthrough un contrôleur USB entier parce que vous en avez assez que le « passthrough d’un périphérique USB » foire à la moindre secousse du périphérique.
Ça marche une journée. Puis la VM perd le clavier, la clé disparaît, ou l’hôte enregistre une pluie de resets comme s’il exorcisait un démon.
Un passthrough de contrôleur USB stable n’est pas une question de chance. Il s’agit de correction de l’IOMMU, de réacheminement des interruptions,
d’une isolation propre, et du refus d’être trop malin aux mauvais endroits. Rendons ça ennuyeux — et donc fiable.
Ce que « stable » signifie réellement pour le passthrough USB
« Stable » ne veut pas dire « ça a démarré une fois ». Stable, c’est :
Pas de déconnexions surprises lors de la ré-énumération du périphérique (fréquent pour interfaces audio, lecteurs de cartes à puce, SDR, clés HID).
Pas de blocages de l’hôte quand l’invité réinitialise le contrôleur ou qu’un périphérique se comporte mal.
Latence prévisible sans à-coups périodiques dus à des tempêtes d’interruptions ou à des conflits de pilotes côté hôte.
Suspend/reprise et redémarrages invités survivables sans laisser le contrôleur bloqué jusqu’au redémarrage de l’hôte.
Propriété claire : soit l’hôte possède le contrôleur, soit l’invité le possède. Pas « parfois les deux ».
Le passthrough de contrôleur USB, c’est du « passthrough de périphérique PCIe avec des moyens supplémentaires de défaillance. »
Les contrôleurs réinitialisent, les endpoints renégocient, les concentrateurs mentent, et les siliciums bas de gamme interprètent le spec de façon créative. Si vous traitez le passthrough USB comme une case à cocher,
vous obtiendrez une fiabilité de case à cocher.
Blague n°1 : USB veut dire « Usually Sorta Behaves » — jusqu’à ce que vous essayiez de le virtualiser.
Faits et historique intéressants à connaître
USB 1.1 utilisait OHCI/UHCI pour les contrôleurs hôtes ; USB 2.0 s’est standardisé sur EHCI avec des contrôleurs compagnons pour les périphériques low/full-speed.
xHCI (USB 3.x) a unifié le bazar : un modèle de contrôleur pour low/full/high/super speed. Bien pour les OS, mais les chemins de reset et de gestion d’alimentation sont plus complexes.
Le réacheminement des interruptions est devenu indispensable dès que l’on a commencé à donner un accès direct aux VMs ; sans lui, un périphérique peut injecter des interruptions de façon non sécurisée.
VT-d (Intel) et AMD-Vi (AMD IOMMU) assurent l’isolation DMA, mais les premières générations avaient des aspérités autour d’ATS/PRI et du routage des interruptions.
MSI/MSI-X ont largement remplacé INTx pour les périphériques PCIe modernes ; c’est une bonne nouvelle pour le passthrough, mais seulement si le réacheminement fonctionne et est sain.
ACS (Access Control Services) sur les switchs/ports racine PCIe influence la séparation des groupes IOMMU ; les plateformes grand public coupent souvent des coins ici.
Les contrôleurs USB peuvent partager du silicium avec d’autres fonctions (SATA, Ethernet, audio), créant des groupes IOMMU multifonctions difficiles à passer en passthrough proprement.
« Passthrough d’un périphérique USB » et « passthrough d’un contrôleur USB » sont des univers différents : l’un émule/proxifie, l’autre transfère la propriété matérielle réelle.
L’architecture réelle : IOMMU, DMA, interruptions, et pourquoi l’USB est spécial
Le passthrough d’un contrôleur USB est une histoire de DMA et d’interruptions
Quand vous passez en passthrough un contrôleur PCIe USB (xHCI/EHCI), vous confiez un périphérique capable de DMA à un invité. Le pilote invité
programme le contrôleur avec des adresses physiques (les « physiques » de l’invité, traduites par l’hyperviseur/IOMMU), et le contrôleur
DMA des données dans la mémoire invitée. C’est tout l’intérêt : retirer l’hôte du chemin de données.
Cela fonctionne quand deux choses sont vraies :
L’isolation DMA est correcte. Le contrôleur doit n’atteindre que la mémoire de l’invité, pas celle de l’hôte, et les traductions ne doivent pas provoquer de fautes sous charge.
La livraison des interruptions est correcte. Les interruptions du contrôleur doivent atteindre l’invité de façon fiable, sans se « bloquer », être mal routées, ou causer des tempêtes sur l’hôte.
Où ça casse en pratique
L’instabilité vient généralement d’une (ou d’une combinaison) de ces causes :
Pas de réacheminement des interruptions (ou il est désactivé/buggé), conduisant à une livraison MSI non sûre ou instable en passthrough.
Contamination du groupe IOMMU : le contrôleur partage un groupe avec quelque chose que l’hôte doit garder (ou que l’invité ne devrait pas obtenir).
Gestion d’alimentation : ASPM, runtime PM et l’autosuspend USB interagissent mal avec le passthrough, surtout sur les cartes grand public.
Sémantique de reset : certains contrôleurs xHCI ne réinitialisent pas proprement via FLR (Function Level Reset) et peuvent se bloquer jusqu’à un cycle d’alimentation complet.
Quirks du noyau et prise en main du pilote : l’hôte prend le contrôleur tôt (xhci_hcd), puis VFIO tente de le binder plus tard ; les résultats vont de correct à instable.
Paramètres du firmware/BIOS : IOMMU activé mais « réacheminement des interruptions » désactivé ; ou « Above 4G decoding » désactivé ; ou tables de routage PCIe cassées.
Ce à quoi vous devez aspirer
Une configuration stable présente ces propriétés :
Le contrôleur USB est seul dans son groupe IOMMU (ou groupé uniquement avec des frères inoffensifs que vous pouvez passer ensemble).
L’hôte ne charge jamais son pilote normal pour ce contrôleur ; VFIO le possède dès le démarrage.
L’IOMMU est activé et fonctionne dans un mode qui supporte la translation DMA à grande échelle (sans fallback).
Le réacheminement des interruptions est activé et confirmé dans les logs du noyau.
MSI/MSI-X est utilisé (contrôleurs modernes), et INTx legacy est évité sauf si vous savez pourquoi vous le faites.
Une idée paraphrasée que les opérations apprennent souvent à la dure : paraphrasé : « L’espoir n’est pas une stratégie. » — souvent attribuée à plusieurs leaders fiabilité ; le point reste valable.
Réacheminement des interruptions : le héros discret
Le réacheminement des interruptions est la partie que beaucoup de guides traitent comme une garniture optionnelle. Ce n’est pas optionnel quand vous tenez à la stabilité.
Dans l’univers VFIO, « ça marche » parfois sans lui, jusqu’à ce que vous montiez en charge d’interruptions, saturiez l’I/O, ou touchiez un cas limite périphérique/firmware.
Ce que fait réellement le réacheminement des interruptions
Avec PCIe, les périphériques utilisent typiquement des interruptions MSI/MSI-X : des écritures à une paire adresse/donnée spécifique que la plateforme interprète comme une interruption.
Sans réacheminement, ces écritures peuvent être mal contraintes. Avec le réacheminement, l’IOMMU/le remappeur d’interruptions fournit une couche de traduction permettant
à l’hyperviseur de router de façon sûre et fiable les interruptions du périphérique vers le vecteur/CPU invité correct.
Modes de défaillance que vous verrez quand le réacheminement est absent ou cassé
Perte aléatoire de périphériques quand la charge change (craquements audio, lag HID, resets de clé).
« Blocages » côté invité où le périphérique est vivant mais les interruptions cessent d’arriver, le pilote expire.
dmesg de l’hôte montre des fautes IOMMU ou des symptômes du type « IRQ bloquée ».
VFIO refuse de démarrer la VM avec des avertissements sur des interruptions non sûres, selon les réglages du noyau.
La conclusion : si votre plateforme ne fait pas correctement le réacheminement des interruptions, arrêtez d’essayer de la convaincre. Changez de plateforme ou isolez la charge.
Vous dépenserez moins en argent que ce que vous perdrez en temps.
Choix matériels qui décident de votre destin
Choisissez des contrôleurs connus pour bien se comporter
Si vous pouvez choisir le contrôleur USB, prenez-en un réputé pour un comportement de reset propre et une livraison MSI stable.
Sur le terrain, les cartes PCIe USB discrètes sont souvent plus simples que les contrôleurs intégrés : elles
sont plus susceptibles d’être isolées dans leur propre groupe IOMMU et de ne pas partager de lanes/fonctions.
Également : évitez de passer en passthrough le seul contrôleur USB de la plateforme si l’hôte en a besoin pour un accès console d’urgence.
Donnez à l’hôte son propre chemin USB « ennuyeux » (même un contrôleur USB2 basique) et passez un contrôleur xHCI séparé au VM.
Le firmware de la carte mère compte plus que vous ne le voudriez
Deux cartes avec le même chipset peuvent se comporter très différemment selon les réglages BIOS et la qualité des tables ACPI/PCIe du vendeur.
Cherchez spécifiquement :
Intel VT-d / AMD IOMMU activé.
Réacheminement des interruptions activé (parfois appelé « IRQ remapping » ou regroupé sous VT-d).
Above 4G decoding activé sur les systèmes avec beaucoup de périphériques PCIe.
SR-IOV n’a pas d’impact direct pour l’USB, mais les cartes qui l’exposent sont souvent moins « jouets ».
CSM/boot legacy désactivé si possible ; UEFI-only tend à être plus propre pour la virtualisation moderne.
N’utilisez pas l’« ACS override » pour contourner la physique sauf si nécessaire
ACS override peut fractionner les groupes IOMMU en logiciel en prétendant que des fonctionnalités ACS existent là où elles n’y sont pas.
C’est tentant. C’est aussi augmenter le rayon d’impact si un périphérique se comporte mal, car l’isolation devient alors aspirative.
Si c’est un système de type production, évitez ACS override sauf si vous avez accepté le risque et que vous supportez les conséquences.
Blague n°2 : Activer ACS override pour « réparer » des groupes, c’est comme étiqueter un carton « sûr » et l’appeler un coffre ignifuge.
Tâches pratiques : commandes, sorties attendues et décisions
Voici les tâches que j’exécute réellement quand quelqu’un dit : « Le passthrough USB est instable. » Chaque tâche inclut :
une commande, ce que signifie la sortie, et la décision que vous en tirez.
Task 1: Confirm IOMMU is enabled in the kernel command line
Signification : Vous voulez voir intel_iommu=on (Intel) ou amd_iommu=on (AMD). iommu=pt est courant pour réduire l’overhead pour les périphériques hôtes en utilisant des mappings pass-through.
Décision : Si les flags IOMMU ne sont pas présents, ajoutez-les dans votre chargeur de démarrage et redémarrez. Pas d’IOMMU, pas de passthrough fiable.
Task 2: Verify the IOMMU actually initialized (don’t trust the cmdline)
Signification : La ligne clé est « IOMMU enabled » et « Interrupt remapping enabled. » Sur AMD vous verrez des messages AMD-Vi/IOMMU.
Décision : Si vous ne voyez pas le réacheminement des interruptions activé, allez dans le BIOS/UEFI et corrigez-le. Si la plateforme ne peut pas, considérez cela comme un stop catégorique pour la stabilité.
Task 3: Check for “no interrupt remapping” or “unsafe interrupts” warnings
Signification : « No interrupt remapping support » est le signe rouge. La ligne VFIO est un bruit normal.
Décision : Si la plateforme manque de réacheminement, vous pouvez parfois tirer sur la corde, mais attendez-vous à des problèmes sporadiques. En production, remplacez le matériel.
Task 4: Identify the USB controller’s PCI address and vendor/device ID
cr0x@server:~$ lspci -nn | egrep -i 'usb|xhci|ehci'
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
00:14.0 USB controller [0c03]: Intel Corporation 200 Series PCH USB 3.0 xHCI Controller [8086:a2af]
Signification : Vous avez maintenant le BDF (03:00.0) et l’ID (1b21:2142).
Décision : Préférez passer une carte discrète (03:00.0) plutôt que celle intégrée au chipset (00:14.0).
Task 5: Check IOMMU group isolation
cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename "$g")"; ls -l "$g/devices"; done | sed -n '1,40p'
Group 13
total 0
lrwxrwxrwx 1 root root 0 Feb 4 09:12 0000:03:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:03:00.0
Group 7
total 0
lrwxrwxrwx 1 root root 0 Feb 4 09:12 0000:00:14.0 -> ../../../../devices/pci0000:00/0000:00:14.0
lrwxrwxrwx 1 root root 0 Feb 4 09:12 0000:00:14.2 -> ../../../../devices/pci0000:00/0000:00:14.2
Signification : Le groupe 13 contient seulement 03:00.0 — bien. Le groupe 7 contient 00:14.0 et 00:14.2 — fonctions partagées.
Décision : Passez des périphériques isolés, ou passez tout le groupe. Ne prenez pas chirurgicalement une fonction d’un groupe multifonction.
Task 6: See what driver currently owns the controller
cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Subsystem: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
Signification : Le pilote hôte (xhci_hcd) le possède actuellement. Ce n’est pas ce que l’on veut pour le passthrough.
Décision : Liezz ce périphérique à vfio-pci tôt, avant que xHCI ne le prenne, ou détachez/rattachez soigneusement à la volée.
Task 7: Bind the controller to vfio-pci (runtime method)
Signification : Nous nous sommes désolidarisés du pilote courant et avons demandé à vfio-pci de réclamer cet ID vendor/device.
Décision : Si le périphérique refuse de se détacher, il peut être utilisé par l’hôte (système racine sur USB, clavier console, etc.). Corrigez d’abord la dépendance.
Task 8: Confirm vfio-pci is now in use
cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Subsystem: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Kernel driver in use: vfio-pci
Kernel modules: xhci_pci
Signification : Correct. L’hôte ne le pilote plus.
Décision : Procédez à l’attachement à la VM. Si au reboot il retourne à xHCI, implémentez un binding persistant.
Task 9: Make vfio-pci binding persistent with modprobe config
Signification : L’initramfs inclura maintenant le binding afin que vfio-pci récupère le contrôleur tôt.
Décision : Redémarrez et confirmez que vfio-pci reste le pilote. Le binding précoce prévient les courses au démarrage et les bizarreries « ça marche sauf si… ».
Task 10: Confirm interrupt mode (MSI/MSI-X) for the passed-through controller
Signification : Tant que le périphérique est géré par l’hôte, il utilise « IR-PCI-MSI » (MSI remappé). Une fois lié à vfio-pci, il devrait disparaître des interruptions de l’hôte.
Décision : Si vous ne voyez que des lignes INTx legacy ou pas de « IR- » sur des plateformes qui devraient le supporter, suspectez un réacheminement manquant ou un firmware étrange.
Task 11: Validate VFIO/IOMMU mapping health under load (look for faults)
Signification : Faille DMA. Ce n’est pas « sans conséquence. » Le contrôleur a tenté un DMA vers un endroit que l’IOMMU n’a pas mappé.
Décision : Si les fautes n’apparaissent que sous charge, suspectez du matériel buggué, un quirk de plateforme IOMMU, ou un pilote invité qui fait quelque chose que le contrôleur/firmware gère mal.
Essayez un autre contrôleur, mettez à jour le BIOS, mettez à jour le noyau, et désactivez des fonctionnalités PCIe suspectes (voir tâches ultérieures).
Task 12: Check for PCIe Advanced Error Reporting (AER) spew
Signification : Les erreurs corrigées ne sont pas fatalement instantanées, mais elles corrèlent très bien avec les resets aléatoires et les événements « USB disparu ».
Décision : Reseat la carte, changez de slot, forcez Gen3 au lieu de « Auto », désactivez l’ASPM agressif, ou remplacez le matériel douteux.
Task 13: Inspect power management settings that commonly break USB passthrough
Signification : ASPM est en « default. » Certaines plateformes se comportent. D’autres inventent de nouveaux modes de défaillance.
Décision : Si vous voyez des liens qui flappent ou des AER autour du contrôleur passé, pensez à démarrer avec pcie_aspm=off comme test.
Si la stabilité s’améliore, vous avez trouvé un bug de gestion d’alimentation, pas un bug de virtualisation.
Task 14: Confirm the VM sees the controller and uses a real driver
cr0x@server:~$ sudo virsh domiflist win11
Interface Type Source Model MAC
-------------------------------------------------------
vnet0 bridge br0 virtio 52:54:00:aa:bb:cc
Signification : La config VM inclut le périphérique passé.
Décision : Si l’invité ne peut pas installer/utiliser le contrôleur xHCI, vous pouvez manquer des réglages UEFI, ou le périphérique n’est pas réellement lié à vfio-pci sur l’hôte.
Task 15: Check for reset problems (FLR/D3cold) after guest reboot
cr0x@server:~$ sudo dmesg | egrep -i 'reset|flr|D3cold|vfio-pci 0000:03:00.0' | tail -n 30
[ 1322.333444] vfio-pci 0000:03:00.0: not ready 1023ms after FLR; waiting
[ 1323.444555] vfio-pci 0000:03:00.0: not ready 2047ms after FLR; giving up
Signification : Le périphérique n’est pas revenu proprement du reset. Classique « ça marche jusqu’au reboot de la VM. »
Décision : Essayez un autre modèle de contrôleur USB, mettez à jour le BIOS, et évitez l’économie d’énergie runtime PCIe. Certains contrôleurs ne réinitialisent pas fiablement en passthrough.
Task 16: Confirm IOMMU mode and domain type (performance vs safety tradeoffs)
Signification : L’hôte utilise des mappings passthrough par défaut ; les périphériques VFIO obtiennent toujours des domaines isolés.
Décision : Si vous déboguez des fautes DMA étranges, retirez temporairement iommu=pt pour tester si la translation complète change le comportement. Pas une solution permanente, juste un levier diagnostic.
Playbook de diagnostic rapide (vérifier premièrement/deuxièmement/troisièmement)
Quand le passthrough d’un contrôleur USB est instable, vous voulez identifier le goulot rapidement : capacité de la plateforme, isolation, comportement de reset,
ou quelque chose d’aussi banal qu’un slot défaillant.
Premièrement : « Cette plateforme peut-elle faire des interruptions sûres ? »
Vérifiez dmesg pour « Interrupt remapping enabled. » Si ce n’est pas là, ne perdez pas une semaine à peaufiner.
Vérifiez si le contrôleur utilise MSI/MSI-X sous le pilote hôte (avant que VFIO ne le prenne). Si vous êtes coincé en INTx legacy, attendez-vous à des ennuis.
Cherchez des avertissements VFIO au sujet d’interruptions non sûres.
Deuxièmement : « L’isolation est-elle réelle, ou est-ce que je me bats contre la physique des groupes IOMMU ? »
Listez les groupes IOMMU. Si le contrôleur USB est collé à d’autres périphériques que vous ne pouvez pas passer, vos choix sont : autre slot, autre contrôleur, autre carte mère.
Évitez ACS override comme solution première. Utilisez-le seulement quand le risque est acceptable et que vous pouvez tester à fond.
Troisièmement : « Est-ce qu’il se réinitialise proprement ? »
Redémarrez l’invité à plusieurs reprises et surveillez les timeouts FLR, les messages « device not ready », ou la disparition du contrôleur de l’espace de configuration PCI.
Si ça se bloque après un seul redémarrage invité, c’est souvent un comportement du silicium/firmware du contrôleur. Échangez le contrôleur avant de réécrire votre pile.
Quatrièmement : « Est-ce un problème de lien/énergie déguisé ? »
Recherchez des erreurs AER corrigées autour du port racine du contrôleur.
Testez avec ASPM désactivé et la génération PCIe forcée (Gen3/Gen4) plutôt que Auto.
Déplacez la carte dans un autre slot et retestez. Oui, vraiment. Les slots peuvent être capricieux, la bifurcation étrange, et le port racine compte.
Cinquièmement : « La charge déclenche-t-elle un cas limite USB réel ? »
Interfaces audio : surveillez les transferts isochrones et des comportements périodiques type XRUN. C’est souvent la livraison d’interruptions ou l’ordonnancement.
Clés HID : cherchez des dips d’alimentation brefs ou des boucles de ré-énumération ; cela vient souvent de la gestion d’alimentation et des resets.
Stockage haute-bande passante : vérifiez si le contrôleur partage des lanes ou est restreint ; le stockage USB3 peut générer des patterns d’interruptions brutaux.
Trois mini-récits d’entreprise depuis le terrain
1) L’incident causé par une mauvaise hypothèse : « IOMMU est activé, donc on est safe »
Une entreprise de taille moyenne faisait tourner des VMs Windows pour quelques workflows liés au matériel : clés de licence, appareils de mesure, lecteur de carte à puce.
Ils avaient appris que le passthrough par périphérique USB était instable, alors ils se sont standardisés sur le passthrough d’un contrôleur USB dédié.
Le déploiement semblait propre en laboratoire. Puis des utilisateurs en production ont commencé à signaler que la clé « tombe » toutes les quelques heures.
L’équipe virtualisation a fait ce que font les équipes : blâmer Windows, blâmer QEMU, blâmer les rayons cosmiques. Ils ont changé les clés. Ils ont remplacé les hubs.
Ils ont même épinglé des vCPU. Le problème a persisté et avait un motif étrange : cela arrivait plus souvent aux heures de pointe, quand les hôtes
étaient plus occupés et que les VMs avaient plus d’interruptions en vol.
La mauvaise hypothèse était subtile : ils avaient confirmé intel_iommu=on et voyaient des logs DMAR, donc ils ont conclu que la plateforme était « IOMMU capable. »
Ce qu’ils n’avaient pas vérifié, c’était le réacheminement des interruptions. Le BIOS avait VT-d activé mais un toggle additionnel « Interrupt Remapping » était désactivé par défaut
après une mise à jour de firmware. Le noyau leur l’avait poliment indiqué, mais personne ne cherchait cette ligne précise.
Une fois le réacheminement activé, les coupures mystérieuses ont cessé. La résolution a paru anticlimatique, ce que font souvent les bons correctifs.
La note de post-mortem importante : « IOMMU activé » n’est pas un état binaire. La translation DMA et le réacheminement des interruptions sont des piliers séparés.
En retirer un, et vous êtes en équilibre sur des on-dit.
2) L’optimisation qui s’est retournée contre eux : « On va économiser un slot PCIe et partager le contrôleur onboard »
Une autre organisation standardisait sur des serveurs compacts avec peu de slots PCIe. Quelqu’un a proposé une optimisation :
au lieu d’acheter une carte contrôleur USB dédiée par hôte, ils passeraient le xHCI onboard et garderaient les besoins USB de l’hôte minimaux.
Sur le papier, ça économisait des slots et réduisait le coût. En réalité, ça rendait l’hôte fragile.
Le contrôleur onboard se trouvait dans un groupe IOMMU avec une autre fonction plateforme. Parfois un périphérique compagnon ; parfois un sous-système chipset que l’hôte nécessitait pour fonctionner.
Ils ont forcé la chose avec des astuces de split de groupe. Ça a marché — jusqu’à ce que ça ne marche plus.
Un reboot invité a déclenché un reset du contrôleur que l’hôte a interprété au mauvais moment, et soudain l’hôte a perdu son seul clavier USB local
et quelques périphériques internes. Il a fallu des interventions sur place. Les opérations adorent ça.
La tentative suivante a été « d’optimiser » les interruptions et l’énergie : activer des C-states profonds et un ASPM agressif parce que les systèmes étaient « principalement inactifs. »
Ça a rendu le problème intermittent et donc plus coûteux. La VM était stable en journée, instable la nuit, et les logs paraissaient innocents.
Finalement, des logs AER et des changements d’état de lien ont lié l’instabilité à la gestion d’alimentation interagissant avec le chemin de reset du contrôleur.
Ils ont annulé l’optimisation : cartes contrôleur USB dédiées, l’hôte conserve l’USB onboard, réglages PCIe conservateurs.
Ça a coûté plus cher. Ça a aussi supprimé toute une catégorie de pannes. C’est le type de ROI dont personne ne se vante en slides, mais que tout le monde apprécie à 3h du matin.
3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Validation pré-vol et chemin de secours connu »
Une équipe de services financiers avait une politique qui semblait excessivement prudente : chaque nouveau build d’hôte devait passer une checklist de « validation passthrough »
avant d’entrer dans le cluster de virtualisation. Elle incluait vérifier le réacheminement des interruptions, contrôler les groupes IOMMU, lancer une boucle de reboot invité,
et brancher/débrancher intentionnellement des périphériques derrière le contrôleur passé tout en collectant les logs.
Lors d’un cycle d’achat, ils ont reçu une série de serveurs avec une révision de carte mère légèrement différente. La fiche technique semblait identique.
Les écrans BIOS semblaient presque identiques. Mais les groupes IOMMU étaient différents : le contrôleur USB onboard était maintenant groupé avec un autre périphérique
à cause d’un changement de routage. La génération précédente avait une isolation propre ; celle-ci non.
Parce que la validation était obligatoire, le problème a été détecté avant que les serveurs n’atteignent les charges de production.
Ils ont ajusté le design : les hôtes utilisent une carte contrôleur USB discrète connue pour le passthrough, et le contrôleur onboard reste avec l’hôte.
La « pratique ennuyeuse » n’était pas héroïque — c’était refuser d’accepter « presque le même matériel » comme étant la même plateforme.
Le meilleur : quand un cadre a demandé pourquoi la date de mise en service n’a pas été retardée, la réponse honnête a été « parce qu’on a fait les tests fastidieux qu’on fait toujours. »
Personne n’a applaudi. Les systèmes sont restés en marche. C’est l’applaudissement que vous voulez réellement.
Erreurs courantes : symptôme → cause racine → correction
1) La VM perd aléatoirement les périphériques USB derrière le contrôleur passé
Symptôme : Périphériques HID/audio/stockage se déconnectent et reconnectent ; logs invités montrent des resets ; logs hôte plutôt propres.
Cause racine : Réacheminement des interruptions désactivé ou cassé, entraînant une livraison MSI instable sous charge.
Correction : Activez le réacheminement des interruptions dans le BIOS/UEFI, confirmez dans dmesg. Si non supporté, changez de plateforme.
2) L’hôte se fige ou devient lent quand l’invité redémarre
Symptôme : Le redémarrage de l’invité provoque un blocage de l’hôte ; parfois seulement des stalls I/O ; parfois blocage total nécessitant cycle d’alimentation.
Cause racine : Le comportement de reset du contrôleur interagit avec le pilote hôte ou le chipset ; l’hôte possède encore des fonctions liées ou partage des ressources dans le groupe.
Correction : Assurez-vous que vfio-pci se lie tôt ; évitez de passer un périphérique dans un groupe IOMMU partagé ; utilisez un contrôleur discret ; mettez à jour le BIOS.
3) VFIO refuse de démarrer la VM ou se plaint d’interruptions non sûres
Symptôme : La VM échoue au démarrage ; erreurs mentionnant le mapping des interruptions ou « no interrupt remapping support. »
Cause racine : La plateforme manque ou a désactivé le réacheminement des interruptions ; parfois les réglages du noyau appliquent la sécurité.
Correction : Activez le réacheminement ; si impossible, n’utilisez pas le passthrough du contrôleur pour cette charge (ou acceptez une sécurité réduite en connaissance de cause).
4) Ça marche jusqu’à ce que vous redémarriez la VM ; ensuite le contrôleur ne revient jamais
Symptôme : Premier démarrage OK ; après redémarrage invité, démarrage suivant échoue ou périphérique manquant ; dmesg montre timeouts FLR.
Cause racine : Le contrôleur ne peut pas effectuer une FLR de façon fiable ; bloqué dans un état basse consommation (D3cold), ou bug firmware.
Correction : Changez le modèle de contrôleur ; essayez un autre slot ; désactivez la gestion d’alimentation runtime PCIe ; parfois seul un redémarrage de l’hôte/le cycle d’alimentation le remettra.
5) Audio USB craque ou a des coupures périodiques dans l’invité
Symptôme : Pops audio toutes les quelques secondes ; l’interface USB reste connectée mais les performances sont mauvaises.
Cause racine : Latence de gestion des interruptions : ordonnancement vCPU, états d’énergie CPU hôte, ou problèmes de réacheminement/affinité des interruptions.
Correction : Épinglez les vCPUs, isolez des CPU hôte pour charges à faible latence, évitez les C-states profonds, et vérifiez MSI avec réacheminement. Envisagez un contrôleur dédié par VM.
6) Le contrôleur partage un groupe IOMMU avec SATA/NIC/autres périphériques critiques
Symptôme : Vous ne pouvez pas passer sans aussi perdre quelque chose que l’hôte nécessite.
Cause racine : La plateforme manque de séparation ACS ; la disposition de la carte lie des fonctions derrière le même upstream port.
Correction : Utilisez un autre slot PCIe ou une carte discrète ; choisissez une carte mère avec meilleure séparation IOMMU ; évitez ACS override en production.
7) Tout a l’air correct, mais les performances sont incohérentes
Symptôme : Débits en dents de scie ; pics de latence aléatoires ; stockage USB parfois bloqué.
Cause racine : Problèmes de lien PCIe (AER corrected errors), câbles marginaux, ou problèmes d’alimentation pour périphériques USB à forte consommation.
Correction : Vérifiez les logs AER, désactivez ASPM, testez avec un hub alimenté propre, remplacez la carte PCIe, et n’utilisez pas le câblage d’en-tête avant pour des périphériques critiques.
Listes de vérification / plan étape par étape
Étape par étape : construire une configuration de passthrough contrôleur USB stable
Choisir le contrôleur : préférez une carte PCIe xHCI discrète qui arrive dans son propre groupe IOMMU.
Configuration firmware : activez VT-d/AMD IOMMU et le réacheminement des interruptions ; activez Above 4G decoding si vous avez plusieurs périphériques PCIe.
Cmdline du noyau : mettez intel_iommu=on ou amd_iommu=on. Optionnellement iommu=pt une fois stable.
Vérifier dans dmesg : confirmer IOMMU et réacheminement des interruptions activés. Si non, arrêtez et corrigez.
Vérifier les groupes IOMMU : assurer que le contrôleur peut être isolé ou passé en tant que groupe complet.
Lier à vfio-pci tôt : utilisez /etc/modprobe.d/vfio.conf et rebuild initramfs. Évitez le rebinding à la volée comme configuration permanente.
Attacher à la VM : utilisez libvirt hostdev ou l’équivalent de votre plateforme. Restez simple : un contrôleur, une VM, un job.
Test de stabilité : boucle de reboot invité, unplug/replug des périphériques derrière le contrôleur, et charge soutenue (copie stockage USB, flux audio, etc.).
Surveiller les logs : vérifiez DMAR/IOMMU faults, erreurs AER, et timeouts FLR.
Verrouiller les fonctionnalités d’alimentation : si vous voyez des erreurs de lien ou des resets étranges, désactivez ASPM et évitez les états d’énergie profonds. Retestez ensuite.
Checklist opérationnelle : ce que vous conservez après que ça marche
Enregistrez le BDF et l’ID vendor/device du périphérique passé dans votre gestion de configuration.
Conservez un chemin USB accessible depuis l’hôte pour les récupérations d’urgence (média virtuel IPMI, USB onboard dédié, ou contrôleur séparé).
Après mises à jour du BIOS, reverifiez le réacheminement des interruptions et les groupes IOMMU. Les firmwares aiment « revenir aux valeurs par défaut ».
Maintenez une version noyau connue-good pour les charges VFIO ; mettez à jour volontairement avec validation, pas « parce qu’on est mardi ».
Alertez sur les DMAR/IOMMU faults et les tempêtes AER ; ce sont des signaux précoces, pas des futilités.
FAQ
Ai-je vraiment besoin du réacheminement des interruptions pour le passthrough contrôleur USB ?
Si vous voulez de la stabilité, oui. L’isolation DMA seule ne garantit pas une livraison d’interruptions fiable. Sans réacheminement, vous pouvez obtenir un comportement « ça marche jusqu’à la charge »
qui vous fera perdre des jours en débogage.
Pourquoi ne pas simplement passer des périphériques USB individuels au lieu du contrôleur ?
Parce que le passthrough d’un périphérique USB individuel proxifie typiquement les transactions USB via l’hôte. Ça peut suffire pour une souris.
C’est souvent catastrophique pour des périphériques qui resetent, streament de l’audio isochrone, ou font des danses d’énumération étranges.
Le passthrough du contrôleur donne à l’invité le vrai matériel et retire l’hôte du datapath.
Est-ce que iommu=pt est bon ou mauvais ?
C’est généralement acceptable et souvent recommandé pour les performances de l’hôte parce que les périphériques non-VFIO obtiennent des mappings identités.
Pour déboguer des fautes de translation étranges, retirez-le temporairement pour voir si le comportement change. Ne le considérez pas comme une solution miracle.
Mon contrôleur USB est dans le même groupe IOMMU que d’autres périphériques. Et maintenant ?
La meilleure réponse : changez de slot PCIe, utilisez une carte contrôleur différente, ou une carte mère avec une meilleure séparation ACS/IOMMU.
Passer des groupes partiels demande l’instabilité. ACS override peut fonctionner, mais c’est un arbitrage de risque, pas un repas gratuit.
Pourquoi le contrôleur disparaît après le reboot de l’invité ?
Comportement de reset. Certains contrôleurs n’implémentent pas correctement la FLR, ou ils restent bloqués dans un état basse consommation.
Si vous voyez « vfio-pci not ready after FLR », arrêtez de penser que c’est un bug logiciel et essayez un autre matériel.
Dois-je désactiver ASPM et l’économie d’énergie ?
Si vous voyez des erreurs AER, des flaps de lien, ou des resets étranges : oui, comme test et souvent comme choix permanent pour des hôtes sensibles à la latence ou chargés en passthrough.
Les économies d’énergie sont agréables ; des interruptions stables le sont davantage.
Puis-je passer le contrôleur USB chipset (onboard) en toute sécurité ?
Parfois. Mais c’est le plus susceptible d’être groupé avec d’autres fonctions plateforme et le plus susceptible d’être nécessaire à l’hôte.
Pour des opérations fiables, une carte contrôleur discrète dédiée à l’invité est la conception propre.
Quelle est la différence entre MSI et INTx pour le passthrough ?
MSI/MSI-X sont des interruptions basées sur messages et sont le défaut moderne. INTx sont des lignes d’interruption partagées legacy et peuvent être plus problématiques en virtualisation.
Vous voulez en général MSI/MSI-X avec réacheminement des interruptions activé.
Ma VM démarre, mais le contrôleur USB affiche des erreurs dans le pilote invité. Est-ce un problème hôte ?
Pas forcément. Ça peut être un problème de pilote invité, mais commencez par vérifier dmesg de l’hôte pour les DMAR faults, timeouts FLR et erreurs AER.
Si l’hôte est propre, alors regardez les logs et versions du pilote invité.
Est-ce qu’un contrôleur USB par VM est nécessaire ?
Pour des configurations hautement stables, oui. Partager un contrôleur entre plusieurs invités n’est pas typique car une seule fonction PCIe physique ne peut pas être possédée de façon sûre par plusieurs OS en même temps.
Si vous avez besoin de plusieurs domaines USB isolés, ajoutez plus de contrôleurs.
Étapes suivantes que vous pouvez faire aujourd’hui
Ouvrez le dmesg de votre hôte et confirmez « Interrupt remapping enabled. » Si c’est absent, corrigez d’abord les réglages firmware.
Choisissez la bonne cible contrôleur USB : carte discrète, groupe IOMMU isolé, pas la ligne vitale de l’hôte.
Liez-la à vfio-pci tôt via config modprobe + initramfs, pas avec des rebindings ad-hoc après le démarrage.
Lancez le test reboot-et-charge : redémarrages invités répétés plus trafic USB soutenu tout en surveillant DMAR faults, timeouts FLR et erreurs AER.
Si ça flanche toujours, arrêtez de tourner les boutons et changez le contrôleur ou la plateforme. Certaines combinaisons sont simplement de mauvaises unions.
L’objectif n’est pas de faire « fonctionner » le passthrough USB. L’objectif est de le rendre prévisible. Les systèmes prévisibles sont ceux que vous pouvez exploiter sans
développer une relation personnelle avec vos logs.