iommu=pt : Le mode de performance caché pour la virtualisation Linux (quand l’utiliser)

février 12, 2026 • février 12, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Vous achetez des CPU rapides, des NIC rapides, des NVMe rapides, et pourtant votre « plate-forme de virtualisation » fonctionne comme si elle montait un piano à l’étage.
Pics de latence. Débits de paquets qui vacillent. Les IOPS de stockage semblent corrects dans un benchmark mais étranges en production.
Quelqu’un suggère « peut‑être que c’est l’IOMMU » et la pièce devient silencieuse, car cette phrase est à la fois vraie et coûteuse.

iommu=pt est l’un de ces commutateurs du noyau Linux qui peut donner l’impression d’un gain de performance gratuit — jusqu’à ce que ce ne soit pas le cas.
Il peut réduire le surcoût dans le chemin de mappage DMA, surtout sous des charges d’E/S virtualisées élevées.
Il peut aussi retirer silencieusement des protections sur lesquelles vous comptiez, ou rendre votre capacité de débogage beaucoup plus difficile.
Ceci est le guide de terrain : quand l’activer, quand l’éviter, et comment prouver que vous résolvez le bon problème.

Ce que `iommu=pt` fait réellement (pas ce que pense Internet)

L’IOMMU (Input‑Output Memory Management Unit) est le MMU pour les périphériques. Il traduit les adresses visibles par le périphérique (IOVA)
en adresses physiques hôtes, et il applique l’isolation pour qu’un périphérique ne puisse pas DMA n’importe où.
En virtualisation, c’est un élément central pour un passthrough PCI sûr (VFIO), l’isolation SR‑IOV, et parfois même pour « juste virtio » selon votre pile.

Linux prend en charge plusieurs modes opérationnels d’IOMMU. Les détails varient selon l’architecture et le pilote (Intel VT‑d, AMD‑Vi,
arm‑smmu, etc.), mais le schéma général est :

Mode traduit : les périphériques DMA passent par les tables de pages de l’IOMMU ; le noyau installe les mappages et peut faire
de l’isolation par périphérique.
Mode pass‑through : les périphériques utilisent des mappages « identité » (ou équivalents) de sorte que les traductions DMA sont
effectivement 1:1 et le surcoût de mappage est réduit.
Désactivé : pas de traduction IOMMU ; les fonctionnalités d’isolation disparaissent, et certaines fonctionnalités avancées de virtualisation
cessent de fonctionner.

iommu=pt demande à Linux de choisir par défaut des mappages pass‑through pour les périphériques qui ne sont pas assignés
aux invités (et parfois même avant l’assignation, selon le pilote et le cycle de vie du périphérique). Cela ne signifie pas « pas d’IOMMU ».
Cela signifie « garder l’IOMMU activé, mais éviter le surcoût de traduction là où l’isolation n’est pas nécessaire ».

La subtilité : lorsque vous liez ensuite un périphérique à VFIO et l’affectez à une VM, le noyau utilise toujours le mode traduit pour ce
périphérique (car vous avez besoin d’isolation entre invité et hôte). Le gain concerne généralement tout le reste : les périphériques hôtes,
le comportement par défaut du mappage DMA, et la quantité de remaniement des mappages dans l’IOMMU lorsque vous exécutez une charge I/O intense.

C’est pourquoi iommu=pt peut aider même si vous ne faites pas de passthrough PCI complet. Certaines charges génèrent une activité massive
de map/unmap DMA (stacks réseau, stockage, traitement de paquets en espace utilisateur, certains pilotes GPU/accélérateurs).
Si ces chemins rencontrent l’IOMMU en mode traduit, vous pouvez payer en cycles CPU, pression cache, invalidations IOTLB, et parfois « pourquoi ksoftirqd me vide le frigo ».

Une façon pratique de le concevoir :
iommu=pt échange une partie du comportement d’isolation par défaut contre une réduction du surcoût de traduction et de tenue des comptes.
C’est un réglage de performance avec une facture sécurité et débogage associée.

Deux termes que les gens confondent : « IOMMU activée » vs « remappage DMA activé »

Beaucoup de plateformes affichent des options de firmware liées à l’IOMMU avec des libellés vagues : « IOMMU », « VT‑d », « DMA remapping », « SVM », « AMD‑Vi ».
Vous pouvez souvent avoir les extensions de virtualisation activées tandis que le remappage DMA est désactivé. Les invités tournent toujours, mais l’isolation
des périphériques et le passthrough sûr deviennent chaotiques. Sur Linux, intel_iommu=on (ou amd_iommu=on) peut forcer son activation,
tandis que iommu=off le désactive dans le noyau.

Gardez cela en tête car les modes d’échec ressemblent : changements de performance, VFIO qui cesse de fonctionner, ou journaux noyau remplis
de plaintes DMAR/IOMMU. Mais les corrections diffèrent.

Exactement une citation (paraphrasée, parce que la précision compte)

Idée paraphrasée (attribuée à Gene Kim) : « Le travail d’amélioration doit être lié à des résultats, et vous avez besoin de boucles de rétroaction suffisamment rapides pour vous orienter. »

Pourquoi l’IOMMU existe : une courte histoire aux bords coupants

Si vous traitez les IOMMU comme « juste une taxe de performance », vous finirez avec un système rapide qui est aussi une arme à feu à un pied.
Un peu de contexte historique aide à comprendre pourquoi la taxe existe et quand il est raisonnable de l’éviter.

Faits et contexte intéressants (8 points)

Les IOMMU précèdent le battage médiatique moderne sur la virtualisation. Ils importaient d’abord pour les systèmes qui avaient besoin que les périphériques fassent du DMA vers
une mémoire au‑delà de ce que les périphériques pouvaient adresser directement, et pour le remappage dans des topologies de bus complexes.
Intel VT‑d et AMD‑Vi ont formalisé le remappage DMA comme fonctionnalité plateforme. Ceci a été critique pour l’assignation sûre de périphériques aux VM : sans isolation DMA, « passthrough » est essentiellement « merci de gribouiller mon hyperviseur ».
Le passthrough PCI initial était fragile car les interruptions et l’isolation DMA l’étaient. MSI/MSI‑X, remappage, et une isolation correcte des groupes IOMMU ont rendu cela banal.
L’API DMA Linux a abstrait le mappage, mais le backend IOMMU peut le rendre coûteux. Les pilotes appellent des API de mappage et s’attendent à ce qu’elles soient « assez bon marché ». Sous forte charge, « assez bon marché » devient discutable.
L’IOTLB existe parce que les périphériques cachent aussi les traductions. Quand les mappages changent, vous pouvez devoir faire des invalidations. Les tempêtes d’invalidation sont réelles et apparaissent comme des pics de latence.
SR‑IOV a changé le rayon d’impact. Désormais vous pouvez avoir beaucoup de VFs (virtual functions) effectuant du DMA, et chaque VF peut avoir ses propres besoins de mappage. Parfait pour la densité. Aussi parfait pour trouver le chemin lent.
Les usages réseau à haut débit en espace utilisateur (DPDK, XDP, AF_XDP) mettent la stratégie de mappage sous pression. Pinner la mémoire et utiliser des hugepages vise autant à éviter le remaniement des mappages qu’à réduire les défauts de TLB.
La recherche en sécurité a rendu les attaques DMA courantes. « Périphérique malveillant » n’est pas juste un scénario de film d’espionnage ; c’est un modèle de menace crédible en environnements multi‑locataires et là où l’accès physique existe.

Blague #1 (courte, pertinente) : L’IOMMU est comme le videur de votre RAM. Il est coûteux, mais il empêche la NIC d’aller dans les zones VIP.

Qui devrait utiliser `iommu=pt` (et qui doit garder ses mains loin)

Voici la version opinionnée : utilisez iommu=pt quand vous pouvez mesurer le surcoût IOMMU et que vous contrôlez le rayon d’impact.
N’utilisez pas cette option parce que vous avez vu un commentaire de forum qui se termine par « ça a résolu pour moi ».

Bons candidats

Hôtes de virtualisation dédiés avec passthrough d’appareils VFIO où la plupart des périphériques restent la propriété de l’hôte et où vous voulez réduire le
surcoût de traduction DMA par défaut pour les périphériques hôtes.
Nœuds réseau à haut débit de paquets utilisant SR‑IOV, DPDK, AF_XDP, ou virtio‑net intensif avec accélération vhost, où vous avez vérifié que du temps est passé dans le mappage/démappage ou les invalidations IOTLB.
Hyperviseurs lourds en stockage gérant beaucoup de complétions NVMe, files d’attente et travail d’interruption, où les cycles CPU dépensés dans le mappage DMA sont mesurables et nuisent à la latence tail.
Environnements mono‑locataire où le modèle de menace est constitué d’accidents opérationnels et non d’un DMA malveillant.

Mauvais candidats

Environnements multi‑locataires ou avec locataires hostiles où l’isolation DMA fait partie de votre stratégie de sécurité. Vous pouvez toujours utiliser l’IOMMU et faire du VFIO en toute sécurité,
mais le « pass‑through par défaut » est un choix de politique. Faites‑le délibérément, pas par inadvertance.
Hôtes qui comptent sur une isolation DMA stricte même pour les périphériques hôtes (pensez : périphériques non fiables, hotplug, emplacements edge, labos avec matériel mystère).
Systèmes où le débogage est déjà difficile. Si vous vivez dans un marécage de problèmes d’E/S intermittents, réduire l’isolation peut transformer « intermittent » en « irréproductible ».

Si vous pensez « mais nous ne sommes pas multi‑locataires », souvenez‑vous : vous êtes toujours multi‑parties prenantes. Les équipes sécurité, conformité et réponse aux incidents
feront partie de votre futur. Laissez‑leur un système qui ait du sens.

Ce que vous gagnez vs ce que vous risquez

Les bénéfices : d’où vient la performance

L’IOMMU ajoute du travail de plusieurs manières :

Surcoût de mappage : le noyau (ou un pilote) doit créer des mappages IOVA pour le DMA. Sous charge, cette gestion coûte du CPU.
Invalidations IOTLB : quand les mappages changent, les périphériques et l’IOMMU doivent faire des invalidations ; celles‑ci peuvent se sérialiser et provoquer des pics de latence.
Fenêtres DMA effectives plus petites : de mauvais paramètres par défaut peuvent provoquer une fragmentation de l’espace IOVA ou forcer l’utilisation de buffers de rebond.
Interactions avec le remappage d’interruptions : certaines plateformes lient le remappage d’interruptions à l’activation de l’IOMMU ; les choix de configuration peuvent
affecter le coût et le comportement de la livraison des interruptions.

iommu=pt réduit le travail de mappage pour les périphériques « normaux » de l’hôte en privilégiant des mappages de type identité. Cela peut :

Réduire le surcoût CPU dans les chemins d’E/S intensifs.
Réduire la latence tail causée par le remaniement des invalidations.
Rendre certains workloads moins sensibles aux petits changements de mappage.

Les inconvénients : ce que vous pouvez casser (ou affaiblir)

Changements de posture sécurité : vous pouvez perdre la protection DMA par défaut pour certains périphériques. Si un périphérique se comporte mal (bug ou malveillance),
il peut cibler plus facilement la mémoire de l’hôte.
Débogabilité réduite : la traduction stricte peut détecter certaines classes de bugs pilote/périphérique (mauvaises adresses DMA).
Les mappages identité peuvent laisser ces erreurs se produire silencieusement.
Hypothèses dans les outils : certains environnements partent du principe que « IOMMU activé » implique « DMA hôte protégé ». Avec des valeurs par défaut en pass‑through,
cette hypothèse devient fausse sauf si vous imposez la traduction par périphérique quand c’est nécessaire.
Cas limites et quirks matériels : certains chipsets et périphériques se comportent différemment avec des valeurs par défaut en pass‑through, surtout avec
ATS/PRI, remappage d’interruptions, ou comportements firmware atypiques.

Blague #2 (courte, pertinente) : Changer les modes IOMMU en production, c’est comme réorganiser un centre de données pendant un exercice d’évacuation — éducatif, mais vous apprendrez de nouveaux mots.

Playbook de diagnostic rapide

Vous ne basculez pas iommu=pt parce que vous vous ennuyez. Vous le basculez parce que vous avez un goulot d’étranglement et que vous pouvez l’expliquer.
Voici l’ordre d’opérations que j’utilise quand un hôte de virtualisation est « rapide sauf quand il ne l’est pas ».

Premier : prouvez si le problème est du temps CPU, de la latence, ou de la mise en file

Vérifiez la saturation CPU dans softirq, kvm, vhost, ou travaux liés à l’iommu.
Vérifiez les pics de latence tail corrélés aux interruptions réseau/stockage.
Vérifiez la croissance de la profondeur de file : anneaux NIC, files NVMe, blk‑mq, files vhost.

Deuxième : confirmez que l’IOMMU est dans le chemin et comment il est configuré

L’IOMMU est‑il activé dans le firmware et le noyau ?
Utilisez‑vous le mode traduit globalement, ou des valeurs par défaut pass‑through ?
Les périphériques critiques (assignés à VFIO) sont‑ils toujours isolés correctement ?

Troisième : identifiez le chemin chaud (mapping/unmapping vs autre chose)

Faites un échantillonnage perf pour iommu_map/iommu_unmap et les fonctions de l’API DMA.
Vérifiez le coût des invalidations IOTLB.
Vérifiez l’utilisation de bounce buffering / swiotlb, qui indique souvent une contrainte d’adressage/mappage.

Point de décision

Si vous pouvez montrer un temps CPU significatif dans le mappage DMA ou les invalidations IOMMU sur l’hôte — et que le modèle de sécurité le permet — alors
iommu=pt est une expérience raisonnable. Si vous ne pouvez pas le montrer, vous êtes probablement sur le point d’optimiser un placebo.

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

Ce ne sont pas des « lancez‑ça parce que c’est amusant ». Chaque tâche inclut ce qu’il faut rechercher et quelle décision elle pilote.
Exécutez‑les sur l’hôte sauf indication contraire.

Task 1: Confirm the kernel command line (what you actually booted)

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

Signification : C’est la vérité terrain. Si iommu=pt n’est pas ici, vous ne le testez pas.
Décision : Si des paramètres manquent ou sont en conflit (comme iommu=off), corrigez la configuration du chargeur de démarrage avant toute chose.

Task 2: Check dmesg for IOMMU mode and DMAR/AMD-Vi initialization

cr0x@server:~$ dmesg -T | egrep -i 'DMAR|IOMMU|AMD-Vi|iommu=' | head -n 30
[Mon Feb  3 10:11:21 2026] DMAR: IOMMU enabled
[Mon Feb  3 10:11:21 2026] DMAR: Default domain type: Passthrough
[Mon Feb  3 10:11:21 2026] pci 0000:00:00.0: DMAR: Skip IOMMU disabling for graphics

Signification : « Default domain type: Passthrough » est l’élément qui confirme que iommu=pt a pris effet (sur les chemins Intel VT‑d).
Décision : Si vous ne le voyez pas, vous êtes peut‑être sur un autre pilote, le firmware peut désactiver des fonctionnalités, ou le paramètre est ignoré.

Task 3: Verify IOMMU groups exist (and see what’s isolated)

cr0x@server:~$ find /sys/kernel/iommu_groups/ -maxdepth 2 -type l | head
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/7/devices/0000:3b:00.0

Signification : Si des groupes existent, l’IOMMU organise au moins les unités d’isolation.
Décision : Pas de groupes signifie généralement que l’IOMMU n’est pas activé ou non supporté ; la sécurité du passthrough VFIO sera compromise.

Task 4: Inspect a specific device’s group (is it shareable or stuck with friends?)

cr0x@server:~$ lspci -nn | egrep -i 'Ethernet|Non-Volatile|VGA' | head -n 5
3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
5e:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

cr0x@server:~$ readlink -f /sys/bus/pci/devices/0000:3b:00.0/iommu_group
/sys/kernel/iommu_groups/7

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups/7/devices/
0000:3b:00.0
0000:3b:00.1

Signification : Le NIC a deux fonctions dans le même groupe ; c’est courant. Le passthrough exige que l’ensemble du groupe soit contrôlé.
Décision : Si le groupe contient des périphériques sans rapport, vous pourriez avoir besoin d’un autre emplacement PCIe, des réglages BIOS ACS, ou accepter « pas de passthrough ».

Task 5: Check whether VFIO is in use and which devices are bound

cr0x@server:~$ lsmod | egrep 'vfio|kvm|vhost' | head -n 20
vfio_pci               73728  0
vfio_pci_core          94208  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   53248  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             376832  0
kvm                  1097728  1 kvm_intel
vhost_net              32768  0

cr0x@server:~$ lspci -nnk -s 3b:00.0
3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
	Subsystem: Intel Corporation Ethernet Converged Network Adapter X710 [8086:0000]
	Kernel driver in use: vfio-pci
	Kernel modules: i40e

Signification : Le NIC est lié à vfio-pci ; il devrait utiliser une isolation traduite pour l’invité même si le domaine par défaut est passthrough.
Décision : Si un périphérique destiné à l’hôte est accidentellement lié à vfio, attendez‑vous à l’absence de réseau/stockage sur l’hôte et à une réunion très tendue.

Task 6: Check IOMMU default domain (generic interface when available)

cr0x@server:~$ cat /sys/module/iommu/parameters/default_domain
pt

Signification : Le domaine par défaut de l’IOMMU du noyau est pass‑through.
Décision : Si cela indique translated (ou similaire), vous n’êtes pas dans le mode que vous pensez ; validez les paramètres du noyau et les valeurs par défaut de la distribution.

Task 7: Look for SWIOTLB usage (a classic hidden performance sink)

cr0x@server:~$ dmesg -T | egrep -i 'swiotlb|bounce' | head -n 20
[Mon Feb  3 10:11:20 2026] software IO TLB: mapped [mem 0x000000007a000000-0x000000007e000000] (64MB)

Signification : SWIOTLB est un mécanisme de bounce buffer. Il peut apparaître à cause de limites d’adressage DMA, de la configuration IOMMU, ou de quirks plateforme.
Décision : Si vous voyez une utilisation importante de SWIOTLB sous charge (souvent visible dans perf), considérez le placement de la mémoire, le BIOS « above 4G decoding », ou le tuning de l’IOMMU.

Task 8: See if interrupt remapping is enabled (stability and security implications)

cr0x@server:~$ dmesg -T | egrep -i 'Interrupt remapping|IR:' | head -n 20
[Mon Feb  3 10:11:21 2026] DMAR-IR: Enabled IRQ remapping in x2apic mode

Signification : Le remappage IRQ est activé. Bon pour l’isolation et parfois requis pour un passthrough stable sur certains systèmes.
Décision : S’il est désactivé de manière inattendue, vérifiez les réglages firmware et les paramètres du noyau ; certaines plateformes le désactivent dans des configurations étranges.

Task 9: Profile for IOMMU/DMA mapping hot spots (proof before policy)

cr0x@server:~$ sudo perf top -g --call-graph fp
Samples: 18K of event 'cycles', Event count (approx.): 12200542319
  5.21%  [kernel]  [k] iommu_map
  4.87%  [kernel]  [k] iommu_unmap
  3.94%  [kernel]  [k] dma_map_page_attrs
  3.12%  [kernel]  [k] intel_iommu_unmap
  2.77%  [kernel]  [k] handle_edge_irq

Signification : C’est la preuve dont vous avez besoin : du temps CPU significatif dans le mapping/démapping.
Décision : Si ces fonctions sont en haut pendant votre charge réelle, iommu=pt est une expérience justifiée. Sinon, cherchez ailleurs.

Task 10: Check host CPU time in softirq (networking pain often shows here)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server) 	02/03/2026 	_x86_64_	(64 CPU)

12:14:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:14:02 AM  all   12.5  0.0  18.2   0.4  0.8  22.9   0.0  45.2
12:14:02 AM    7    8.1  0.0  15.0   0.0  1.2  46.3   0.0  29.4

Signification : Un %soft élevé indique souvent du travail réseau ou des complétions bloc et du travail piloté par interruption.
Décision : Si softirq est élevé et que perf montre des fonctions IOMMU, le chemin de mappage est un candidat. Si softirq est élevé mais pas l’IOMMU, concentrez‑vous sur NIC/RPS/affinité IRQ.

Task 11: Validate hugepages and pinned memory behavior (especially for DPDK/VFIO)

cr0x@server:~$ grep -E 'HugePages|Hugepagesize' /proc/meminfo
HugePages_Total:     4096
HugePages_Free:      3900
HugePages_Rsvd:       120
Hugepagesize:       2048 kB

Signification : Des hugepages sont disponibles ; cela réduit la pression TLB et peut diminuer le remaniement des mappages dans les frameworks I/O en espace utilisateur.
Décision : Si vous dépendez des hugepages et qu’elles sont épuisées sous charge, vous verrez un effondrement des performances qui ressemble à « l’IOMMU est lent ».

Task 12: Check QEMU/KVM process CPU and thread behavior (don’t blame IOMMU for a pinned vCPU)

cr0x@server:~$ ps -eo pid,comm,pcpu,psr,cls,rtprio,pri,ni,stat --sort=-pcpu | head
 23144 qemu-system-x86 189.7  12  TS      -  19   0 Rl
  1821 ksoftirqd/7       45.2   7  TS      -  19   0 R
  1402 vhost-23144       32.1   7  TS      -  19   0 R

Signification : Un processus VM et un thread vhost sont chauds, plus ksoftirqd sur le même CPU.
Décision : Avant de toucher l’IOMMU, corrigez l’affinité CPU et la distribution IRQ. Si vous gardez tout sur le CPU 7, vous avez construit un petit embouteillage.

Task 13: Inspect IRQ distribution for a NIC (interrupt storms masquerade as “IOMMU overhead”)

cr0x@server:~$ egrep -i 'eth0|i40e|x710' /proc/interrupts | head -n 10
 169:  12499231   38123   11212   11098   IR-PCI-MSI 524288-edge      eth0-TxRx-0
 170:  12588110   39001   11992   10902   IR-PCI-MSI 524289-edge      eth0-TxRx-1

Signification : Les interruptions sont présentes et réparties entre les CPU (colonnes de gauche). Si tous les comptes se trouvent sur un seul CPU, vous avez trouvé une cause probable de latence.
Décision : Si la distribution est mauvaise, ajustez l’affinité IRQ et RPS/XPS ; iommu=pt ne sauvera pas un embouteillage d’interruption mono‑cœur.

Task 14: Check for IOMMU faults (when performance issues are actually errors)

cr0x@server:~$ dmesg -T | egrep -i 'IOMMU fault|DMAR: DRHD|IO_PAGE_FAULT|AMD-Vi: Event logged' | tail -n 10
[Mon Feb  3 12:19:04 2026] DMAR: [DMA Read] Request device [3b:00.0] fault addr 0x7f3a4000 [fault reason 0x05] PTE Read access is not set

Signification : Un vrai défaut DMA. Ce n’est pas « temps de tuning », c’est « temps de confinement et de correction ».
Décision : Arrêtez. Validez l’assignation du périphérique, la stabilité du pilote, le firmware, et si l’invité/l’hôte est mal configuré. iommu=pt pourrait masquer cela, pas le corriger.

Trois mini‑histoires d’entreprise tirées du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne exploitait une flotte d’hyperviseurs KVM avec un mix de périphériques virtio et quelques NICs VFIO passthrough pour des locataires « premium ».
La sécurité a validé « IOMMU activé » dans leur checklist de durcissement. L’équipe d’infrastructure a entendu la même phrase et l’a traduite par
« nous pouvons faire du passthrough en toute sécurité ; l’IOMMU est activé ».

Un nouveau déploiement du noyau incluait iommu=pt. Il a été ajouté comme tweak de performance après un test en labo montrant une réduction de l’usage CPU dans des charges réseau.
La note de changement disait « garde l’IOMMU activé, améliore les performances ». Tout le monde a hoché la tête. Personne n’a demandé : « quels périphériques continuent d’être traduits par défaut ? »

Des semaines plus tard, ils ont enquêté sur un étrange événement de corruption mémoire hôte. Pas fréquent. Pas reproductible. Le genre de problème qui vous force à boire du café froid.
Après assez d’archéologie dans les logs, l’équipe a trouvé un motif : les hôtes affectés avaient un pilote hors arbre particulier pour une carte PCIe de monitoring.
Cette carte faisait du DMA vers la mauvaise adresse sous certaines conditions de reset. En mode traduction stricte elle aurait levé un défaut bruyant. Avec des valeurs par défaut pass‑through,
elle a gribouillé silencieusement.

La correction n’a pas été « ne jamais utiliser iommu=pt ». La correction a été d’arrêter de traiter « IOMMU activé » comme un contrôle de sécurité booléen.
Ils ont remplacé la combinaison carte/driver problématique, et ont renforcé le contrôle des changements autour des paramètres du noyau qui affectent l’isolation DMA.
Ils ont aussi ajouté un contrôle post‑boot qui vérifie le domaine par défaut et alerte quand il change de manière inattendue.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une entreprise exploitait une infra de trading basse latence sur des hôtes dédiés. Ils n’étaient pas multi‑locataires, mais extrêmement sensibles au jitter.
Un ingénieur performance a vu mapping/unmapping apparaître dans un profil et a décidé de « supprimer entièrement le surcoût IOMMU ». Ils ont mis iommu=off sur toute la flotte.
Le benchmark initial était excellent. La direction a obtenu le graphique qu’elle voulait.

Puis est venue une fenêtre de mise à jour du firmware NIC. Un hôte est revenu avec une topologie PCIe légèrement différente et un quirk d’interruption.
Sans remappage d’interruptions (souvent lié à l’activation de l’IOMMU), ils ont connu des tempêtes d’interruptions intermittentes et des interruptions manquées sous charge.
Le symptôme était simple : perte sporadique de paquets à la frontière de l’hôte.

Ils ont essayé d’ajuster les anneaux, le coalescing, l’affinité IRQ — tous les leviers habituels. Parfois ça aidait, parfois non.
Le vrai problème était que la plateforme était passée dans une configuration moins testée pour cette combinaison NIC/firmware.
Ce n’était pas un « bug Linux », c’était un « vous avez désactivé une fonctionnalité que la plateforme attendait ».

Ils ont reculé vers intel_iommu=on iommu=pt. Les performances sont restées bonnes, et la stabilité est revenue.
La leçon n’était pas « l’IOMMU est toujours bon ». La leçon était « la plateforme est un système ». Enlever une partie et le reste peut bouder.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe cloud exploitait une plate‑forme privée de virtualisation pour des charges internes : runners CI, bases de données, et quelques machines GPU pour ML.
Ils avaient une politique stricte « un changement par déploiement » pour les paramètres du noyau. Ça agaçait les développeurs. Ça les a aussi sauvés.

Quand ils ont expérimenté iommu=pt, ils n’ont pas commencé par le déployer. Ils ont commencé par instrumenter :
profils perf sous charge représentative, histogrammes de latence baseline, comptage des défauts IOMMU depuis dmesg, et
une simple exportation quotidienne de /proc/cmdline + domaine IOMMU par défaut.

Le test a montré une baisse petite mais constante du CPU hôte pour leur workload CI réseau‑lourd. Parfait. Ils l’ont déployé sur un cluster.
Deux jours plus tard, un hôte GPU a commencé à générer des défauts DMA pendant des resets d’invité. L’équipe a pu corréler immédiatement :
le problème existait avant, mais le mode strict aurait faulté plus tôt ; les valeurs par défaut pass‑through rendaient la défaillance plus rare et plus coriace.

Parce qu’ils avaient un déploiement par étapes et de la télémétrie, le rollback a été propre. Pas de drame. Pas de « on pense que c’est le noyau ».
Ils ont isolé le problème à une paire firmware+pilote GPU spécifique, l’ont corrigée, puis ont réintroduit iommu=pt en confiance.
Les pratiques ennuyeuses ne gagnent pas d’applaudissements. Elles vous donnent du sommeil.

Erreurs courantes (symptômes → cause racine → correction)

1) Symptom: VFIO passthrough fails after enabling `iommu=pt`

Cause racine : Confondre iommu=pt avec iommu=off, ou le firmware n’active pas réellement le remappage DMA.
Parfois le système démarre sans le support IOMMU approprié, donc VFIO refuse de s’attacher.

Correction : Vérifiez avec dmesg que l’IOMMU est activé, vérifiez que des groupes existent, assurez‑vous que intel_iommu=on ou amd_iommu=on est réglé, et confirmez que le firmware VT‑d/AMD‑Vi est activé.

2) Symptom: Performance improved, but you now get rare host crashes or memory corruption

Cause racine : Un périphérique/driver buggy a fait du DMA incorrect ; la traduction stricte aurait déclenché un défaut, les valeurs pass‑through l’ont laissé gribouiller.

Correction : Traitez cela comme une question de correction. Mettez à jour firmware/ pilotes, retirez les périphériques problématiques, et envisagez de garder le mode traduit pour certaines classes de périphériques (ou évitez iommu=pt sur des hôtes avec périphériques douteux).

3) Symptom: Latency spikes remain even with `iommu=pt`

Cause racine : Le goulot d’étranglement n’était pas la traduction IOMMU ; c’était l’affinité IRQ, l’arriéré softirq, le placement des threads vhost, ou des problèmes côté invité.

Correction : Utilisez /proc/interrupts, mpstat, et perf pour trouver le vrai chemin chaud. Corrigez d’abord le pinning CPU et la distribution des IRQ.

4) Symptom: SR-IOV VFs work, but throughput is inconsistent across VMs

Cause racine : Contraintes de groupes IOMMU et limitations ACS entraînent un placement maladroit, ou vous avez des modes d’interruption mixtes entre les VFs.
Parfois une sous‑population de VFs se retrouve avec une locality NUMA différente et vous incriminez l’IOMMU.

Correction : Vérifiez les groupes, le nœud NUMA des périphériques PCI, la distribution des IRQ, et assurez‑vous que le pinning vCPU des VM aligne la locality du périphérique.

5) Symptom: Dmesg shows DMA faults after a kernel parameter change

Cause racine : Un périphérique utilise désormais le mode traduit avec une application plus stricte (ou l’inverse), révélant un vrai bug.

Correction : Ne pas « tuner cela ». Identifiez le périphérique, le pilote et la charge déclencheuse du défaut. Validez la configuration VFIO et mettez à jour le firmware.

Listes de contrôle / plan étape par étape

Step-by-step: deciding whether to try `iommu=pt`

Définissez votre objectif. Exemple : « Réduire le CPU hôte de 10% à 2Mpps par hôte tout en gardant le passthrough VFIO stable. »
Capturez une baseline. Échantillon perf, % softirq, latence p99 pour les chemins clés (stockage, réseau), et compte des défauts dmesg.
Prouvez que le surcoût IOMMU existe. Cherchez map/unmap et invalidations IOTLB dans perf durant la charge réelle.
Confirmez le modèle de menace. Mono‑locataire ? Matériel contrôlé ? Sinon, obtenez l’aval sécurité et documentez le compromis.
Déployez par étapes. Un hôte, un pool, un cluster. Facilitez le rollback.
Validez l’isolation pour les périphériques VFIO. Assurez‑vous que les périphériques assignés utilisent toujours VFIO avec des groupes corrects.
Surveillez après le changement. Surveillez les défauts DMA, l’instabilité hôte, et la latence tail.

Implementation checklist: making the change cleanly

Réglez le firmware VT‑d/AMD‑Vi et (si pertinent) « Above 4G decoding » de façon appropriée.
Définissez les paramètres du noyau : intel_iommu=on iommu=pt ou amd_iommu=on iommu=pt selon le cas.
Redémarrez, puis vérifiez avec /proc/cmdline et dmesg.
Vérifiez que les groupes IOMMU existent et que les périphériques VFIO sont dans les groupes corrects.
Reprenez vos mesures de baseline et comparez.

Rollback checklist

Retirez iommu=pt et redémarrez.
Confirmez que le domaine par défaut n’est plus pt (translated ou valeur par défaut distro).
Re‑vérifiez la liaison des périphériques VFIO et la fonctionnalité des invités.
Comparez les logs de défauts et les régressions latence/CPU avec la baseline.

FAQ

1) Does `iommu=pt` disable the IOMMU?

Non. Il garde l’IOMMU activé mais demande des mappages de type pass‑through/identité par défaut pour les périphériques non assignés.
Les périphériques assignés à VFIO nécessitent toujours une isolation traduite.

2) When is `iommu=pt` most likely to help?

Quand votre hôte passe un temps CPU significatif dans map/unmap DMA ou les invalidations IOMMU sous charge réelle — courant dans le réseau à haut débit,
des taux élevés de complétions stockage, ou des frameworks I/O en espace utilisateur.

3) Is `iommu=pt` safe for multi-tenant environments?

« Sûr » dépend de la politique et de la confiance matérielle. Si votre modèle de sécurité dépend de l’isolation DMA pour les périphériques hôtes, les valeurs par défaut pass‑through sont un risque.
Dans les configurations multi‑locataires, faites de ce choix une décision délibérée et révisée avec contrôles compensatoires.

4) How is `iommu=pt` different from `intel_iommu=on`?

intel_iommu=on force l’activation Intel VT‑d. iommu=pt définit le type de domaine par défaut.
On les utilise souvent ensemble : forcer l’activation, puis choisir le défaut pass‑through.

5) Will `iommu=pt` improve virtio performance?

Parfois indirectement. Virtio est paravirtual, mais le comportement DMA de l’hôte pour les périphériques backing et les chemins vhost peut encore impliquer du travail IOMMU.
Mesurez. Si perf n’affiche pas de surcoût IOMMU, n’attendez pas de miracles.

6) What’s the biggest operational risk of enabling `iommu=pt`?

Masquer ou activer des bugs liés au DMA et affaiblir l’isolation par défaut pour les périphériques hôtes. Le plus inquiétant est que les défaillances peuvent devenir plus rares et plus destructrices.

7) If performance is bad, should I just use `iommu=off` instead?

Généralement non. Désactiver l’IOMMU supprime des protections et peut casser VFIO, les attentes d’isolation SR‑IOV, et le remappage d’interruptions sur certaines plateformes.
Si vous cherchez de la performance, iommu=pt est l’outil plus chirurgical — toujours avec des compromis.

8) How do I prove `iommu=pt` is the reason performance improved?

Utilisez des comparaisons before/after sous la même charge : profils perf (temps de mapping/unmapping), utilisation CPU, et latence tail.
Vérifiez aussi que le domaine par défaut est bien passé en passthrough dans dmesg ou sysfs.

9) Can `iommu=pt` cause devices to end up in different IOMMU groups?

Non. Les groupes sont déterminés par la topologie matérielle (comportement ACS PCIe, isolation du root port), pas par le domaine par défaut de mappage.
Si vos groupes sont mauvais, corrigez la topologie/ACS/l’emplacement, pas le mode de mappage du noyau.

10) What’s a sign I should not touch IOMMU knobs at all?

Si votre goulot d’étranglement est clairement ailleurs : un CPU chaud unique dû à l’affinité IRQ, mauvaise configuration pilote côté invité, mise en file stockage, ou problèmes d’ordonnancement.
Corrigez d’abord l’évidence.

Conclusion : étapes suivantes qui ne vous rendront pas célèbre pour de mauvaises raisons

iommu=pt n’est pas un commutateur magique de vitesse. C’est un choix de politique : garder l’IOMMU activé, réduire le surcoût de traduction là où l’isolation n’est pas nécessaire,
et accepter que vous avez modifié les garde‑fous de sécurité par défaut.

Étapes pratiques suivantes :

Exécutez le playbook de diagnostic rapide et obtenez un profil perf sous charge réelle. Si le mappage IOMMU n’est pas chaud, arrêtez‑vous là.
Si map/unmap est chaud, testez iommu=pt sur un hôte. Validez : cmdline, domaine par défaut dans dmesg, liaisons VFIO, et absence de défauts DMA.
Comparez CPU et latence tail à la baseline. Si vous n’obtenez pas un gain significatif, revenez en arrière et passez à autre chose — votre goulot d’étranglement est ailleurs.
Si vous le conservez, documentez le compromis sécurité, ajoutez une vérification post‑boot du domaine par défaut, et surveillez dmesg pour les défauts DMA comme si c’était votre travail (parce que ça l’est).