MSI/MSI-X + Remappage des interruptions : le correctif de 5 minutes pour les saccades aléatoires des VM

Un modèle mental utile : pourquoi les interruptions causent des saccades « aléatoires »

Le problème de saccade de votre VM est souvent un problème de distribution de latence, pas de débit.
Les interruptions sont un moteur principal de la latence en queue car elles percent le temps CPU.
Quand la perforation arrive au mauvais moment — pendant l’exécution d’un vCPU, une rafale de réception réseau ou une vague de complétions de stockage — vous n’obtenez pas « plus lent »,
vous obtenez du caractère pointeux.

Ce que MSI/MSI‑X change par rapport à l’INTx legacy

Les interruptions PCI legacy (INTx) sont des lignes déclenchées par niveau partagées entre dispositifs. « Partagées » est un terme poli.
Dans la pratique, ça peut devenir une discussion de groupe bruyante : un dispositif active la ligne, le CPU doit interroger plusieurs périphériques
« c’était toi ? » jusqu’à trouver le bon. Ce travail supplémentaire est de la gigue.

MSI (Message Signaled Interrupts) a remplacé « activer un pin » par « écrire un message à une adresse APIC spécifique ».
MSI‑X est allé plus loin avec de nombreux vecteurs, permettant à un périphérique de répartir la charge entre des files (pensez aux NIC multiqueue et NVMe).
Bien utilisé, MSI‑X est l’un des héros discrets derrière les E/S modernes à faible latence.

Où le remappage des interruptions entre en jeu

En virtualisation et en passthrough, vous ne livrez pas seulement des interruptions à l’hôte.
Vous devez les livrer au bon invité, en sécurité, sans permettre à un périphérique d’écrire des interruptions vers des destinations arbitraires.
Cette traduction — mapper un message MSI/MSI‑X généré par un périphérique vers une cible d’interruption autorisée — est le remappage des interruptions,
typiquement fourni par l’IOMMU (Intel VT-d ou AMD‑Vi).

Sans remappage des interruptions, le noyau peut refuser d’activer MSI/MSI‑X dans certains scénarios de passthrough,
ou il peut retomber sur INTx legacy ou des chemins moins efficaces. Même lorsque « ça marche », vous pouvez vous retrouver avec :

• Des tempêtes d’interruptions consolidées sur un seul CPU
• Un arriéré de softirq et du thrashing de ksoftirqd
• Du buffering dans vhost-net, virtio ou la couche bloc
• Des préemptions vCPU imprévisibles (la saccade que vous ressentez)

Vérité sèchement drôle : le CPU est excellent en calcul et terrible quand tout le monde l’interrompt en même temps — comme un chirurgien à qui on demande aussi de répondre au téléphone du bureau.

À quoi ressemble une « saccade aléatoire » au niveau des interruptions

Le schéma classique est des pics de latence brefs mais sévères corrélés à :

• Rafales réseau (complétions RX/TX)
• Files de complétions NVMe
• Contrôleurs USB (oui, vraiment) entraînant des pics de gestion d’IRQ par l’hôte
• Anomalies de livraison d’interruptions en passthrough GPU
• Interactions tick timer et ordonnanceur quand l’hôte est légèrement surassigné

L’hôte peut montrer une faible utilisation CPU globale, mais un cœur se fait marteler par les interruptions et les softirqs pendant que les autres restent inactifs.
C’est pourquoi la « moyenne CPU » est le mauvais graphe à surveiller.

Une nuance pratique de plus : les « interruptions » incluent à la fois le contexte IRQ hard et le traitement softirq/NAPI.
Une NIC peut générer des interruptions qui déclenchent du traitement softirq sur le même CPU, et cela peut voler du temps aux threads vCPU KVM.
Vous verrez des saccades malgré une marge importante.

Citation (idée paraphrasée) de Werner Vogels : Vous le construisez, vous l’exécutez — la responsabilité opérationnelle change la manière dont vous concevez et déboguez les systèmes.
Si vous exploitez des hyperviseurs, les interruptions ne sont pas des « choses matérielles ». Ce sont votre produit.

Faits et historique réellement importants

Vous n’avez pas besoin d’une visite de musée, mais quelques faits concrets vous aident à arrêter de refaire les mêmes mauvaises hypothèses :

1. MSI est apparu largement avec le matériel PCI 2.2 pour réduire les lignes d’interruption partagées et améliorer l’évolutivité.
2. MSI‑X est arrivé avec PCI 3.0 et a augmenté significativement le nombre de vecteurs, permettant des interruptions par file pour les périphériques haute-performance.
3. INTx legacy est déclenché par niveau et partageable ; il est sujet au balayage « qui a activé la ligne ? » et à des interactions étranges sous charge.
4. Les NIC modernes et NVMe sont conçus en partant de MSI‑X ; retomber sur INTx peut détruire silencieusement le parallélisme et ajouter de la gigue.
5. Le remappage des interruptions est autant une fonctionnalité de sécurité que de performance ; il empêche les périphériques de cibler arbitrairement des CPUs/invités avec des écritures MSI.
6. Les IOMMU VT-d/AMD‑Vi sont souvent activés pour l’isolation DMA, mais le remappage des interruptions peut rester désactivé ou indisponible selon le firmware/les options.
7. Les logs Intel DMAR sont utiles ; le noyau vous dira quand le remappage des interruptions est désactivé, forcé ou cassé — si vous prenez la peine de regarder.
8. x2APIC et les interruptions postées ont changé la donne pour l’évolutivité de la livraison d’interruptions et la réduction du coût des VM-exit dans certains chemins de virtualisation.
9. irqbalance n’est pas un outil de performance universel ; c’est un compromis ; il peut aider ou nuire selon la mise en queue, le pinning CPU et la stratégie d’isolation.

Deuxième petite blague : si quelqu’un vous dit « les interruptions ne peuvent pas causer de saccades parce que l’utilisation CPU est seulement de 20% », il vient d’inventer une nouvelle unité de déni.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : prouvez que c’est la latence d’interruption/softirq, pas le CPU brut ou le débit stockage

• Vérifiez la distribution IRQ par CPU et la pression softirq.
• Corrélez les pics avec un périphérique (NIC, NVMe, USB, HBA, GPU).
• Cherchez une retombée sur INTx et l’absence de MSI/MSI‑X.

Deuxième : validez que l’IOMMU + le remappage d’interruptions sont réellement activés

• Confirmez les flags de démarrage du noyau : Intel intel_iommu=on, AMD amd_iommu=on.
• Confirmez que les logs DMAR/IVRS montrent le remappage d’interruptions activé.
• Si vous faites du passthrough VFIO : assurez-vous que la plateforme le supporte et que le noyau l’utilise.

Troisième : corrigez la topologie d’interruptions (affinité, isolation, files)

• Répartissez délibérément les vecteurs MSI‑X sur les CPUs, pas « ce qui s’est passé au boot ».
• Faites coïncider le pinning CPU et l’affinité IRQ (ne pincez pas les vCPU sur le même cœur qui gère toutes les interruptions NIC).
• Re-vérifiez les saccades : votre objectif est une latence tail plus serrée, pas forcément un débit plus élevé.

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

Voici les vérifications que j’exécute réellement sur un hôte Linux KVM (Proxmox, Ubuntu, Debian, RHEL-ish).
Elles sont ordonnées pour que vous puissiez vous arrêter tôt si vous trouvez la preuve évidente.
Chaque tâche inclut : commande, sortie réaliste, ce que ça signifie et la décision à prendre.

Task 1: Confirm IOMMU is enabled in the kernel command line

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0 root=/dev/mapper/vg0-root ro quiet intel_iommu=on iommu=pt

Ce que ça signifie : intel_iommu=on active l’IOMMU VT-d. iommu=pt utilise le mode passthrough pour les périphériques hôtes afin de réduire l’overhead tout en gardant la traduction disponible.

Décision : Si vous ne voyez pas intel_iommu=on ou amd_iommu=on, ajoutez-le et redémarrez. Si vous utilisez VFIO, vous voulez généralement l’activer. Si vous utilisez uniquement virtio, ça aide souvent quand même pour la sanity du remappage d’interruptions.

Task 2: Check DMAR/IVRS logs for interrupt remapping status

cr0x@server:~$ dmesg -T | egrep -i 'dmar|ivrs|iommu|interrupt remapping' | head -n 30
[Mon Feb  3 10:12:11 2026] DMAR: IOMMU enabled
[Mon Feb  3 10:12:11 2026] DMAR: Interrupt remapping enabled
[Mon Feb  3 10:12:11 2026] DMAR: x2apic enabled
[Mon Feb  3 10:12:12 2026] pci 0000:3b:00.0: DMAR: Skip IOMMU disabling for graphics

Ce que ça signifie : C’est l’indicateur « ne pas trop réfléchir ». S’il indique remappage d’interruptions activé, la plateforme + firmware + noyau coopèrent.

Décision : Si vous voyez Interrupt remapping disabled ou des erreurs, arrêtez-vous et corrigez cela avant d’ajuster l’affinité IRQ. Vous ne pouvez pas compenser l’absence de fonctionnalités par des réglages.

Task 3: Confirm the IOMMU groups exist (sanity for VFIO users)

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/2/devices/0000:00:02.0

Ce que ça signifie : L’existence des groupes implique fortement que l’IOMMU est active.

Décision : Si le répertoire est vide/absent, vous n’êtes pas dans une configuration IOMMU réelle. Corrigez les paramètres BIOS/UEFI (VT-d/AMD-Vi) et les flags du noyau.

Task 4: Identify which PCI devices are using MSI/MSI‑X vs INTx

cr0x@server:~$ lspci -nnk | egrep -A3 -i 'ethernet|nvme|usb|sata|raid|vga|3d'
3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
	Subsystem: Intel Corporation Device [8086:0000]
	Kernel driver in use: i40e
	Kernel modules: i40e
5e:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]
	Kernel driver in use: nvme
0a:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
	Kernel driver in use: xhci_hcd

Ce que ça signifie : Cela montre qui est important. NIC + NVMe + USB sont des sources courantes de saccades.

Décision : Ensuite, inspectez chaque périphérique pour « MSI/MSI‑X enabled » et le nombre de vecteurs.

Task 5: For a device, check whether MSI/MSI‑X is enabled and how many vectors

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | egrep -i 'msi|msi-x|interrupt'
	Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
	Interrupt: pin A routed to IRQ 16

Ce que ça signifie : MSI‑X est activé avec 64 vecteurs. MSI est présent mais désactivé (normal quand MSI‑X est utilisé). La ligne « Interrupt pin … IRQ 16 » peut exister même quand MSI‑X est en service ; ne paniquez pas.

Décision : Si vous voyez MSI-X: Enable- et que vous attendiez des performances multiqueue, vous avez potentiellement trouvé la cause. Cherchez pourquoi il est désactivé (options du pilote, quirks du noyau, problèmes VFIO/IR).

Task 6: Detect legacy INTx usage via /proc/interrupts patterns

cr0x@server:~$ cat /proc/interrupts | head -n 15
           CPU0       CPU1       CPU2       CPU3
  16:     91233          3          1          2   IO-APIC   16-fasteoi   i40e
  24:    501223          0          0          0   PCI-MSI 524288-edge   nvme0q0
  25:    198772          0          0          0   PCI-MSI 524289-edge   nvme0q1
  26:     77211          0          0          0   PCI-MSI 524290-edge   nvme0q2

Ce que ça signifie : Les lignes IO-APIC indiquent souvent des interruptions legacy ou basées sur pin ; PCI-MSI indique des vecteurs MSI/MSI‑X. Notez aussi la distribution CPU : tout s’accumulant sur CPU0 est un piège de latence.

Décision : Si les périphériques chauds sont IO-APIC et majoritairement sur CPU0, passez à MSI/MSI‑X et/ou ajustez l’affinité. S’ils sont MSI mais restent concentrés sur CPU0, réglez l’affinité et irqbalance.

Task 7: Check softirq pressure (the hidden “interrupt aftermath”)

cr0x@server:~$ cat /proc/softirqs
                    CPU0       CPU1       CPU2       CPU3
          HI:          3          0          0          0
       TIMER:   1123456    902233     877112     889001
      NET_TX:      8221      9102      8455      8601
      NET_RX:   9981234     21002     19511     20110
       BLOCK:    302112     88011     90122     89300
    IRQ_POLL:          0          0          0          0
     TASKLET:      1022       1101       1002       1010
       SCHED:    512001     490002     488901     487112
     HRTIMER:        42         39         41         40
         RCU:    980002     910001     905551     907221

Ce que ça signifie : CPU0 a un NET_RX massif comparé aux autres. C’est exactement le profil de saccade « un cœur se fait massacrer ».

Décision : Répartissez les files NIC (RSS), définissez l’affinité IRQ ou ajustez RPS/XPS. Si vous pincez des vCPU, gardez les CPUs à forte IRQ loin des threads vCPU sensibles à la latence.

Task 8: Check which IRQs belong to your NIC queues and where they run

cr0x@server:~$ grep -iE 'i40e|mlx|ixgbe|bnxt|ena' /proc/interrupts | head
  16:     91233          3          1          2   IO-APIC   16-fasteoi   i40e
  98:    501223          0          0          0   PCI-MSI 327680-edge   i40e-TxRx-0
  99:    498877          0          0          0   PCI-MSI 327681-edge   i40e-TxRx-1
 100:    490112          0          0          0   PCI-MSI 327682-edge   i40e-TxRx-2

Ce que ça signifie : Les interruptions de file sont collées sur CPU0. Soit l’affinité est mal définie par défaut, soit irqbalance les a fixées là.

Décision : Définissez explicitement l’affinité pour ces IRQs, ou configurez irqbalance pour éviter vos cœurs « vCPU ».

Task 9: Inspect current IRQ affinity masks

cr0x@server:~$ sudo cat /proc/irq/98/smp_affinity
1

Ce que ça signifie : Le masque 1 signifie CPU0 seulement.

Décision : Changez-le pour répartir sur plusieurs CPUs (exemple : CPUs 0-3 est le masque f ; CPUs 4-7 est f0 sur un système 8 cœurs). Adaptez-le à votre topologie CPU et votre plan de pinning.

Task 10: Set IRQ affinity (carefully) for a queue IRQ

cr0x@server:~$ echo f | sudo tee /proc/irq/98/smp_affinity
f

Ce que ça signifie : Vous autorisez l’IRQ 98 à s’exécuter sur les CPUs 0–3. C’est un outil brutal, mais c’est une validation rapide.

Décision : Si les saccades diminuent immédiatement, vous avez validé le diagnostic. Ensuite, faites une configuration durable (unit systemd, profil tuned ou politique irqbalance).

Task 11: Check whether irqbalance is running and what it might be doing to you

cr0x@server:~$ systemctl status irqbalance --no-pager
● irqbalance.service - irqbalance daemon
     Loaded: loaded (/lib/systemd/system/irqbalance.service; enabled)
     Active: active (running) since Mon 2026-02-03 10:12:38 UTC; 1h 3min ago
   Main PID: 812 (irqbalance)
      Tasks: 1
     Memory: 2.4M
        CPU: 1.231s

Ce que ça signifie : irqbalance est actif. Il peut améliorer la distribution, ou il peut combattre votre isolation CPU et annuler votre pinning soigneux.

Décision : Si vous utilisez le pinning/isolation CPU pour les VMs, envisagez de configurer des bans dans irqbalance, ou de le désactiver et de gérer l’affinité explicitement.

Task 12: Check if the kernel is forcing PCI MSI off globally

cr0x@server:~$ cat /proc/cmdline | grep -o 'pci=.*' || true

Ce que ça signifie : Aucun pci=nomsi présent. Bien.

Décision : Si vous trouvez pci=nomsi dans la cmdline (oui, des gens collent ça depuis de vieux forums), retirez-le. C’est une usine à saccades sur le matériel moderne.

Task 13: Check for interrupt remapping disablement by kernel quirks

cr0x@server:~$ dmesg -T | egrep -i 'remapping.*(off|disable)|no IR|intremap' | head

Ce que ça signifie : Rien d’alarmant trouvé dans cet échantillon. Sur des systèmes cassés, vous pourriez voir des messages indiquant que IR est désactivé à cause de bugs BIOS ou de limitations de plateforme.

Décision : Si vous voyez des désactivations forcées, mettez à jour le BIOS/UEFI et le microcode d’abord. Si ça échoue toujours, vous pourriez avoir besoin d’un matériel différent pour un comportement VFIO/MSI stable.

Task 14: Check KVM threads placement and whether vCPUs share cores with IRQ storms

cr0x@server:~$ ps -eLo pid,psr,comm | egrep 'kvm|qemu-system' | head
  2311   0 qemu-system-x86
  2315   0 CPU 0/KVM
  2316   1 CPU 1/KVM
  2317   2 CPU 2/KVM
  2318   3 CPU 3/KVM

Ce que ça signifie : Les threads vCPU sont sur les CPU 0–3. Si vos interruptions sont aussi concentrées là, vous planifiez des affrontements.

Décision : Soit déplacez les IRQ loin des cœurs vCPU, soit déplacez les vCPU loin des cœurs chargés en IRQ. Ne « partagez » pas en espérant le meilleur.

Task 15: Quick glance at per-CPU softirq usage in real time

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

11:21:01 AM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
11:21:02 AM  all  7.11  0.00  6.33    0.12  0.10  3.52   0.00 82.82
11:21:02 AM    0  4.00  0.00  9.00    0.00  0.60 18.40   0.00 68.00
11:21:02 AM    1  8.00  0.00  6.00    0.00  0.00  1.00   0.00 85.00
11:21:02 AM    2  9.00  0.00  5.00    0.00  0.00  0.90   0.00 85.10
11:21:02 AM    3  8.00  0.00  5.00    0.00  0.00  0.80   0.00 85.20

Ce que ça signifie : CPU0 a un %soft élevé qui correspond souvent à un arriéré NET_RX. C’est un générateur classique de jitter VM.

Décision : Si un CPU montre un softirq élevé, ciblez les files du périphérique mappées dessus et redistribuez.

Le correctif de 5 minutes : quoi changer et pourquoi

« 5 minutes » suppose que vous avez accès à la console et pouvez redémarrer une fois. Si vous ne pouvez pas redémarrer, vous pouvez toujours valider et atténuer partiellement avec l’affinité.
L’idée centrale est simple : assurez-vous que MSI/MSI‑X est activé, et assurez-vous que le remappage des interruptions est activé pour que la livraison MSI soit sûre et rapide dans les chemins virtualisés.

Étape 1 : Activer l’IOMMU et le remappage des interruptions dans le firmware

Dans le BIOS/UEFI, activez :

• Intel : VT-d (parfois « Intel Virtualization Technology for Directed I/O »)
• AMD : AMD‑Vi / IOMMU

Vérifiez aussi les bascules « Interrupt Remapping » ou « DMA Remapping » si le firmware les expose.
Les interfaces firmware varient de polies à maudites. Cherchez tout ce qui ressemble à IOMMU/VT-d/AMD‑Vi.

Étape 2 : Activer l’IOMMU dans les paramètres de démarrage du noyau

Ajoutez l’un de ces paramètres dans votre chargeur de démarrage :

• intel_iommu=on iommu=pt
• amd_iommu=on iommu=pt

iommu=pt est souvent un bon défaut pour les hôtes qui ne mettent pas « tout derrière la traduction tout le temps ».
Il peut réduire l’overhead tout en gardant la machinerie IOMMU disponible pour le remappage et l’affectation de périphériques.

Étape 3 : Redémarrer, vérifier que DMAR/IVRS dit « Interrupt remapping enabled »

Si ce n’est pas activé, arrêtez-vous. Ne faites pas des réglages d’IRQ élaborés sur une plateforme mal configurée.
Corrigez le BIOS/UEFI, mettez à jour le firmware/microcode, ou changez le matériel si nécessaire.

Étape 4 : Vérifier que les périphériques utilisent bien MSI/MSI‑X et ont le nombre attendu de vecteurs

Pour les NIC, vous attendez plusieurs files Tx/Rx. Pour NVMe, vous attendez plusieurs files de complétions.
Si vous voyez un seul vecteur, ou MSI‑X présent mais désactivé, des saccades sous rafales sont sans surprise.

Étape 5 : Écarter les interruptions des cœurs vCPU

Le tour de performance n’est pas « répartir tout partout ». C’est la séparation des responsabilités :

• Choisissez des cœurs CPU pour le travail IRQ/softirq hôte (réseau, stockage)
• Choisissez des cœurs CPU pour les vCPUs des VM (invités sensibles à la latence)
• Faites correspondre les politiques d’affinité à ces choix

Si vous ne faites rien d’autre, au moins arrêtez de laisser toutes les interruptions de file pointer vers CPU0. CPU0 a déjà des tâches de maintenance sur de nombreux systèmes.
Laissez-le respirer.

Trois mini-histoires d’entreprise depuis les tranchées des interruptions

Incident : la mauvaise hypothèse (« le stockage doit être le problème »)

Une entreprise de taille moyenne exploitait un cluster de virtualisation hébergeant l’intégration continue interne, quelques bases de données et une ferme VDI.
Les utilisateurs se plaignaient que « les VM se figent pendant une seconde » plusieurs fois par heure. Logiquement, l’équipe stockage a été alertée en premier,
parce que le stockage est toujours le premier interrogé.

L’hypothèse initiale était familière : saccades = latence stockage. L’équipe a scruté les graphiques SAN, les stats multipath
et les retransmissions iSCSI. Rien. La latence était stable. Le débit avait de la marge. Le fournisseur SAN s’ennuyait poliment.

Un SRE a exécuté une simple vérification : /proc/softirqs et /proc/interrupts. CPU0 présentait des compteurs NET_RX écrasants.
La carte 10GbE était « multiqueue capable », mais ses vecteurs IRQ étaient effectivement collés à un seul cœur.
Ils ont aussi découvert que le remappage des interruptions avait été désactivé dans le firmware après qu’un profil BIOS ait été réinitialisé par une mise à jour de plateforme.

Avec le remappage des interruptions désactivé, l’hôte avait pris une voie de livraison d’interruptions moins optimale pour un sous-ensemble de périphériques.
Sous un trafic VDI en rafale, la gestion IRQ/softirq de l’hôte privait brièvement les threads vCPU KVM.
Les utilisateurs percevaient cela comme « la VM qui se fige ».

Le correctif fut ennuyeux : réactiver VT-d/IOMMU + remappage des interruptions, confirmer MSI‑X activé, puis distribuer les interruptions de file loin des cœurs vCPU.
Le SAN n’a rien changé. Les tickets ont cessé. L’équipe stockage n’a pas reçu d’excuses, mais leurs astreintes sont devenues plus calmes.

Optimisation qui a mal tourné : « désactiver l’IOMMU pour la performance »

Une autre organisation exploitait un cluster compute dense : beaucoup de VMs, réseau intensif, NVMe local modéré.
Quelqu’un a lu que l’IOMMU ajoute de l’overhead et a poussé un changement pour le désactiver sur toute la flotte. C’était présenté comme « performance gratuite ».
Le changement a été déployé durant une fenêtre de mise à jour noyau.

Les benchmarks de débit semblaient corrects. Voilà le piège : les moyennes n’ont pas beaucoup bougé.
Mais une semaine plus tard, le support a commencé à recevoir des rapports de « micro-gels » dans les sessions distantes, plus des rafales de perte de paquets dans les invités.
Ce n’était pas consistant. C’était pire sur des nœuds avec certaines révisions de firmware NIC. Naturellement, cela est devenu un débat inter-équipes.

Le postmortem a découvert deux problèmes. Premièrement : sans IOMMU, le remappage des interruptions n’était pas disponible, et certains cas de passthrough retombaient sur des chemins affreux.
Deuxièmement : leur stratégie de pinning CPU supposait que les IRQ seraient balancées loin des cœurs vCPU isolés. irqbalance a fait le contraire sur certains nœuds,
et sans les fonctionnalités d’interruption attendues, la distribution a été encore pire.

Le rollback a été simple : réactiver l’IOMMU avec iommu=pt pour éviter des traductions inutiles pour les périphériques hôtes,
vérifier le remappage des interruptions dans dmesg, puis revalider l’affinité IRQ. L’optimisation « performance gratuite » avait livré de la gigue gratuite à la place.

La leçon durable : un changement qui améliore le débit moyen peut quand même ruiner la latence tail.
Pour des systèmes orientés utilisateur (VDI, voix, jeux, trading, latence de commit de base), la latence tail est ce qui compte.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « profils matériels et assertions au démarrage »

Une équipe de services financiers exploitait un petit environnement KVM critique. Leur travail n’était pas glamour : services internes,
lots batch, quelques composants sensibles à la latence et des contraintes de conformité rendant le changement pénible.
Ils ont appris tôt que « même modèle de serveur » ne veut pas dire « mêmes paramètres firmware ».

Ils se sont standardisés sur une baseline hôte :
VT-d/IOMMU activé, remappage des interruptions activé, profils BIOS cohérents exportés et versionnés,
et une vérification au démarrage qui alerterait si dmesg ne contenait pas la ligne attendue « Interrupt remapping enabled ».
Ils ont aussi piné les IRQ de maintenance et les files NIC sur des cœurs désignés, laissant un ensemble propre pour les vCPUs.

Un trimestre, ils ont dû remplacer une carte mère défaillante sous pression temporelle. La remplaçante est revenue avec un profil BIOS par défaut :
les fonctionnalités de virtualisation partiellement désactivées. L’hôte a démarré « correctement ». Les VM ont démarré « correctement ». Et puis les graphiques de latence ont commencé à chuchoter.

Leur assertion au démarrage l’a détecté en quelques minutes. Ils ont corrigé les paramètres firmware avant que les utilisateurs ne s’en aperçoivent.
Pas d’appel incident, pas de salle de crise, pas de blâme. Juste un ticket avec une checklist et une boucle fermée.

C’est la réalité peu sexy de la fiabilité : les pratiques ennuyeuses n’empêchent pas tous les problèmes,
mais elles préviennent le genre coûteux — ceux que vous ne détectez que quand votre PDG est la personne sur la session VDI figée.

Erreurs courantes : symptôme → cause → correction

1) Symptom: « Saccades aléatoires 200–800 ms, CPU bas »

Cause : Point chaud IRQ/softirq sur un CPU (souvent CPU0), privant périodiquement les threads vCPU.

Correction : Vérifiez MSI‑X activé ; redistribuez l’affinité IRQ ; séparez les cœurs IRQ des cœurs vCPU ; envisagez le tuning RPS/XPS.

2) Symptom: « VFIO passthrough fonctionne mais la latence est atroce sous charge »

Cause : Remappage des interruptions désactivé/indisponible ; interruptions du périphérique livrées via des chemins de repli ou MSI restreint.

Correction : Activez VT-d/AMD‑Vi + remappage des interruptions dans le firmware et le noyau. Mettez à jour le BIOS/microcode. Retestez en vérifiant dmesg.

3) Symptom: « La NIC revendique 10/25/40GbE mais se comporte comme 1GbE sous rafales »

Cause : MSI‑X non activé, ou une seule file/vecteur actif ; multiqueue non fonctionnel.

Correction : Confirmez MSI-X: Enable+ et le nombre de vecteurs ; vérifiez les paramètres de file du pilote (ethtool -l), le firmware et les paramètres noyau désactivant MSI.

4) Symptom: « Les saccades ont commencé après une mise à jour BIOS »

Cause : Le profil BIOS a réinitialisé et désactivé VT-d/IOMMU ou le remappage des interruptions ; parfois x2APIC a été basculé.

Correction : Réappliquez le profil BIOS connu bon ; vérifiez les logs DMAR/IVRS ; ajoutez des assertions au démarrage.

5) Symptom: « Tout s’est amélioré sauf une VM qui a encore des saccades »

Cause : Les vCPUs de cette VM sont pinés sur le même CPU qui gère les interruptions NVMe ou NIC ; ou un périphérique passthrough particulier utilise un chemin IRQ différent.

Correction : Alignez le pinning vCPU avec l’affinité IRQ ; isolez les cœurs IRQ hôte ; confirmez le MSI‑X et le statut IR du périphérique passé.

6) Symptom: « Désactiver irqbalance a empiré les choses »

Cause : Vous avez désactivé l’équilibrage sans le remplacer par un plan d’affinité délibéré ; les interruptions sont revenues aux valeurs par défaut.

Correction : Soit configurez irqbalance avec des CPUs bannis pour protéger les vCPUs, soit gérez l’affinité avec des règles persistantes (unit systemd) par groupe IRQ.

7) Symptom: « Une mise à jour du noyau a changé le comportement »

Cause : Le pilote a changé les valeurs par défaut de file ; des quirks MSI/MSI‑X ont changé ; la gestion de la topologie CPU/NUMA a évolué ; la politique irqbalance a changé.

Correction : Reprenez les vérifications de la section tâches. Ne supposez pas que la distribution d’interruptions d’hier persiste après des mises à jour.

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

Checklist A: Triage d’une hôte seul « saccade » (15 minutes)

1. Exécutez un filtre dmesg pour DMAR/IVRS et confirmez « Interrupt remapping enabled ».
2. Vérifiez /proc/interrupts et /proc/softirqs pour des points chauds CPU.
3. Pour les périphériques suspects (NIC/NVMe/USB/HBA), confirmez que MSI/MSI‑X est activé via lspci -vv.
4. Vérifiez si les threads vCPU de la VM sont sur les mêmes CPUs que le hotspot IRQ.
5. Répartissez temporairement l’affinité IRQ pour les IRQ chaudes et observez la réduction des saccades.

Checklist B: Correctif durable pour un nœud de virtualisation (contrôlé par changement)

1. Standardisez le profil BIOS : activez VT-d/AMD‑Vi et le remappage des interruptions.
2. Définissez les flags noyau : intel_iommu=on iommu=pt (ou équivalent AMD).
3. Redémarrez ; enregistrez les logs DMAR/IVRS dans l’inventaire du nœud.
4. Confirmez les comptes de vecteurs MSI‑X sur les NIC et NVMe ; assurez-vous que le multiqueue est actif.
5. Définissez l’allocation CPU : quels cœurs sont pour IRQ/softirq hôte, quels cœurs sont pour vCPUs.
6. Implémentez une politique d’affinité IRQ persistante (bans irqbalance ou masques explicites).
7. Retestez sous un trafic représentatif ; mesurez la latence p99, pas seulement le débit moyen.

Checklist C: Prévention à l’échelle du cluster

1. Ajoutez une vérification au démarrage qui alerte quand le remappage d’interruptions n’est pas activé.
2. Suivez les versions firmware et la dérive des paramètres BIOS ; ne comptez pas sur le « même modèle ».
3. Après les mises à jour noyau/driver, revalidez l’activation MSI‑X et les comptes de files sur un nœud canari.
4. Documentez une procédure de rollback incluant la cmdline du noyau et les profils BIOS.

FAQ

1) Le remappage des interruptions est-il requis pour de bonnes performances ?

Pas universellement, mais pour VFIO/passthrough et certains chemins modernes de livraison d’interruptions, c’est souvent la différence entre un usage propre de MSI/MSI‑X et un comportement de repli.
C’est aussi une frontière de sécurité. Si vous tenez à la latence tail et à la correction, activez-le.

2) J’ai activé l’IOMMU. Pourquoi vois-je encore des saccades ?

L’IOMMU activé ne garantit pas que vos interruptions sont bien distribuées. Vous pouvez avoir un remappage parfait et toujours canaliser toutes les interruptions de file sur CPU0.
Vérifiez /proc/interrupts, /proc/softirqs et les masques d’affinité IRQ.

3) Quelle est la différence pratique entre MSI et MSI‑X ?

MSI offre typiquement un petit nombre de vecteurs ; MSI‑X prend en charge de nombreux vecteurs. De nombreux vecteurs permettent des interruptions par file, ce qui laisse la NIC/NVMe évoluer avec les cœurs et réduire la contention.
Pour les E/S haut débit modernes, MSI‑X est l’état normal visé.

4) iommu=pt rend-il les choses dangereuses ?

Il réduit l’overhead de traduction pour les périphériques non isolés, mais il ne « désactive » pas l’existence de l’IOMMU. Pour les périphériques VFIO, vous obtenez toujours l’isolation.
La posture de sécurité dépend de votre configuration complète ; ne l’utilisez pas comme substitut à la compréhension de votre modèle de menace.

5) Dois-je désactiver irqbalance ?

Si vous utilisez l’isolation/pinning CPU pour les VMs, vous devriez au minimum contrôler irqbalance. Un irqbalance non contrôlé peut saboter l’isolation.
Soit configurez-le pour éviter vos cœurs vCPU, soit désactivez-le et définissez l’affinité IRQ de façon persistante.

6) Pourquoi CPU0 a-t-il toujours l’air coupable ?

CPU0 gère souvent les tâches de maintenance et obtient l’affinité par défaut pour beaucoup d’interruptions. Il n’est pas malveillant ; il est juste pratique.
La praticité est un mauvais plan de performance.

7) Un contrôleur USB peut-il vraiment provoquer des saccades VM ?

Oui. Un contrôleur USB bruyant (ou un périphérique dessus) peut générer des interruptions qui volent du temps CPU, surtout si ces interruptions sont concentrées sur un cœur exécutant des vCPUs.
C’est moins courant que NIC/NVMe, mais suffisamment réel pour être vérifié.

8) Comment savoir si je retombe sur INTx ?

Regardez /proc/interrupts pour des lignes IO-APIC liées à votre périphérique, et confirmez l’activation MSI/MSI‑X dans lspci -vv.
Si MSI‑X montre Enable- ou si vous voyez une seule ligne d’interruption là où vous en attendez beaucoup, suspectez une retombée.

9) Ma VM utilise uniquement virtio. Est-ce que ça m’intéresse encore ?

Oui, car l’hôte gère toujours les interruptions des périphériques physiques (NICs, NVMe, HBAs) qui sous-tendent virtio.
Même sans passthrough, une mauvaise distribution des interruptions peut priver les threads vhost et l’exécution des vCPU.

10) Quelle est la confirmation la plus rapide que vos changements ont fonctionné ?

Vous devez voir : DMAR indique le remappage d’interruptions activé, les périphériques montrent MSI‑X activé avec le nombre attendu de vecteurs, et la charge IRQ/softirq est répartie sur les CPUs prévus.
Puis validez avec une mesure de latence tail : p99/p999 dans l’invité, pas seulement le débit moyen sur l’hôte.

Conclusion : prochaines étapes déployables aujourd’hui

Les saccades aléatoires des VM sont souvent des problèmes de topologie d’interruptions déguisés. MSI/MSI‑X et le remappage des interruptions ne sont pas des fonctionnalités de niche ;
ce sont la tuyauterie qui permet aux périphériques modernes de s’étendre sans transformer un CPU en salle de crise.

Prochaines étapes pratiques :

1. Sur un hôte qui saccade, confirmez que DMAR/IVRS affiche « Interrupt remapping enabled ». Sinon, corrigez le firmware + les flags noyau.
2. Confirmez que vos périphériques chauds (NIC/NVMe) ont MSI‑X activé et plusieurs vecteurs.
3. Vérifiez /proc/interrupts et /proc/softirqs pour des hotspots CPU ; n’acceptez pas « le CPU est bas » comme preuve.
4. Alignez l’affinité IRQ avec le pinning vCPU : dédiez des cœurs aux interruptions hôte, gardez les cœurs VM propres.
5. Rendez cela durable : versionnez les profils BIOS, ajoutez des assertions au démarrage et revérifiez après les mises à jour.

Faites cela une fois, correctement, et vous arrêterez de traiter la « saccade » comme une histoire de fantômes. Ce n’est que du routage.