iommu=pt: El modo oculto de rendimiento para virtualización en Linux (cuándo usarlo)

febrero 12, 2026 • febrero 12, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

Compras CPUs rápidas, NICs rápidas, NVMe rápidos y luego tu “plataforma de virtualización” funciona como si llevara un piano escaleras arriba.
Picos de latencia. Ritmos de paquetes inestables. IOPS de almacenamiento que se ven bien en un benchmark y raros en producción.
Alguien dice “tal vez es el IOMMU” y la sala se queda en silencio, porque esa frase es a la vez cierta y cara.

iommu=pt es uno de esos interruptores del kernel de Linux que puede sentirse como performance gratis—hasta que no lo es.
Puede reducir la sobrecarga en la ruta de mapeo DMA, especialmente bajo cargas intensas de virtualización de E/S.
También puede eliminar silenciosamente protecciones de las que dependías, o empeorar mucho tu historia de depuración.
Esta es la guía de campo: cuándo activarlo, cuándo no hacerlo y cómo demostrar que estás arreglando el problema correcto.

Qué hace realmente `iommu=pt` (no lo que internet piensa)

El IOMMU (Input-Output Memory Management Unit) es el MMU para dispositivos. Traduce direcciones visibles para el dispositivo (IOVAs)
a direcciones físicas del host, y hace cumplir aislamiento para que un dispositivo no haga DMA donde le plazca.
En virtualización, es un bloque central para el passthrough seguro de PCI (VFIO), el aislamiento SR-IOV y a veces
incluso para “solo virtio” dependiendo de tu stack.

Linux soporta múltiples modos operativos del IOMMU. Los detalles varían según arquitectura y driver (Intel VT-d, AMD-Vi,
arm-smmu, etc.), pero el patrón general es:

Modo traducido: los dispositivos hacen DMA a través de tablas de páginas del IOMMU; el kernel configura mapeos y puede hacer
aislamiento por dispositivo.
Modo passthrough: los dispositivos usan mapeos “identidad” (o equivalente) de modo que las traducciones DMA son
efectivamente 1:1 y la sobrecarga de mapeo se reduce.
Deshabilitado: no hay traducción del IOMMU; las funciones de aislamiento desaparecen y algunas características avanzadas de virtualización
dejan de funcionar.

iommu=pt pide a Linux que por defecto use mapeos de passthrough para dispositivos que no están asignados
a invitados (y a veces incluso antes de la asignación, dependiendo del driver y del ciclo de vida del dispositivo). No significa “sin IOMMU”.
Significa “mantén el IOMMU activado, pero evita la sobrecarga de traducción donde el aislamiento no es necesario.”

La sutileza: cuando más tarde enlazas un dispositivo a VFIO y lo asignas a una VM, el kernel aún usa modo traducido para ese
dispositivo (porque necesitas aislamiento entre invitado y host). La ganancia suele ser sobre todo en el resto: dispositivos del host,
el comportamiento por defecto de mapeo DMA y la cantidad de churn de mapeo en el IOMMU cuando ejecutas una caja ocupada con mucha E/S.

Por eso iommu=pt puede ayudar incluso cuando no haces passthrough completo de PCI. Algunas cargas generan una enorme
actividad de map/unmap DMA (stacks de red, almacenamiento, procesamiento de paquetes en userspace, ciertos drivers de GPU/aceleradores).
Si esas rutas llegan al IOMMU en modo traducido, puedes pagar en ciclos CPU, presión de caché, invalidaciones de IOTLB, y
ocasionalmente “por qué ksoftirqd me está comiendo el almuerzo”.

Una forma práctica de pensarlo:
iommu=pt intercambia algo de comportamiento de aislamiento por defecto por menor sobrecarga de traducción y gestión.
Es una perilla de rendimiento con una factura en seguridad y depuración adjunta.

Dos términos que la gente confunde: “IOMMU habilitado” vs. “Remapeo DMA habilitado”

Muchas plataformas muestran toggles relacionados con IOMMU en firmware con etiquetas vagas: “IOMMU,” “VT-d,” “DMA remapping,” “SVM,” “AMD-Vi.”
A menudo puedes tener extensiones de virtualización activas mientras el remapeo DMA está apagado. Los invitados todavía funcionan, pero el aislamiento
de dispositivos y el passthrough seguro se complican. En Linux, intel_iommu=on (o amd_iommu=on) puede forzarlo, mientras que
iommu=off lo desactiva en el kernel.

Mantén esto claro porque los modos de falla se parecen: cambios de rendimiento, VFIO deja de funcionar o los logs del kernel se llenan
de quejas DMAR/IOMMU. Pero las soluciones difieren.

Exactamente una cita (parafraseada, porque la precisión importa)

Idea parafraseada (atribuida a Gene Kim): “El trabajo de mejora debe estar ligado a resultados, y necesitas bucles de retroalimentación lo bastante rápidos para dirigir.”

Por qué existe el IOMMU: una breve historia con aristas

Si tratas a los IOMMUs como “solo un impuesto de rendimiento,” acabarás con un sistema rápido que también es una pistola con el seguro quitado.
Un poco de contexto histórico te ayuda a entender por qué existe el impuesto y cuándo es razonable evitarlo.

Hechos y contexto interesantes (8 puntos)

Los IOMMU preceden al hype moderno de la virtualización. Originalmente importaban para sistemas que necesitaban DMA de dispositivos hacia
memoria más allá de lo que los dispositivos podían direccionar directamente, y para remapeo en topologías de bus complejas.
Intel VT-d y AMD-Vi formalizaron el remapeo DMA como característica de plataforma. Esto fue crítico para la asignación segura de dispositivos
a VMs: sin aislamiento DMA, el “passthrough” es básicamente “por favor garabatea en mi hypervisor.”
El passthrough PCI temprano era frágil porque las interrupciones y el aislamiento DMA eran frágiles. MSI/MSI-X, remapeo
y el aislamiento apropiado por grupos IOMMU fueron parte de volverlo aburrido.
La DMA API de Linux abstrajo el mapeo, pero el backend IOMMU puede hacerlo caro. Los drivers llaman a las APIs de mapeo
y esperan que sean “suficientemente baratas.” Bajo carga intensa, “suficientemente barato” se vuelve discutible.
El IOTLB existe porque los dispositivos también cachean traducciones. Cuando los mapeos cambian, puede que necesites invalidaciones.
Las tormentas de invalidación son reales y aparecen como picos de latencia.
SR-IOV cambió el radio de blast. Ahora puedes tener muchas VFs haciendo DMA, y cada VF puede tener sus propias necesidades de mapeo.
Genial para densidad. También genial para encontrar el camino lento.
Usuarios de redes de alta tasa en userspace (DPDK, XDP, AF_XDP) presionan la estrategia de mapeo. Pinnear memoria y usar
hugepages es tanto para evitar churn de mapeo como para mitigar fallos de TLB.
La investigación en seguridad volvió los ataques DMA algo común. “Periférico malicioso” no es solo trama de película; es un modelo de amenaza creíble
en entornos multi-tenant y en sitios con acceso físico.

Broma #1 (corta, relevante): El IOMMU es como el guardia de seguridad de tu RAM. Es caro, pero evita que la NIC pasee por las áreas VIP.

Quién debería usar `iommu=pt` (y quién debería mantener las manos alejadas)

Aquí está la versión opinativa: usa iommu=pt cuando puedas medir la sobrecarga del IOMMU y controles el radio de blast.
No lo uses porque viste un comentario en un foro que terminó con “me lo arregló a mí.”

Buenos candidatos

Hosts de virtualización dedicados con passthrough VFIO donde la mayoría de dispositivos permanecen en el host y quieres reducir la
sobrecarga por defecto de traducción DMA para dispositivos del host.
Nodos de red de alta tasa de paquetes haciendo SR-IOV, DPDK, AF_XDP o virtio-net pesado con aceleración vhost, donde has
verificado que el tiempo se gasta en mapear/desmapear o invalidaciones de IOTLB.
Hypervisors pesados en almacenamiento con muchas completions NVMe, colas e interrupciones, donde los ciclos CPU gastados en mapeo DMA
son medibles y afectan la latencia en la cola.
Entornos de inquilino único donde el modelo de amenaza son accidentes operacionales y no DMA malicioso.

Mala idea para

Entornos multi-tenant o con inquilinos hostiles donde el aislamiento DMA forma parte de tu historia de seguridad. Aún puedes usar IOMMU y
seguir haciendo VFIO de forma segura, pero el “passthrough por defecto” es una decisión de política. Hazlo deliberadamente, no por casualidad.
Hosts que dependen de aislamiento DMA estricto incluso para dispositivos del host (piensa: periféricos no confiables, hotplug, ubicaciones edge, laboratorios
con hardware misterioso).
Sistemas donde la depuración ya es difícil. Si vives en un pantano de problemas de E/S intermitentes, reducir el aislamiento puede convertir
“intermitente” en “no reproducible.”

Si piensas “pero no somos multi-tenant,” recuerda: siempre eres multi-interesado. Los equipos de seguridad, cumplimiento y respuesta a incidentes estarán en tu futuro.
Déjales un sistema que tenga sentido.

Qué ganas vs. qué riesgosas

La ventaja: de dónde viene el rendimiento

El IOMMU añade trabajo en varias formas:

Sobrehead de mapeo: El kernel (o un driver) necesita crear mapeos IOVA para DMA. Bajo carga, esa gestión cuesta CPU.
Invalidaciones de IOTLB: Cuando los mapeos cambian, dispositivos y el IOMMU necesitan invalidaciones; esas pueden serializar y causar picos de latencia.
Ventanas DMA efectivas más pequeñas: Defaults pobres pueden causar fragmentación en el espacio IOVA o forzar bounce buffering.
Interacciones con remapeo de interrupciones: Algunas plataformas atan el remapeo de interrupciones a la habilitación del IOMMU; las configuraciones pueden
afectar la entrega y el overhead de interrupciones.

iommu=pt reduce el trabajo de mapeo para dispositivos “normales” del host al preferir mapeos tipo identidad. Eso puede:

Reducir la sobrecarga CPU en rutas de alta E/S.
Disminuir la latencia en cola causada por churn de invalidaciones.
Hacer algunas cargas menos sensibles a pequeños cambios de mapeo.

La desventaja: qué podrías romper (o debilitar)

Cambios en la postura de seguridad: Puedes perder protección DMA por defecto para algunos dispositivos. Si un dispositivo se comporta mal (bug o malicioso),
puede dirigirse más fácilmente a la memoria del host.
Menor capacidad de depuración: La traducción estricta puede detectar ciertas clases de bugs de driver/dispositivo (direcciones DMA inválidas).
Los mapeos de identidad pueden permitir que garabateen silenciosamente.
Asunciones en herramientas: Algunos entornos asumen “IOMMU on” implica “DMA del host protegido.” Con defaults passthrough,
esa asunción se vuelve falsa a menos que apliques traducción por dispositivo donde sea necesario.
Quirks hardware en casos límite: Algunos chipsets y dispositivos se comportan distinto con defaults passthrough, especialmente con
características ATS/PRI, remapeo de interrupciones o firmware extraño.

Broma #2 (corta, relevante): Cambiar modos IOMMU en producción es como reorganizar un centro de datos durante un simulacro de incendio—educativo, pero aprenderás palabras nuevas.

Guion de diagnóstico rápido

No activas iommu=pt porque estás aburrido. Lo activas porque tienes un cuello de botella y puedes explicarlo.
Este es el orden de operaciones que uso cuando un host de virtualización es “rápido salvo cuando no lo es.”

Primero: prueba si el problema es tiempo CPU, latencia o encolamiento

Busca saturación de CPU en softirq, kvm, vhost o trabajo relacionado con iommu.
Busca picos de latencia correlacionados con interrupciones de red/almacenamiento.
Busca crecimiento de profundidad de cola: anillos NIC, colas NVMe, blk-mq, colas vhost.

Segundo: confirma que el IOMMU está en la ruta y cómo está configurado

¿Está el IOMMU habilitado en firmware y kernel?
¿Estás usando modo traducido globalmente o defaults passthrough?
¿Los dispositivos críticos (asignados a VFIO) siguen aislados correctamente?

Tercero: identifica la ruta caliente (map/unmap vs. otra cosa)

Haz perfiles con perf para iommu_map/iommu_unmap y funciones de la DMA API.
Revisa el costo de invalidaciones IOTLB.
Revisa bounce buffering / uso de swiotlb, que a menudo indica una restricción de direccionamiento/mapeo.

Punto de decisión

Si puedes mostrar tiempo CPU significativo en mapeo DMA o invalidaciones del IOMMU en el host—y el modelo de seguridad lo permite—entonces
iommu=pt es un experimento razonable. Si no puedes mostrarlo, probablemente vas a optimizar un placebo.

Tareas prácticas: comandos, salidas y decisiones (12+)

Esto no es “ejecuta esto porque es divertido.” Cada tarea incluye qué buscar y qué decisión impulsa.
Ejecútalas en el host salvo que se indique lo contrario.

Tarea 1: Confirma la línea de comandos del kernel (qué arrancaste realmente)

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

Significado: Esto es la verdad de tierra. Si iommu=pt no está aquí, no lo estás probando.
Decisión: Si faltan parámetros o están en conflicto (como iommu=off), corrige la configuración del bootloader antes de hacer otra cosa.

Tarea 2: Revisa dmesg por modo IOMMU e inicialización DMAR/AMD-Vi

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

Significado: “Default domain type: Passthrough” es la prueba indiscutible de que iommu=pt tomó efecto (en rutas Intel VT-d).
Decisión: Si no lo ves, puedes estar en otro driver, el firmware podría estar deshabilitando funciones o el parámetro se ignora.

Tarea 3: Verifica que existan grupos IOMMU (y qué está aislado)

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

Significado: Si existen grupos, el IOMMU está al menos organizando unidades de aislamiento.
Decisión: No tener grupos suele significar que el IOMMU no está habilitado o no es soportado; la seguridad de VFIO passthrough se verá comprometida.

Tarea 4: Inspecciona el grupo de un dispositivo específico (¿es compartible o viene con amigos?)

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

Significado: La NIC tiene dos funciones en el mismo grupo; eso es común. El passthrough requiere controlar todo el grupo.
Decisión: Si el grupo contiene dispositivos no relacionados, puede que necesites cambiar el slot PCIe, ajustes BIOS ACS o aceptar “no hay passthrough.”

Tarea 5: Comprueba si VFIO está en uso y qué dispositivos están enlazados

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

Significado: La NIC está enlazada a vfio-pci; debería usar aislamiento traducido para el invitado incluso si el dominio por defecto es passthrough.
Decisión: Si un dispositivo pensado para el host está accidentalmente enlazado a vfio, espera pérdida de red/almacenamiento en el host y una reunión tensa.

Tarea 6: Comprueba el dominio por defecto del IOMMU (interfaz genérica cuando está disponible)

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

Significado: El dominio por defecto del IOMMU en el kernel es passthrough.
Decisión: Si dice translated (o similar), no estás en el modo que crees; valida parámetros del kernel y defaults de la distro.

Tarea 7: Busca uso de SWIOTLB (un clásico sumidero de rendimiento oculto)

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)

Significado: SWIOTLB es un mecanismo de bounce buffer. Puede aparecer por límites de direccionamiento DMA, configuración IOMMU o quirks de plataforma.
Decisión: Si ves uso intensivo de SWIOTLB durante carga (a menudo visible en perf), considera la colocación de memoria, BIOS “above 4G decoding” o ajuste del IOMMU.

Tarea 8: Comprueba si el remapeo de interrupciones está habilitado (implicaciones de estabilidad y seguridad)

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

Significado: El remapeo de IRQ está activado. Bueno para aislamiento y a veces requerido para passthrough estable en ciertos sistemas.
Decisión: Si está apagado inesperadamente, revisa ajustes de firmware y parámetros del kernel; algunas plataformas lo deshabilitan bajo configuraciones raras.

Tarea 9: Perfilado para hotspots IOMMU/ DMA mapping (prueba antes de política)

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

Significado: Esta es la evidencia que necesitas: tiempo CPU significativo dentro de mapping/unmapping.
Decisión: Si estas funciones están entre las principales durante tu carga real, iommu=pt es un experimento justificado. Si no, busca en otro lado.

Tarea 10: Comprueba tiempo CPU del host en softirq (el dolor de redes suele mostrarse aquí)

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

Significado: Un %soft alto a menudo indica trabajo de red o completions de bloque y trabajo impulsado por interrupciones.
Decisión: Si softirq es alto y perf muestra funciones IOMMU, la ruta de mapeo es un candidato; si softirq es alto pero IOMMU no aparece, enfócate en NIC/RPS/afinidad IRQ.

Tarea 11: Valida comportamiento de hugepages y memoria pinneada (especialmente para DPDK/VFIO)

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

Significado: Hay hugepages disponibles; esto reduce la presión de TLB y puede reducir churn de mapeo en frameworks de E/S en userspace.
Decisión: Si dependes de hugepages y se agotan bajo carga, verás una caída de rendimiento que parece “IOMMU lento.”

Tarea 12: Revisa CPU y comportamiento de hilos de procesos QEMU/KVM (no culpes al IOMMU por un vCPU pegado)

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

Significado: Un proceso VM y el hilo vhost están calientes, además de ksoftirqd en la misma CPU.
Decisión: Antes de tocar el IOMMU, arregla afinidad de CPU y distribución de IRQ. Si mantienes todo en la CPU 7, has construido un pequeño atasco.

Tarea 13: Inspecciona la distribución de IRQ para una NIC (tormentas de interrupciones se hacen pasar por “sobrecarga IOMMU”)

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

Significado: Hay interrupciones presentes y distribuidas entre CPUs (primeras columnas). Si todos los contadores están en una CPU, has encontrado una probable causa de latencia.
Decisión: Si la distribución es mala, ajusta afinidad IRQ y RPS/XPS; iommu=pt no salvará un atasco de interrupciones en un solo núcleo.

Tarea 14: Revisa fallos IOMMU (cuando problemas de rendimiento son en realidad errores)

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

Significado: Un fallo DMA real. Esto no es “tiempo de tuning,” esto es “tiempo de contención y corrección.”
Decisión: Para. Valida la asignación de dispositivos, la estabilidad del driver, el firmware y si el invitado/host está mal configurado. iommu=pt podría ocultarlo, no arreglarlo.

Tres micro-historias corporativas desde las trincheras

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana operaba una flota de hypervisors KVM con mezcla de dispositivos virtio y un puñado de NICs en passthrough VFIO para “tenants premium.”
Seguridad aprobó “IOMMU habilitado” como parte de su checklist de hardening. El equipo de infraestructura oyó la misma frase y la tradujo como
“podemos hacer passthrough de forma segura; el IOMMU está activado.”

Un despliegue de kernel nuevo incluyó iommu=pt. Se añadió como un ajuste de rendimiento tras una prueba de laboratorio que mostró reducción de uso CPU en cargas de red.
La nota de cambio decía “mantiene IOMMU activado, mejora rendimiento.” Todos asintieron. Nadie preguntó: “¿qué dispositivos siguen siendo traducidos por defecto?”

Semanas después investigaron un raro evento de corrupción de memoria del host. No frecuente. No reproducible. Del tipo que te obliga a beber café frío.
Tras suficiente arqueología de logs, el equipo encontró un patrón: los hosts afectados tenían un driver fuera del árbol para una tarjeta PCIe de monitorización.
Esa tarjeta hacía DMA a la dirección equivocada bajo ciertas condiciones de reset. En modo traducido estricto habría fallado ruidosamente. Con defaults passthrough,
garabateó en silencio.

La solución no fue “nunca usar iommu=pt.” La solución fue dejar de tratar “IOMMU activado” como un control de seguridad booleano.
Reemplazaron la combinación tarjeta/driver problemática y ajustaron el control de cambios alrededor de parámetros del kernel que afectan el aislamiento DMA.
También añadieron una comprobación post-boot que verifica el dominio por defecto y alerta cuando cambia inesperadamente.

Micro-historia 2: La optimización que salió mal

Una empresa ejecutaba infraestructura de trading de baja latencia en hosts dedicados. No eran multi-tenant, pero eran extremadamente sensibles al jitter.
Un ingeniero de rendimiento vio map/unmap en un perfil y decidió “quitar completamente la sobrecarga IOMMU.” Pusieron iommu=off en toda la flota.
El benchmark inicial se veía genial. La dirección obtuvo el gráfico que quería.

Luego pasaron una ventana de upgrade donde se aplicaron actualizaciones de firmware de NIC. Un host volvió con una topología PCIe ligeramente diferente y un quirk en el comportamiento de interrupciones.
Sin remapeo de interrupciones (a menudo ligado a habilitar IOMMU), tuvieron tormentas de interrupciones intermitentes y ocasionales interrupciones perdidas bajo carga.
El síntoma fue simple: pérdida esporádica de paquetes en el borde del host.

Intentaron afinar anillos, coalescing, afinidad IRQ, todos los palancas usuales. A veces ayudaba, a veces no.
El problema real fue que la plataforma había cruzado a una configuración menos probada para esa combinación NIC/firmware.
No era un “bug de Linux,” era “deshabilitaste una característica que la plataforma espera tener” bug.

Volvieron a intel_iommu=on iommu=pt. El rendimiento siguió bien y la estabilidad regresó.
La lección no fue “IOMMU siempre es bueno.” La lección fue “la plataforma es un sistema.” Quitar una pieza puede enfadar al resto.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de cloud operaba una plataforma privada de virtualización para cargas internas: runners CI, bases de datos y algunos hosts GPU para ML.
Tenían una estricta política “un cambio por deploy” para parámetros del kernel. Molestaba a desarrolladores. También los salvó.

Cuando experimentaron con iommu=pt, no empezaron por desplegar en masa. Empezaron por instrumentar:
perfiles perf bajo carga representativa, histogramas de latencia baseline, un conteo de fallos IOMMU desde dmesg, y
una exportación diaria simple de /proc/cmdline + dominio por defecto del IOMMU.

La prueba mostró una pequeña pero consistente caída de CPU del host para su carga CI intensiva en red. Genial. Lo rollaron a un cluster.
Dos días después, un host GPU empezó a lanzar fallos DMA durante resets de invitados. El equipo pudo correlacionarlo de inmediato:
el problema existía antes, pero en modo estricto fallaría antes; los defaults passthrough hicieron la falla más rara y más desagradable.

Porque tenían rollout escalonado y telemetría, el rollback fue limpio. Sin drama. Sin “creemos que es el kernel” hablando sin evidencia.
Aislaron el problema a un emparejamiento específico de firmware+driver GPU, lo corrigieron primero y luego reintrodujeron iommu=pt con confianza.
Las prácticas aburridas no te dan aplausos. Te dan sueño.

Errores comunes (síntomas → causa raíz → arreglo)

1) Síntoma: Passthrough VFIO falla tras habilitar `iommu=pt`

Causa raíz: Confundir iommu=pt con iommu=off, o el firmware no habilita realmente el remapeo DMA.
A veces el sistema arranca sin soporte IOMMU apropiado, así que VFIO se niega a adjuntar.

Arreglo: Verifica con dmesg que IOMMU esté habilitado, revisa que existan grupos, asegura intel_iommu=on o amd_iommu=on,
y confirma que VT-d/AMD-Vi esté activado en firmware.

2) Síntoma: Rendimiento mejoró, pero ahora obtienes crashes raros del host o corrupción de memoria

Causa raíz: Un dispositivo/driver buggy hizo DMA incorrectamente; la traducción estricta habría fallado, defaults passthrough lo permitieron.

Arreglo: Trata esto como corrección. Actualiza firmware/drivers, retira dispositivos problemáticos y considera mantener modo traducido para ciertas clases de dispositivo (o evita iommu=pt en hosts con periféricos dudosos).

3) Síntoma: Picos de latencia persisten incluso con `iommu=pt`

Causa raíz: El cuello de botella no era la traducción IOMMU; era afinidad IRQ, backlog de softirq, colocación de hilos vhost o problemas de driver en el invitado.

Arreglo: Usa /proc/interrupts, mpstat y perf para encontrar la ruta caliente real. Arregla pinning de CPU y distribución de IRQ primero.

4) Síntoma: SR-IOV VFs funcionan, pero el throughput es inconsistente entre VMs

Causa raíz: Restricciones de grupo IOMMU y limitaciones ACS llevan a colocación incómoda, o tienes modos de interrupción mezclados entre VFs.
A veces un subconjunto de VFs termina con distinta localidad NUMA y culpas al IOMMU.

Arreglo: Revisa grupos, nodo NUMA de los dispositivos PCI, distribución de IRQ y asegura que el pinning de vCPU de la VM alinee con la localidad del dispositivo.

5) Síntoma: Dmesg muestra fallos DMA tras un cambio de parámetro del kernel

Causa raíz: Un dispositivo ahora usa modo traducido con aplicación más estricta (o al revés), sacando a la luz un bug real.

Arreglo: No “tunees para esconderlo.” Identifica el dispositivo, driver y la carga que dispara el fallo. Valida la configuración VFIO y actualiza firmware.

Listas de verificación / plan paso a paso

Paso a paso: decidir si probar `iommu=pt`

Declara tu objetivo. Ejemplo: “Reducir CPU del host en 10% a 2Mpps por host manteniendo passthrough VFIO estable.”
Captura una línea base. Perfil perf, % softirq, latencia p99 para rutas clave (almacenamiento, red) y conteo de fallos dmesg.
Demuestra que existe sobrecarga IOMMU. Busca mapping/unmapping y invalidaciones IOTLB en perf durante la carga real.
Confirma el modelo de amenaza. ¿Single-tenant? ¿Hardware controlado? Si no, consigue la aprobación de seguridad y documenta el tradeoff.
Despliegue en etapas. Un host, una pool, un cluster. Facilita el rollback.
Valida aislamiento para dispositivos VFIO. Asegura que los dispositivos asignados sigan usando VFIO con grupos correctos.
Monitorea tras el cambio. Vigila fallos DMA, inestabilidad del host y latencia en cola.

Lista de implementación: hacer el cambio limpamente

Configura firmware VT-d/AMD-Vi y (si aplica) “Above 4G decoding” apropiadamente.
Establece parámetros del kernel: intel_iommu=on iommu=pt o amd_iommu=on iommu=pt según corresponda.
Reinicia y luego verifica con /proc/cmdline y dmesg.
Verifica que existan grupos IOMMU y que los dispositivos VFIO estén en grupos correctos.
Re-ejecuta tus mediciones baseline y compara.

Checklist de rollback

Quita iommu=pt y reinicia.
Confirma que el dominio por defecto no sea pt (translated o default de la distro).
Re-revisa el binding de dispositivos VFIO y la funcionalidad de invitados.
Compara logs de fallos y regresión de latencia/CPU con la baseline.

Preguntas frecuentes

1) ¿Desactiva `iommu=pt` el IOMMU?

No. Mantiene el IOMMU activado pero pide mapeos por defecto de estilo passthrough/identidad para dispositivos no asignados.
Los dispositivos asignados a VFIO aún necesitan aislamiento traducido.

2) ¿Cuándo es más probable que `iommu=pt` ayude?

Cuando tu host gasta tiempo CPU significativo en map/unmap DMA o en rutas de invalidación del IOMMU bajo carga real—común en redes de alta tasa de paquetes,
altas tasas de completions de almacenamiento o frameworks de E/S en userspace.

3) ¿Es `iommu=pt` seguro para entornos multi-tenant?

“Seguro” depende de la política y la confianza hardware. Si tu modelo de seguridad depende del aislamiento DMA para dispositivos del host, los defaults passthrough son un riesgo.
En setups multi-tenant, haz esto una decisión deliberada y revisada con controles compensatorios.

4) ¿Cómo se diferencia `iommu=pt` de `intel_iommu=on`?

intel_iommu=on fuerza la habilitación Intel VT-d. iommu=pt establece el tipo de dominio de mapeo por defecto.
A menudo se usan juntos: fuerzas habilitar, luego eliges passthrough por defecto.

5) ¿Mejorará `iommu=pt` el rendimiento de virtio?

A veces de forma indirecta. Virtio en sí es paravirtual, pero el comportamiento DMA del host para dispositivos de backing y rutas vhost puede implicar trabajo IOMMU.
Mide. Si perf no muestra sobrecarga IOMMU, no esperes milagros.

6) ¿Cuál es el mayor riesgo operativo de habilitar `iommu=pt`?

Enmascarar o habilitar bugs relacionados con DMA y debilitar el aislamiento por defecto para dispositivos del host. Lo aterrador es que las fallas pueden volverse menos frecuentes y más destructivas.

7) Si el rendimiento es malo, ¿debería simplemente usar `iommu=off`?

Normalmente no. Deshabilitar el IOMMU elimina protecciones y puede romper VFIO, expectativas de aislamiento SR-IOV y el comportamiento de remapeo de interrupciones en algunas plataformas.
Si necesitas rendimiento, iommu=pt es la herramienta más quirúrgica—pero aún con tradeoffs.

8) ¿Cómo pruebo que `iommu=pt` es la razón del mejor rendimiento?

Usa comparaciones antes/después bajo la misma carga: perfiles perf (tiempo de mapping/unmapping), utilización CPU y latencia en cola.
También verifica que el dominio por defecto cambió a passthrough en dmesg o sysfs.

9) ¿Puede `iommu=pt` hacer que los dispositivos queden en diferentes grupos IOMMU?

No. Los grupos los determina la topología hardware (comportamiento ACS de PCIe, aislamiento del root port), no el dominio por defecto passthrough.
Si tus grupos están mal, arregla topología/ACS/slotting, no el modo de mapeo del kernel.

10) ¿Cuál es una señal de que no debería tocar los knobs del IOMMU en absoluto?

Si tu cuello de botella es claramente otra cosa: una CPU caliente por afinidad IRQ, mala configuración de driver en el invitado, encolamiento de almacenamiento o problemas de scheduling.
Arregla lo obvio primero.

Conclusión: próximos pasos que no te harán famoso por razones equivocadas

iommu=pt no es un interruptor mágico de velocidad. Es una decisión de política: mantener IOMMU activado, reducir la sobrecarga de traducción donde el aislamiento no es necesario,
y aceptar que has cambiado los rieles de seguridad por defecto.

Pasos prácticos siguientes:

Ejecuta el guion de diagnóstico rápido y obtén un perfil perf bajo carga real. Si el mapeo IOMMU no está caliente, detente aquí.
Si map/unmap está caliente, prueba iommu=pt en un host. Valida: cmdline, dmesg dominio por defecto, bindings VFIO y ausencia de fallos DMA.
Compara CPU y latencia en cola con la baseline. Si no obtienes una ganancia significativa, revierte y sigue buscando—tu cuello de botella está en otro lado.
Si lo mantienes, documenta el trade-off de seguridad, añade una comprobación post-boot para el dominio por defecto y vigila dmesg por fallos DMA como si fuera tu trabajo (porque lo es).