ACS Override sur Proxmox : le raccourci qui peut coûter la stabilité (faites plutôt ceci)

février 21, 2026 • février 21, 2026 • Lecture : 31 min • Views: 1

Cet article vous a aidé ?

Vous l’avez fait. Vous avez activé le passthrough PCIe sur Proxmox, regardé des groupes IOMMU qui ressemblaient à un tiroir à bazar,
et quelqu’un sur un forum a prononcé les mots magiques : « ACS override ». Un redémarrage plus tard votre GPU apparaît enfin dans la VM.
Vous vous sentez malin. Vous allez vous coucher.

Et puis l’hôte commence à se comporter comme hanté : gel intermittent des VM, timeouts NVMe, redémarrages spontanés sous charge,
ou cette petite fuite d’erreurs PCIe « corrigées » qui se transforme en panne un vendredi. L’ACS override n’a pas « réparé » votre plateforme.
Il a dit au noyau de faire comme si votre matériel était plus isolé qu’il ne l’est réellement. Parfois ça passe. Parfois c’est un piège.

Ce que fait réellement l’ACS override (et ce qu’il ne fait pas)

Dans l’univers PCIe, vous ne « passez pas un périphérique » tant que vous n’avez pas convaincu l’hôte d’arrêter d’y toucher, puis donné la
propriété directe à une VM via VFIO. La sécurité et la stabilité de cet arrangement dépendent des limites d’isolation fournies par la plateforme :
groupes IOMMU, capacités ACS, remappage des interruptions, comportement de reset, et la topologie PCIe elle-même.

ACS (Access Control Services) est un ensemble de fonctionnalités PCIe qui peuvent faire respecter la manière dont les transactions sont routées et empêcher
le DMA pair-à-pair là où il ne devrait pas se produire. En pratique, ACS explique en grande partie pourquoi des périphériques finissent dans des groupes IOMMU séparés.
Si ACS n’est pas présent (ou n’est pas activé) sur un chemin descendant donné, le noyau peut devoir supposer que les périphériques derrière le même bridge PCIe
peuvent communiquer entre eux. Cette hypothèse les force à être dans le même groupe IOMMU.

L’option Linux « ACS override » n’est pas votre carte mère qui apprend soudainement de nouvelles capacités. C’est un paramètre du noyau qui peut
diviser artificiellement les groupes IOMMU en faisant comme si l’isolation ACS existait là où le noyau ne peut pas la prouver.
C’est utile lorsque vous voulez passer un périphérique d’un groupe qui contient d’autres éléments que vous souhaitez garder sur l’hôte.

Voici la partie inconfortable : avec l’ACS override, vous pouvez créer une configuration qui paraît isolée pour VFIO et le gestionnaire de VM,
mais qui n’est pas isolée sur le bus. Si deux périphériques peuvent encore faire du DMA pair-à-pair ou partager un chemin en amont sans isolation adéquate,
vous avez construit un système qui « fonctionne » jusqu’à ce qu’il cesse de fonctionner. Vous pouvez voir des plantages, des risques de corruption de données,
ou des pathologies de performance étranges qui ne se reproduisent pas de façon déterministe.

Si vous faites cela en homelab, votre tolérance au risque peut être « acceptable ». En production — ou toute situation où vous serez tenu responsable —
traitez l’ACS override comme un outil de diagnostic temporaire, pas comme une architecture permanente.

Ce que modifie l’ACS override

Il modifie la formation des groupes. Les périphériques peuvent apparaître dans des groupes IOMMU séparés même si la plateforme n’applique pas réellement cette séparation.
Il modifie ce que Proxmox vous permet de faire. Vous pouvez attacher un seul périphérique à VFIO sans embarquer tout le groupe avec lui.

Ce que l’ACS override ne modifie pas

Il n’ajoute pas d’isolation matérielle. Si le chemin PCIe manque d’ACS, il en manque toujours.
Il ne corrige pas les resets défaillants. Les « bugs » de reset GPU et les problèmes de FLR restent.
Il ne garantit pas la sécurité du DMA. Dans le pire des cas, un périphérique passé peut encore affecter la mémoire de l’hôte ou d’autres périphériques.
Il ne résout pas les problèmes de remappage d’interruptions. Si votre plateforme ne peut pas remapper correctement les interruptions, vous pouvez toujours avoir des blocages difficiles à déboguer.

Une citation à garder en tête quand vous êtes tenté par des flags magiques vient de John Ousterhout :
« La complexité est incrémentale. » Vous remarquez rarement le premier compromis. Vous remarquerez assurément le dixième.

Pourquoi les gens utilisent l’ACS override sur Proxmox

Proxmox rend VFIO accessible. C’est bien. Mais les fabricants de matériel ne conçoivent pas les plateformes grand public pour obtenir des groupes IOMMU propres ;
ils conçoivent pour des coûts et des listes de caractéristiques marketing. Vous obtenez donc les irritations classiques :

Votre GPU est regroupé avec le contrôleur USB du chipset et le contrôleur SATA.
Vos emplacements NVMe partagent un port racine avec quelque chose dont vous avez besoin sur l’hôte.
Votre HBA se trouve derrière un bridge avec d’autres périphériques que vous ne pouvez pas passer.
Votre plateforme a l’IOMMU activé mais le remappage des interruptions est partiel ou instable.

L’ACS override semble la sortie la plus simple. Et pour beaucoup, ça « marche ». La VM démarre, le périphérique apparaît, les benchs sont bons,
et vous passez à autre chose.

Blague n°1 : l’ACS override, c’est comme utiliser du ruban adhésif pour faire une poutre structurelle. Ça tient jusqu’à ce que la gravité se rappelle à vous.

Les coûts en stabilité : modes de défaillance réels

Parlons des façons concrètes dont cela peut mal tourner. Pas du théorique « des chercheurs en sécurité pourraient… ». De la vraie douleur opérationnelle.

1) Surprises de DMA et peer-to-peer

Si deux périphériques ne sont pas réellement isolés, un périphérique passé peut atteindre la mémoire ou d’autres périphériques de manières non prévues.
Même si vous ne craignez pas un comportement malveillant, le « peer-to-peer inattendu » peut se manifester par :

Instabilité de l’hôte quand le pilote de la VM active des fonctionnalités avancées.
Timeouts de périphérique sous charge qui ressemblent à des problèmes de câblage (alors que c’est PCIe).
Comportement non déterministe quand plusieurs VM se concurrencent sur des chemins en amont partagés.

2) Remappage d’interruptions et gels « aléatoires »

Certaines plateformes supportent la traduction IOMMU mais ont un remappage d’interruptions faible ou bogué. Quand vous passez des périphériques qui génèrent beaucoup d’interruptions
(GPU, NVMe, HBA, NIC), vous pouvez obtenir des blocages de VM ou des lockups complets de l’hôte. On accuse les pilotes. Parfois le pilote est correct.
La plomberie des interruptions de la plateforme est le coupable.

3) Spam AER PCIe que vous ignorez jusqu’à ce que ça fasse mal

Advanced Error Reporting (AER) enregistre les erreurs PCIe corrigées et non corrigées. Les erreurs corrigées peuvent sembler inoffensives — jusqu’à ce que leur taux augmente et que les performances s’effondrent,
ou jusqu’à ce qu’une erreur non corrigée escalade en reset de périphérique en plein IO. L’ACS override ne cause pas les erreurs AER en soi, mais il peut vous amener à placer
des périphériques à forte charge derrière une topologie douteuse, ce qui révèle les liaisons marginales.

4) La panne « ça marchait depuis des mois »

Les pires pannes sont celles qui attendent. Une mise à jour du noyau change les timings. Une charge VM change le taux d’interruptions. Un nouveau pilote active ASPM différemment.
Soudainement votre passthrough auparavant « stable » devient une roulette russe.

5) Risque de corruption de stockage quand vous passez le mauvais périphérique

Passer un HBA peut être une excellente solution pour ZFS dans une VM — quand c’est fait sur de véritables limites d’isolation. Avec l’ACS override sur une topologie branlante,
le profil de risque change. « Mais ZFS a des checksums » n’est pas un champ de force. Les checksums vous disent que quelque chose s’est mal passé ; ils ne garantissent pas que vous pourrez
récupérer sans downtime, perte de données, ou les deux.

6) Falaise de performance : complexes racine partagés et contention cachée

La division des groupes peut vous tromper en vous faisant croire que des périphériques ont des chemins indépendants. Ils peuvent encore partager un budget de bande passante du port racine,
ou partager l’uplink d’un switch, ou partager des voies chipset avec des goulets DMI. Vous pouvez obtenir :

Des pics de latence NVMe lorsque le GPU est en charge.
Perte de paquets ou jitter sur des NIC en passthrough pendant des rafales de stockage.
Soft lockups CPU causés par des tempêtes d’interruptions quand le système ne peut pas remapper efficacement.

Faits et historique intéressants (court, utile et un peu nerd)

La sémantique des groupes IOMMU dans Linux est conservatrice par conception. Le noyau groupe les périphériques ensemble s’il ne peut pas prouver l’isolation. C’est une paranoïa intentionnelle, pas de la paresse.
ACS provient du besoin de la spec PCIe de gérer les fonctions multi et les fabrics commutés. Les serveurs avec des switches PCIe et beaucoup d’endpoints avaient besoin de fonctions d’application ; les desktops souvent s’en passent.
VT-d (Intel) et AMD-Vi (AMD IOMMU) ont mûri avec le boom de la virtualisation. Les premières implémentations existaient, mais un passthrough robuste n’est devenu courant que lorsque la virtualisation est devenue la norme.
Proxmox n’a pas inventé VFIO ; il l’a opérationnalisé. VFIO est un cadre du noyau Linux ; Proxmox est le visage amical qui pousse les gens à cliquer sur « Add PCI Device ».
Le remappage d’interruptions a été le moment « ah oui ». La traduction d’adresses seule ne suffisait pas ; l’assignation sûre de périphériques exige que les interruptions soient gérées avec la même rigueur.
Les chipsets grand public accrochent souvent des périphériques aux mêmes ports en amont. C’est pourquoi votre contrôleur USB et votre contrôleur SATA peuvent finir mariés dans le même groupe IOMMU.
Le comportement de reset des GPU a été une douleur récurrente pendant des années. Le support FLR varie, les pilotes fournisseurs varient, et le résultat est le fameux « ça marche jusqu’au reboot de la VM ».
Le logging AER est plus ancien que beaucoup ne le pensent. PCIe a depuis longtemps un moyen de vous dire que la liaison est malade ; nous sommes juste devenus très bons pour l’ignorer.
L’ACS override existe parce que les utilisateurs l’ont demandé. C’est un outil pragmatique pour le développement et les homelabs, pas un label d’approbation architecturale.

Playbook de diagnostic rapide (trouver le goulot vite)

Quand le passthrough est instable, vous pouvez perdre des jours dans le folklore des pilotes. Ne le faites pas. Commencez par la topologie et les preuves.
Voici l’ordre qui m’a fait gagner le plus de temps.

Première étape : confirmez que vous avez vraiment IOMMU + remappage d’interruptions

Vérifiez la ligne de commande du noyau pour les paramètres IOMMU AMD/Intel.
Vérifiez dmesg pour « DMAR » (Intel) ou « AMD-Vi » et pour le remappage d’interruptions activé.
Si le remappage d’interruptions manque/est désactivé, attendez-vous à des gels étranges sous charge.

Deuxième étape : inspectez les groupes IOMMU et la topologie PCIe réelle

Listez les groupes depuis /sys/kernel/iommu_groups.
Comparez avec lspci -t et lspci -vv pour voir quels périphériques partagent des bridges/ports racine.
Si l’ACS override est activé, considérez les divisions de groupe comme « logiques », pas nécessairement « physiques ».

Troisième étape : recherchez AER, reset et erreurs VFIO

Cherchez dans les logs les occurrences de AER, DPC, « BAR », « vfio », « DMAR fault », « IOMMU fault ».
Corrélez avec les horaires de charge. Si des erreurs apparaissent au démarrage/arrêt de la VM, soupçonnez un comportement de reset/FLR.

Quatrième étape : isolez les variables en ne changeant qu’une chose à la fois

Désactivez l’ACS override temporairement et vérifiez si le problème disparaît (même si ça casse votre agencement).
Déplacez le périphérique vers un autre slot/port racine si possible.
Mettre à jour le firmware/BIOS seulement après avoir capturé des logs de référence.

Cinquième étape : décidez si c’est un problème d’architecture

Si la plateforme ne peut pas fournir une isolation stable, vous ne « peaufinez » pas pour vous en sortir. Remplacez le matériel, changez le design :
NIC différente, GPU différent, slot différent, carte différente, ou pas de passthrough.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les vérifications que j’exécute réellement sur Proxmox (basé sur Debian) quand quelqu’un dit « l’ACS override a résolu le problème » et que je veux savoir ce que nous venons d’accepter.
Chaque tâche inclut : la commande, un exemple de sortie, ce que cela signifie, et la décision à prendre.

Task 1: Confirm IOMMU is enabled in the running kernel

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

Ce que cela signifie : Vous avez démarré avec AMD IOMMU activé ; iommu=pt utilise le mode passthrough pour les périphériques de l’hôte (souvent bon pour les performances).

Décision : Si vous ne voyez pas intel_iommu=on ou amd_iommu=on, corrigez cela avant de toucher à l’ACS override ou à VFIO.

Task 2: Verify IOMMU and interrupt remapping in dmesg (Intel)

cr0x@server:~$ dmesg -T | egrep -i "DMAR|IOMMU|remapping" | head -n 20
[Tue Feb  4 10:12:11 2026] DMAR: IOMMU enabled
[Tue Feb  4 10:12:11 2026] DMAR-IR: Enabled IRQ remapping in x2apic mode

Ce que cela signifie : Intel VT-d est actif et le remappage d’IRQ est activé. C’est la bonne voie.

Décision : Si vous voyez « IRQ remapping disabled » ou rien sur IR, supposez un risque plus élevé pour la stabilité du passthrough.

Task 3: Verify IOMMU and interrupt remapping in dmesg (AMD)

cr0x@server:~$ dmesg -T | egrep -i "AMD-Vi|IOMMU|remap|IVRS" | head -n 30
[Tue Feb  4 10:12:10 2026] AMD-Vi: IOMMU performance counters supported
[Tue Feb  4 10:12:10 2026] AMD-Vi: Interrupt remapping enabled

Ce que cela signifie : AMD IOMMU fonctionne et le remappage d’interruptions est activé.

Décision : Pas de remappage d’interruptions ? Ne « colmatez » pas avec l’ACS override. Attendez-vous à des problèmes avec des périphériques à fortes interruptions.

Task 4: Check whether ACS override is enabled

cr0x@server:~$ grep -R "pcie_acs_override" -n /etc/default/grub /etc/kernel/cmdline 2>/dev/null
/etc/default/grub:6:GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"

Ce que cela signifie : L’ACS override est explicitement activé.

Décision : Traitez chaque groupe IOMMU « propre » avec suspicion jusqu’à preuve par la topologie et les bits de capacité ACS.

Task 5: Enumerate IOMMU groups the straightforward way

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}:"; lspci -nns $(ls "$g"/devices | sed 's/^/0000:/'); echo; done | head -n 40
Group 12:
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
03:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba] (rev a1)

Group 13:
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Ce que cela signifie : Le GPU et sa fonction audio sont regroupés (attendu). Le NVMe est dans un groupe différent (bien, peut-être).

Décision : Si des contrôleurs critiques de l’hôte partagent un groupe avec le périphérique que vous voulez, n’allez pas tout de suite vers l’ACS override. Cartographiez d’abord la topologie.

Task 6: View PCIe topology as a tree (who shares which bridge)

cr0x@server:~$ lspci -t
-+-[0000:00]-+-00.0
 |           +-01.0-[01]----00.0
 |           +-03.0-[02-05]--+-00.0
 |           |               +-00.1
 |           |               \-01.0
 |           \-08.1-[06]----00.0

Ce que cela signifie : Les périphériques derrière le même port descendant peuvent partager des contraintes d’isolation. Une division de groupe qui contredit cet arbre est un signal d’alarme.

Décision : Si votre périphérique cible est sous un switch/bridge avec d’autres périphériques, envisagez de changer de slot ou d’utiliser une carte avec une meilleure séparation des ports racine.

Task 7: Check whether the relevant bridges advertise ACS capability

cr0x@server:~$ lspci -vv -s 00:03.0 | egrep -i "ACSCap|ACSCtl|PCIe Cap|Root Port" -n
45:00:03.0 PCI bridge: Intel Corporation Device 7a44 (rev 11)
86:	Capabilities: [148 v1] Access Control Services
87:		ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans+
88:		ACSCtl: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+

Ce que cela signifie : Ce bridge possède réellement ACS. C’est bon ; la séparation de groupes ici est plus susceptible d’être « réelle ».

Décision : Si le bridge n’a pas la capacité ACS mais que vous comptez sur l’ACS override pour séparer les périphériques derrière lui, vous pariez sur un mensonge.

Task 8: Confirm VFIO bindings for the passthrough device

cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:5162]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Ce que cela signifie : Le GPU est lié à vfio-pci, pas au pilote graphique de l’hôte.

Décision : Si vous voyez le pilote du vendeur en cours d’utilisation, corrigez le binding avant de déboguer la stabilité. Les périphériques à moitié liés créent des problèmes fantômes.

Task 9: Look for IOMMU faults and DMAR/AMD-Vi errors during VM use

cr0x@server:~$ journalctl -k --since "2 hours ago" | egrep -i "DMAR|AMD-Vi|IOMMU fault|vfio|AER" | tail -n 30
Feb 04 09:41:22 server kernel: vfio-pci 0000:03:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258
Feb 04 09:58:03 server kernel: pcieport 0000:00:03.0: AER: Corrected error received: 0000:04:00.0
Feb 04 09:58:03 server kernel: nvme 0000:04:00.0: AER: [0] RxErr (First)

Ce que cela signifie : Erreurs PCIe corrigées sur le lien NVMe. Pas immédiatement fatal, mais cela vous indique que le lien physique est mécontent.

Décision : Si des erreurs corrigées apparaissent sous charge ou augmentent avec le temps, traitez cela comme un câble défaillant — sauf que le « câble » est votre slot, riser, alimentation, ou signal PCIe marginal.

Task 10: Check whether your NVMe is dropping queues or timing out

cr0x@server:~$ journalctl -k --since "24 hours ago" | egrep -i "nvme.*timeout|I/O.*timeout|resetting controller|frozen" | tail -n 20
Feb 03 22:14:19 server kernel: nvme nvme0: I/O 124 QID 7 timeout, aborting
Feb 03 22:14:19 server kernel: nvme nvme0: Abort status: 0x371
Feb 03 22:14:20 server kernel: nvme nvme0: resetting controller

Ce que cela signifie : Le contrôleur NVMe fait timeout et se réinitialise. Si cela coïncide avec la charge GPU/VM, soupçonnez une contention du chemin PCIe partagé ou des problèmes de signalisation.

Décision : Ne blâmez pas ZFS en premier. Réparez le transport. Envisagez de déplacer le NVMe sur un slot connecté au CPU ou de désactiver la gestion d’alimentation agressive.

Task 11: Confirm virtualization features and IOMMU visibility

cr0x@server:~$ pveversion -v | head -n 5
proxmox-ve: 8.2.2 (running kernel: 6.8.12-4-pve)
pve-manager: 8.2.2 (running version: 8.2.2/1a3f7d3e)
pve-kernel-6.8: 6.8.12-4

Ce que cela signifie : Vous pouvez corréler le comportement avec les versions du noyau. Les régressions VFIO et les quirks PCIe peuvent être spécifiques à un noyau.

Décision : Si l’instabilité a commencé juste après une mise à jour du noyau, testez le noyau Proxmox précédent avant de changer le matériel ou de « tuner » à l’aveugle.

Task 12: Inspect QEMU VM config for passthrough options that affect reset and ROM

cr0x@server:~$ cat /etc/pve/qemu-server/101.conf
agent: 1
bios: ovmf
boot: order=scsi0;net0
cpu: host
hostpci0: 0000:03:00,pcie=1,x-vga=1
machine: q35
memory: 16384
name: gpu-vm
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0
ostype: win11
scsi0: local-lvm:vm-101-disk-0,size=200G

Ce que cela signifie : OVMF + q35 + cpu: host est une configuration typique pour le passthrough GPU.

Décision : Si vous voyez un BIOS legacy, i440fx, ou des combinaisons étranges, standardisez d’abord. Déboguer des configs VM uniques est une taxe inutile.

Task 13: Check whether the device supports FLR (Function Level Reset)

cr0x@server:~$ lspci -vv -s 03:00.0 | egrep -i "FLR|Reset" -n
210:	Capabilities: [1b0 v1] Transaction Processing Hints
233:	Capabilities: [300 v1] Secondary PCI Express
262:	Kernel driver in use: vfio-pci

Ce que cela signifie : Cet extrait n’affiche pas explicitement FLR ; beaucoup de périphériques ne l’annoncent pas clairement de façon visible. Le comportement de reset reste important sur le plan opérationnel.

Décision : Si les reboots VM échouent sauf si vous redémarrez l’hôte, soupçonnez le comportement de reset. Envisagez un autre modèle de GPU ou une topologie où le périphérique peut être coupé sous tension (ex. contrôle d’alimentation du slot sur certaines cartes serveurs).

Task 14: Validate that the host isn’t accidentally using the passed-through GPU for console

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x  2 root root       80 Feb  4 10:12 by-path
crw-rw----  1 root video 226,   0 Feb  4 10:12 card0
crw-rw----  1 root render 226, 128 Feb  4 10:12 renderD128

Ce que cela signifie : Des périphériques DRM existent. Si le GPU passé est lié à VFIO, il ne devrait généralement pas apparaître comme un périphérique DRM actif pour la pile hôte.

Décision : Si l’hôte utilise le GPU (framebuffer/DRM), corrigez cela : blacklist des pilotes, définissez le GPU primaire dans le BIOS, et assurez-vous que VFIO se lie tôt.

Task 15: Confirm that your intended HBA is in a clean group before passthrough

cr0x@server:~$ lspci -nn | egrep -i "SAS|HBA|LSI|Broadcom|MegaRAID"
81:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)

cr0x@server:~$ readlink -f /sys/bus/pci/devices/0000:81:00.0/iommu_group
/sys/kernel/iommu_groups/26

Ce que cela signifie : Le HBA est dans le groupe 26. Listez maintenant ce qui d’autre se trouve dans ce groupe avant de le passer.

Décision : Si le groupe contient autre chose que le HBA (ou ses fonctions attendues), ne comptez pas sur l’ACS override pour « arranger » ça. Changez de slot ou de carte.

Task 16: Check CPU/chipset lane attachment hints (quick-and-dirty)

cr0x@server:~$ lspci -vv -s 04:00.0 | egrep -i "LnkCap|LnkSta" 
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 16GT/s, Width x4

Ce que cela signifie : Le lien est à la vitesse/largeur attendue. Si vous voyez une largeur x1 ou une vitesse inférieure à l’attendu, vous avez trouvé un indice de performance et de stabilité.

Décision : Corrigez le brochage physique, les paramètres PCIe du BIOS, les risers, ou le choix du slot avant d’accuser Proxmox ou VFIO.

Trois mini-récits d’entreprise issus du monde réel

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

Une entreprise de taille moyenne a constitué un cluster Proxmox pour héberger des agents de build et quelques services internes. Ils avaient une machine GPU pour des workloads CI :
tests de navigateurs, encodage vidéo, et quelques jobs CUDA. Le GPU vivait sur une carte mère de classe workstation qui paraissait « assez serveur ».

L’ingénieur en charge a trouvé des groupes IOMMU moches et a activé l’ACS override. La VM GPU a démarré. Les benchs étaient bons. Tout le monde est passé à autre chose.
Leur hypothèse était simple : « Si c’est dans son propre groupe IOMMU, c’est isolé. » Le noyau l’avait dit. Donc ça doit être vrai.

Des semaines plus tard, ils ont commencé à voir des défaillances sporadiques dans des VM totalement non reliées sur ce même hôte. Pas tous les jours. Pas toutes les charges.
Les pannes étaient exaspérantes : une VM gelait pendant 30–90 secondes, se rétablissait, puis avait un état d’application corrompu. Parfois l’hôte loguait des erreurs PCIe corrigées.
Parfois rien du tout.

Le schéma final montrait que les gels corrélaient avec une forte activité DMA du GPU et un IO NVMe intense en même temps.
La topologie PCIe montrait les deux périphériques derrière un port en amont partagé sans ACS approprié. L’ACS override avait séparé les groupes logiquement,
mais le bus pouvait encore se comporter comme un quartier partagé avec des cloisons fines.

La correction a été ennuyeuse et coûteuse : ils ont déplacé le GPU vers un autre slot, le plaçant sur un port racine différent, et remplacé un riser marginal pour des vitesses Gen4.
Ils ont désactivé l’ACS override après avoir confirmé que les groupes étaient propres sans lui. La stabilité est revenue immédiatement. Personne n’a regretté la simplicité.

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

Une autre organisation a essayé de tirer le maximum de performance d’un hôte Proxmox axé stockage. Ils passaient un HBA à une VM TrueNAS
et aussi une NIC haute vitesse à une VM routeur. La carte mère ne leur donnait pas de groupes propres. L’ACS override semblait éviter l’achat d’une nouvelle plateforme.

Ils ont aussi activé iommu=pt et quelques options BIOS « performance » : tweaks ASPM, désactivation d’économies d’énergie agressives, et forçage de vitesses PCIe.
L’objectif était faible latence et haut débit. Le résultat a été… des benchmarks initialement impressionnants.

Puis la déconvenue : sous trafic soutenu, la VM NIC perdait parfois la liaison pendant une seconde. Pas assez pour déclencher des alarmes évidentes,
mais assez pour provoquer des retransmissions TCP et des timeouts applicatifs en amont. Pendant ce temps la VM stockage loguait des resets de contrôleur occasionnels.
L’hôte lui-même ne plantait pas, donc tout le monde traitait ça comme un problème invité.

Ce n’était pas ça. C’était la contention et la récupération d’erreur sur un chemin PCIe partagé que l’ACS override avait rendu facile à ignorer.
L’« optimisation » a augmenté la charge et poussé le lien dans un régime de récupération d’erreurs. Les AER corrigées ont augmenté. La latence est devenue éruptive.

Ils ont annulé les forçages BIOS, puis déplacé un périphérique vers un slot connecté au CPU. Les performances ont légèrement chuté sur papier, mais le réseau a cessé de hoqueter.
Les graphiques de service sont redevenus ennuyeux. L’ennui est l’objectif.

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

Une équipe de services financiers utilisait Proxmox pour des workloads internes avec un processus de gestion des changements strict (oui, ça existe).
Ils voulaient du passthrough GPU pour un petit workload analytique. Le matériel était une vraie carte serveur avec ports racine clairs et VT-d validé.

Le SRE principal a insisté sur une checklist : capturer la topologie PCIe, enregistrer les groupes IOMMU avant les modifications, valider le remappage d’interruptions,
et exécuter un test de burn-in. Pas d’ACS override sauf s’ils pouvaient prouver la capacité ACS sur le chemin en amont. C’était impopulaire. Les gens voulaient la VM aujourd’hui.

Durant le burn-in, ils ont détecté un flux constant d’erreurs AER corrigées sur le port en amont du GPU à Gen4. Le système « fonctionnait », mais les logs n’étaient pas contents.
Ils ont changé le GPU de slot et les erreurs ont disparu. C’était probablement un problème d’assise ou d’intégrité du signal sur ce slot, mais ils n’avaient pas besoin d’une réponse philosophique.
Ils avaient besoin d’un fonctionnement propre.

Des mois plus tard, une mise à jour firmware a changé le comportement d’égalisation PCIe et une autre équipe a commencé à voir du bruit AER sur des hôtes similaires.
Cette équipe disposait déjà de logs de référence et de snapshots de topologie, donc ils ont pu comparer immédiatement « avant » et « après ».
Ils ont évité des jours de tâtonnements et ont ciblé le problème sur une révision BIOS spécifique.

Leur pratique n’était pas glamour. C’était aussi la raison pour laquelle personne n’a été appelé à 2h du matin.

Faites ceci à la place : manières plus sûres d’obtenir le passthrough

Si l’ACS override vous tente, cela signifie généralement que la plateforme ne vous donne pas de limites propres. La bonne réponse est de réparer les limites,
pas de faire semblant qu’elles existent.

Option A : Utiliser le bon slot (la topologie est une fonctionnalité)

Beaucoup de cartes ont un ou deux slots câblés directement au CPU root complex et d’autres via le chipset.
Les slots connectés au CPU tendent à offrir une isolation plus propre et moins de surprises « tout partage tout ».

Déplacez le périphérique. Oui, physiquement. C’est incroyable combien de « problèmes VFIO » sont en réalité des « vous avez choisi le slot que le concepteur a utilisé par commodité ».

Option B : Choisir du matériel avec un vrai ACS et des groupes IOMMU sensés

Les cartes serveurs, cartes workstation, et certaines cartes grand public haut de gamme offrent un meilleur comportement ACS et plus de ports racine.
Ce n’est pas garanti par la marque ; c’est modèle-spécifique. Vous voulez :

Séparation claire des lanes CPU vs lanes chipset
Capacité ACS correcte sur les bridges/ports racine
VT-d/AMD-Vi validé avec remappage d’interruptions

Option C : Passer tout le groupe (quand c’est raisonnable)

Le noyau groupe les périphériques ensemble parce qu’il ne peut pas prouver l’isolation. Parfois le mouvement stable le plus simple est d’accepter cela :
passez tout le groupe IOMMU à une seule VM et éloignez l’hôte de ces périphériques.

Cela fonctionne bien quand le groupe est « GPU + audio GPU » ou « contrôleur USB que vous pouvez sacrifier ». Cela fonctionne mal quand le groupe contient du stockage ou du réseau
dont l’hôte a besoin. C’est votre signal que la plateforme est le problème, pas Proxmox.

Option D : Arrêtez de passer la mauvaise classe de périphérique

Si vous voulez des performances de stockage, vous n’avez pas toujours besoin du passthrough HBA. Parfois une configuration virtio-scsi sur l’hôte avec ZFS est plus simple et plus sûre.
Si vous voulez de l’accélération GPU pour une application spécifique, parfois un conteneur avec l’accès périphérique approprié suffit (et évite le risque au niveau du bus).

Option E : Si vous devez utiliser l’ACS override, encadrez-le et testez sérieusement

Parfois vous êtes coincé. Budget, contraintes matérielles, temps. Si vous décidez d’utiliser l’ACS override malgré tout, traitez-le comme un brûlage contrôlé :

Activez-le seulement pour valider la faisabilité, puis essayez de le supprimer en changeant de slot/matériel.
Effectuez un burn-in sous charge IO et d’interruptions réaliste.
Surveillez en continu AER, fautes IOMMU, resets et latences.
Ayez un plan de rollback et documentez pourquoi ce risque a été accepté.

Blague n°2 : Si votre plan de disponibilité est « j’ai activé l’ACS override et j’ai prié », félicitations — vous avez implémenté une infrastructure basée sur la foi.

Erreurs courantes : symptôme → cause racine → correction

Voici les récidivistes. Pas des fautes morales. Juste des motifs.

1) Symptom: VM runs fine until reboot; then GPU passthrough fails

Cause racine : Comportement de reset GPU (pas de FLR ou chemin de reset bogué). Le périphérique ne revient pas dans un état propre après l’arrêt/reboot de l’invité.

Correction : Essayez un autre modèle de GPU, assurez-vous que le périphérique n’est pas partagé, considérez le reboot de l’hôte en dernier recours, et évitez que l’ACS override masque les problèmes de topologie. Si la stabilité compte, choisissez du matériel connu pour un comportement de reset sain.

2) Symptom: Host hard-freezes under IO or GPU load

Cause racine : Remappage d’interruptions manquant/désactivé, ou bugs IOMMU de la plateforme déclenchés par des taux d’interruptions élevés.

Correction : Confirmez que dmesg montre le remappage d’interruptions activé. Mettez à jour le BIOS/firmware. Si IR ne peut pas être activé de façon fiable, ne faites pas de passthrough de périphériques à fortes interruptions sur cette plateforme.

3) Symptom: Storage latency spikes when GPU VM is busy

Cause racine : Contention de bande passante sur port racine/switch uplink partagé, souvent rendue invisible par la division de groupe ACS override.

Correction : Déplacez les périphériques sur différents ports racine CPU ; évitez les lanes chipset pour deux périphériques lourds. Vérifiez avec lspci -t et la largeur/vitesse du lien.

4) Symptom: AER corrected errors slowly climb in logs

Cause racine : Signalisation PCIe marginale (assise du slot, riser, alimentation, forçage de vitesse Gen, ou layout de la carte).

Correction : Réassurez le périphérique, retirez les risers, annulez les paramètres PCIe forcés, essayez un autre slot, et envisagez de limiter la vitesse du lien (comme diagnostic) pour voir si les erreurs disparaissent.

5) Symptom: “Device is in its own IOMMU group” but weird cross-device effects happen

Cause racine : L’ACS override a créé des groupes logiques sans application réelle d’ACS.

Correction : Désactivez l’ACS override et revérifiez les groupes. Si la séparation disparaît, ne comptez pas sur la fausse division — changez le matériel/topologie.

6) Symptom: VFIO binds, but device still appears used by host drivers

Cause racine : Problèmes d’ordre de binding des pilotes ; configuration initramfs VFIO manquante ; console hôte utilisant le GPU.

Correction : Assurez-vous que les modules VFIO se chargent tôt, blacklistez les modules conflictuels, définissez l’affichage primaire dans le BIOS sur iGPU/autre GPU, et re-vérifiez lspci -nnk.

7) Symptom: Passing through an HBA causes sporadic ZFS errors inside the storage VM

Cause racine : Le HBA partage un groupe/topologie avec d’autres périphériques ; erreurs/reset PCIe ; ou quirks de gestion d’alimentation.

Correction : Mettez le HBA sur un port racine propre ; évitez l’ACS override ; utilisez des HBA entreprise avec firmware stable ; surveillez AER et resets de contrôleur.

Checklists / plan pas à pas

Checklist A: Before you enable ACS override (the “don’t regret this” pass)

Confirmer que l’IOMMU est activé dans /proc/cmdline.
Confirmer que le remappage d’interruptions est activé dans dmesg (DMAR-IR ou AMD-Vi interrupt remapping).
Capturer la sortie de lspci -t pour la topologie.
Capturer la liste des groupes IOMMU depuis /sys/kernel/iommu_groups.
Vérifier les bridges concernés pour la capacité ACS via lspci -vv.
Décider si vous pouvez passer tout le groupe à la place.
Décider si changer de slot peut corriger le groupement sans override.

Checklist B: If you already enabled ACS override (stabilize or back out)

Documenter les paramètres du noyau exacts et la version de Proxmox.
Exécuter un burn-in de 2–4 heures qui reflète votre charge réelle (GPU + stockage + réseau).
Surveiller journalctl -k pour AER, fautes IOMMU, messages de reset VFIO.
Si vous voyez une montée d’erreurs AER corrigées, traitez-le d’abord comme un problème matériel/topologie.
Essayez de déplacer le périphérique vers un autre slot et répétez le burn-in.
Essayez de désactiver l’ACS override et revérifiez si le groupement devient acceptable.
Si vous ne pouvez pas retirer l’ACS override, fixez les attentes : risque opérationnel plus élevé, surveillance accrue, et plan de rollback testé.

Checklist C: A production-grade PCI passthrough acceptance test

Cold boot de l’hôte, démarrer la VM, exécuter la charge pendant 60 minutes.
Arrêter la VM, démarrer la VM à nouveau (test du chemin de reset), exécuter la charge encore.
Migrer des VM non liées hors et sur l’hôte si votre environnement le fait (stress scheduling).
Capturer les compteurs AER et comparer début vs fin.
Valider qu’il n’y a pas de resets NVMe, pas de flaps de liaison NIC, pas de soft lockups hôte.

FAQ

1) Is ACS override “unsafe” or just “unsupported”?

C’est un compromis délibéré. Il peut réduire les garanties d’isolation en créant des divisions de groupes IOMMU que le matériel n’applique peut-être pas.
C’est un problème de sécurité et de sûreté, pas seulement de support.

2) If my VM works, why should I care about “real” isolation?

Parce que votre mode de défaillance peut être rare et dépendant de la charge. Les problèmes d’isolation apparaissent souvent sous forme de gels intermittents, de resets, et de « falaises » de performance.
Ce sont les pires incidents à déboguer.

3) Does ACS override always cause instability?

Non. Sur certaines topologies le risque pratique est faible, et l’override aide surtout le noyau à être moins conservateur. Mais généralement vous ne savez pas dans quel cas vous êtes
sans inspecter les capacités ACS et la topologie.

4) Can I use ACS override only for one device?

Le paramètre du noyau affecte le comportement de groupement globalement (selon le mode). Vous ne pouvez pas le contraindre proprement à un seul endpoint comme vous le faites avec le binding VFIO.
Traitez-le comme un changement de comportement de l’hôte tout entier.

5) What’s the best alternative when my GPU shares a group with SATA or USB?

Déplacez le GPU vers un autre slot/port racine, ou changez la carte. Si c’est impossible, envisagez de passer un autre GPU ou d’utiliser une plateforme faite pour la virtualisation.
Si nécessaire, passez tout le groupe — uniquement si vous pouvez sacrifier tous les éléments qu’il contient.

6) I’m doing ZFS in a VM with an HBA passthrough. Is ACS override ever acceptable?

C’est un multiplicateur de risque. Si le HBA n’est pas vraiment isolé, vous créez un chemin où des étrangetés au niveau du bus peuvent impacter la fiabilité du stockage.
Pour le stockage, je suis plus strict : évitez l’ACS override sauf si vous avez validé ACS sur le chemin en amont et effectué un burn-in sous IO réel.

7) What should I watch in logs to catch trouble early?

Messages AER, « resetting controller » pour NVMe, fautes IOMMU, erreurs DMAR/AMD-Vi, et messages VFIO autour du reset de périphérique ou du mapping des BAR.
Si les erreurs corrigées augmentent, ne les ignorez pas.

8) Does `iommu=pt` make passthrough less safe?

Cela peut réduire l’overhead en mappant les périphériques hôtes plus directement, mais ce n’est pas un substitut à une isolation correcte. Pour la plupart des installations Proxmox c’est courant.
Votre plus grand levier de sécurité reste néanmoins un groupement IOMMU réel et le remappage des interruptions.

9) Can a kernel update change IOMMU groupings?

Oui. Les quirks PCI du noyau et le traitement ACS peuvent changer. C’est pourquoi vous devez capturer des groupements et topologies « connus bons », et re-valider après des mises à jour majeures.

10) When is ACS override a reasonable temporary tool?

Quand vous validez la faisabilité, faites une preuve de concept en labo, ou débloquez une migration en attendant du matériel correct. Temporaire signifie que vous avez déjà planifié la sortie :
autre slot, autre carte, ou autre architecture.

Prochaines étapes à faire cette semaine

Si vous utilisez actuellement l’ACS override sur un hôte Proxmox important, ne la laissez pas « activée et oubliée ». Faites ceci :

Capturez des preuves : sauvegardez /proc/cmdline, lspci -t, et une liste complète des groupes IOMMU.
Vérifiez le remappage : confirmez le remappage d’interruptions dans dmesg. S’il n’est pas présent, ne le considérez pas comme stable.
Auditez les bridges : vérifiez la capacité ACS sur le chemin en amont des périphériques que vous passez.
Burn-in : exécutez la charge réelle et surveillez les messages AER/IOMMU/NVMe reset. Si les logs sont bruyants, réparez d’abord le physique/la topologie.
Essayez de retirer l’override : déplacez les slots, passez des groupes entiers, ou changez le matériel jusqu’à ce que les groupes soient propres sans que le noyau ne fasse semblant.

L’objectif n’est pas la pureté. L’objectif est des domaines de défaillance prévisibles. Si l’ACS override est la seule chose entre vous et un système fonctionnel,
c’est un signal pour re-designer — pas une raison de célébrer.