Intel VT-d vs AMD-Vi: ¿Cuál ofrece realmente mejor passthrough?

febrero 18, 2026 • febrero 18, 2026 • Lectura: 28 min • Views: 0

¿Te fue útil?

El passthrough PCIe es una característica que en una diapositiva parece determinista y en producción se comporta como el tiempo.
Un día tu VM con GPU es una ciudadana ejemplar; al siguiente se queda en pantalla negra al reiniciarla y tu ventana de mantenimiento se convierte en una sesión grupal de terapia.

La pregunta “¿Es Intel VT-d mejor que AMD-Vi?” suele surgir justo después de comprar hardware y justo antes de arrepentirse de al menos una configuración del BIOS.
La respuesta real tiene menos que ver con logos y más con comportamientos específicos de la plataforma: agrupamiento IOMMU, remapeo de interrupciones, calidad del firmware y cuánto necesitas un aislamiento limpio de dispositivos.

Qué significa realmente “mejor passthrough”

“Mejor passthrough” no es una única métrica. En producción te importan cuatro cosas, en este orden aproximado:

Corrección del aislamiento: el dispositivo está en su propio grupo IOMMU, el DMA está contenido y los resets se comportan.
Estabilidad operativa: reinicios, migraciones en vivo (donde aplique), recargas de controladores y actualizaciones del kernel no se convierten en tickets de incidentes.
Consistencia del rendimiento: baja fluctuación bajo carga y latencia predecible, especialmente para NVMe, NICs y GPUs.
Gestionabilidad: buena visibilidad con herramientas, logs sensatos y menos “flags especiales de arranque” que se convierten en conocimiento tribal.

Si estás montando un laboratorio casero, puedes tolerar hacks como ACS override y “simplemente no reinicies la VM dos veces seguidas”.
Si lo haces para un negocio—especialmente con cargas reguladas—tu “solución de passthrough” es un sistema, no una casilla marcada.

VT-d vs AMD-Vi: resumen con opinión

Tanto Intel VT-d como AMD-Vi (la IOMMU de AMD) pueden ofrecer un excelente passthrough. Las mayores diferencias que notarás no son teóricas.
Son detalles de implementación de la plataforma: firmware de la placa base, topología PCIe, agrupamiento IOMMU y si el remapeo de interrupciones está sólido.

Mi recomendación por defecto

Si necesitas passthrough de grado empresarial y aburrido (NICs SR-IOV, HBAs, NVMe, GPUs en flota): elige la plataforma con el mejor historial de placa + BIOS, no el proveedor del CPU.
En la práctica, eso suele significar plataformas Intel en servidores certificados por fabricantes, y plataformas AMD en servidores EPYC modernos con firmware maduro.
Si compras equipo de consumo: los sistemas AMD suelen ofrecer más núcleos por dólar, pero también mayor variabilidad en el agrupamiento IOMMU según chipset y enrutamiento de la placa.
Las placas Intel de consumo pueden ser más predecibles, aunque aún encontrarás el ocasional “grupo de puerto raíz compartido”.
Si dependes de grupos IOMMU limpios y no puedes tolerar ACS override: prioriza plataformas que expongan más puertos raíz PCIe y un aislamiento descendente más limpio.
Eso tiene menos que ver con “Intel vs AMD” y más con “esta placa y generación de CPU específicas”.

Aquí va la versión franca: el mejor passthrough es el passthrough que puedes reiniciar.
Si no puedes reiniciar en frío el host, reiniciar el guest y volver a adjuntar el dispositivo repetidamente sin rarezas, no tienes una solución—tienes una demo.

Cómo funciona realmente el passthrough IOMMU (y dónde falla)

El passthrough es un contrato de tres partes:

El dispositivo hace DMA y genera interrupciones.
La IOMMU traduce las direcciones DMA del dispositivo mediante tablas de páginas, restringiendo qué memoria física puede tocar el dispositivo.
El hipervisor (KVM/QEMU vía VFIO en Linux, o un hipervisor tipo 1) vincula el dispositivo a un guest y programa los mapeos de la IOMMU.

Cuando funciona, tu guest puede manejar el dispositivo casi como si fuera bare metal, pero el host mantiene límites de seguridad DMA.
Cuando no funciona, los modos de fallo son… educativos:

Mal agrupamiento: tu GPU y tu controlador USB comparten un grupo IOMMU; no puedes pasar uno sin el otro de forma segura.
Fallo de reset: el guest se apaga, el dispositivo no se reinicia correctamente y el siguiente arranque se queda atascado en “Starting bootloader…” o en pantalla negra.
Problemas de interrupciones: la entrega de MSI/MSI-X se vuelve rara; el rendimiento cae o la latencia se dispara; algunos dispositivos solo funcionan con ciertos parámetros de kernel.
Fallos de página: aparecen fallos de IOMMU en dmesg; el driver del guest está bien, pero los mapeos o comportamientos ATS/PRI no coinciden con lo esperado.

Además: el passthrough es un problema de topología.
Dos CPUs idénticas con placas base diferentes pueden comportarse como especies distintas, porque el diseño PCIe determina qué dispositivos están detrás de qué puertos raíz y bridges,
y eso determina agrupamientos y dominios de reset.

Broma #1: El passthrough PCIe es sencillo—hasta que lo intentas.

Hechos interesantes y contexto histórico (la versión corta y útil)

Estos no son datos para la noche de trivialidades. Explican por qué existen ciertos errores y peculiaridades de plataforma.

VT-d llegó después de VT-x: la virtualización de CPU (VT-x) no fue suficiente para un DMA seguro, así que VT-d rellenó la laguna para I/O dirigido.
AMD-Vi aparece como “IOMMU” en los logs de Linux: Linux a menudo informa la implementación de AMD bajo el nombre genérico IOMMU, y verás “AMD-Vi” en dmesg en muchos sistemas.
El remapeo de interrupciones es una característica de fiabilidad: no es solo rendimiento—sin ello, puedes verte forzado a modos de interrupción menos seguros o funcionales.
ACS es una característica de PCIe, no de la IOMMU: Access Control Services puede ayudar a hacer cumplir el aislamiento entre puertos descendentes; la ausencia de ACS suele provocar agrupamientos feos.
“ACS override” es una solución en Linux: puede dividir los grupos IOMMU fingiendo que existe aislamiento ACS. A veces está bien; otras veces es una autogol.
SR-IOV hizo a la IOMMU algo mainstream: cuando las NICs empezaron a presentar múltiples funciones virtuales, la corrección de la IOMMU dejó de ser nicho y pasó a ser imprescindible en centros de datos.
DMAR es la tabla ACPI de Intel para IOMMU: si las tablas DMAR están mal, VT-d puede estar “habilitado” pero ser efectivamente poco fiable.
AMD IOMMU usa tablas IVRS: de forma similar, entradas IVRS defectuosas pueden llevar a dispositivos faltantes, mapeos rotos o una topología de grupos confusa.
El dolor del reset de GPU es en parte histórico: muchas GPUs nunca fueron diseñadas para resets frecuentes a nivel de función en entornos virtualizados, así que heredas supuestos de hardware del mundo bare-metal.

Diferencias de plataforma que cambian resultados

1) Calidad de los grupos IOMMU: el hacedor silencioso de reyes

Tu mejor caso: cada dispositivo que quieras pasar está solo en su grupo IOMMU (o comparte solo con funciones inofensivas del mismo dispositivo, como el audio de la GPU).
El peor caso: la mitad de la placa base es un solo grupo porque el firmware expone una topología grosera o los switches PCIe no soportan ACS.

Intel vs AMD aquí no es un concurso moral. Es sobre la combinación de:
complejos raíz PCIe integrados en el CPU, carriles del chipset, switches/retimers PCIe a bordo y el enrutamiento de la placa.
Las placas de servidor tienden a ser más limpias que las de consumo. Las placas de estación de trabajo pueden ser un paraíso o un carnaval.

2) Remapeo de interrupciones: la diferencia entre “bien” y “¿por qué la latencia es variable?”

Con passthrough quieres que las interrupciones MSI/MSI-X se entreguen limpiamente al guest. El remapeo de interrupciones ayuda a mantener eso coherente y seguro.
Sin él, puedes ver advertencias en dmesg, retrocesos o restricciones. Cuando la gente describe “jitter” en dispositivos passthrough, las interrupciones a menudo están involucradas.

3) ATS/PRI y afines: cuando los dispositivos se vuelven listos

Algunos dispositivos pueden participar activamente en la traducción de direcciones (ATS) o solicitar páginas (PRI). En teoría, esto mejora el rendimiento.
En la práctica, amplía la superficie para peculiaridades de plataforma. Si persigues fallos raros de IOMMU bajo carga, estas características pueden ser relevantes.
No necesitas memorizar acrónimos; necesitas reconocer patrones y saber dónde mirar.

4) Dominios de reset y soporte FLR

Function Level Reset (FLR) facilita mucho la gestión del ciclo de vida del passthrough.
Si tu dispositivo no puede reiniciarse limpiamente, obtendrás el síntoma clásico: el primer arranque funciona, el segundo falla hasta reiniciar el host.
Esto afecta tanto a sistemas Intel como AMD porque a menudo es limitación del dispositivo, no de la IOMMU.

5) Madurez del firmware: el BIOS es parte de tu hipervisor

En el papel, VT-d y AMD-Vi son tecnologías maduras. En realidad, la calidad del firmware varía desde “sólida” hasta “alguien lo envió un viernes”.
Una placa puede anunciar soporte IOMMU y aun así tener tablas IVRS/DMAR rotas o valores por defecto cuestionables.
Actualiza el BIOS temprano y trata las notas de la versión como retrospectivas de incidentes—porque eso es lo que son.

Rendimiento: dónde se esconde la sobrecarga

Con passthrough, el rendimiento bruto suele estar cerca del bare metal. Los asesinos son:

Latencia y jitter por manejo de interrupciones, planificación y desajustes NUMA.
Coste de mapeo DMA cuando la memoria del guest está fragmentada o la carga churnea mapeos.
Ubicación NUMA incorrecta: pasar un dispositivo conectado al nodo NUMA 1 a un guest fijado al nodo 0 es una caída lenta.
Hugepages vs no: las hugepages reducen la presión de TLB y pueden disminuir la sobrecarga de mapeo para algunas cargas.

Si comparas Intel y AMD puramente por “rendimiento de passthrough”, probablemente estás midiendo lo incorrecto.
El diferenciador real es cuán fácil es hacer que el sistema sea estable y predecible bajo tu carga y patrones de reinicio.

Seguridad y fiabilidad: lo que obtienes cuando está correcto

La IOMMU es un límite de seguridad. Sin ella, un dispositivo con capacidad DMA puede leer/escribir la memoria del host directamente.
Con ella, el dispositivo queda restringido a un mapeo definido por el kernel/hipervisor del host.

Eso importa para:

Anfitriones multi-tenant (incluso “tenants” dentro de la misma empresa).
Controladores no confiables en guests (especialmente stacks de GPU y aceleradores nicho).
Contención de mal comportamiento del dispositivo (bugs de firmware, DMA perezoso, etc.).

Un encuadre útil de fiabilidad: el passthrough es seguro cuando tu IOMMU es estricta, tu agrupamiento es limpio y los resets del ciclo de vida son correctos.
Pierde cualquiera de esos, y pasarás el tiempo inventando rituales en vez de ejecutar servicios.

Una cita para mantenerte honesto: La esperanza no es una estrategia. — Rick Pitino

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

Estas son centradas en Linux, porque es donde vive la mayoría del passthrough VFIO/KVM y donde depurarás a las 02:00.
Los comandos son ejecutables en distribuciones modernas; ajusta nombres de paquetes según tu entorno.

Tarea 1: Confirma la CPU y las banderas de virtualización

cr0x@server:~$ lscpu | egrep -i 'Vendor ID|Model name|Virtualization|Flags'
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) CPU
Virtualization:        VT-x
Flags:                 ... vmx ...

Qué significa: “Virtualization: VT-x” (Intel) o “AMD-V” (AMD) te dice que la virtualización de CPU existe. No prueba que la IOMMU esté habilitada.

Decisión: Si la virtualización no está presente, detente. No vas a hacer passthrough en ese host de forma sensata.

Tarea 2: Confirma que la IOMMU está habilitada en el kernel (Intel VT-d)

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|VT-d' | head -n 30
[    0.612345] DMAR: IOMMU enabled
[    0.612678] DMAR: Host address width 46
[    0.613210] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.615432] DMAR: Interrupt remapping enabled

Qué significa: “DMAR: IOMMU enabled” es la línea clave. “Interrupt remapping enabled” es un fuerte indicio de que tendrás menos casos raros de interrupciones.

Decisión: Si no ves líneas DMAR, revisa ajustes del BIOS y parámetros del kernel (tareas posteriores). No depures VFIO hasta que esto esté correcto.

Tarea 3: Confirma que la IOMMU está habilitada en el kernel (AMD-Vi)

cr0x@server:~$ dmesg | egrep -i 'AMD-Vi|IOMMU|IVRS' | head -n 40
[    0.501234] AMD-Vi: IOMMU performance counters supported
[    0.501567] AMD-Vi: Lazy IO/TLB flushing enabled
[    0.504321] ivrs: IOAPIC[4] not in IVRS table

Qué significa: Las líneas AMD-Vi indican que el driver de IOMMU de AMD está activo. Las advertencias IVRS pueden ser inofensivas o un olor a firmware según la gravedad.

Decisión: Si los logs muestran repetidas quejas IVRS/IOAPIC y el passthrough es inestable, actualiza el BIOS y considera otra placa antes de perder una semana.

Tarea 4: Verifica la línea de comandos del kernel (intel_iommu / amd_iommu)

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

Qué significa: intel_iommu=on (o amd_iommu=on) habilita la IOMMU. iommu=pt pone dispositivos del host en modo pass-through para menor sobrecarga manteniendo traducción para guests.

Decisión: Para hosts de virtualización, iommu=pt suele ser un buen valor por defecto. Si depuras aislamiento de dispositivos o fallos, puedes quitarlo temporalmente para comparar comportamiento.

Tarea 5: Confirma grupos IOMMU y detecta “compartición mala”

cr0x@server:~$ find /sys/kernel/iommu_groups/ -maxdepth 2 -type l | sed 's#.*/##' | sort | head
0000:00:01.0
0000:00:14.0
0000:00:14.2
0000:01:00.0
0000:01:00.1

Qué significa: Esto lista dispositivos en grupos IOMMU. Necesitas inspeccionar a qué grupo pertenece cada dispositivo y si tu dispositivo objetivo está aislado.

Decisión: Si tu GPU/NVMe/NIC objetivo comparte grupo con dispositivos no relacionados que no puedes pasar también, o cambias de ranura, cambias placa, o aceptas el riesgo del ACS override.

Tarea 6: Imprime grupos con nombres legibles

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; for d in $g/devices/*; do lspci -nns ${d##*/}; done; echo; done | sed -n '1,40p'
Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1234] (rev 02)

Group 1
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:5678] (rev 02)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba] (rev a1)

Qué significa: Buscas “solo las funciones de la GPU” en un grupo, no la GPU más SATA más USB más un bridge aleatorio con amigos.

Decisión: Agrupamiento limpio? Procede con VFIO. Agrupamiento desordenado? Considera otra ranura PCIe (a menudo cambia el puerto raíz), o una placa diferente.

Tarea 7: Comprueba si tu dispositivo soporta señales de reset (FLR)

cr0x@server:~$ lspci -s 01:00.0 -vv | egrep -i 'Capabilities:|FLR|Reset' -n | head -n 20
45:Capabilities: [1b0] Vendor Specific Information: ID=0001 Rev=1 Len=024
78:Capabilities: [1e0] Device Serial Number 00-00-00-00-00-00-00-00
92:Capabilities: [250] Latency Tolerance Reporting
110:Capabilities: [300] Secondary PCI Express
132:Capabilities: [400] Physical Resizable BAR
160:Capabilities: [420] Data Link Feature

Qué significa: No todos los dispositivos anuncian claramente FLR en un grep obvio. Algunos mostrarán “Function Level Reset” explícitamente; otros no.

Decisión: Si tu GPU muestra mal comportamiento de reset en la práctica, planifica mitigaciones: módulos de reset por proveedor (cuando aplique), evitar patrones de reinicio en caliente o seleccionar un modelo de GPU conocido por reiniciarse bien.

Tarea 8: Identifica el driver actualmente ligado a un dispositivo PCI

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5110
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: Si “Kernel driver in use” es el driver del proveedor, no lo has entregado aún a VFIO.

Decisión: Para passthrough, vincúlalo a vfio-pci en el host y mantén la gráfica del host en otra tarjeta (iGPU o GPU separada).

Tarea 9: Vincular un dispositivo a vfio-pci (persistente vía configuración modprobe)

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:2684,10de:22ba disable_vga=1
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0

Qué significa: Estás diciendo al host que vincule esos IDs PCI a vfio-pci temprano en el arranque. La actualización del initramfs asegura que surta efecto.

Decisión: Si dependes de la GPU para la consola del host, no hagas esto. Usa una iGPU o serial/IPMI. De lo contrario te bloquearás de forma definitiva.

Tarea 10: Confirma el enlace vfio-pci después del reinicio

cr0x@server:~$ lspci -k -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2684 (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5110
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: “Kernel driver in use: vfio-pci” es lo que quieres. “Kernel modules” puede seguir listando módulos del proveedor; eso está bien.

Decisión: Si no está vinculado, revisa initramfs, pon en la lista negra drivers conflictivos y confirma la política de Secure Boot si interfiere con la carga de módulos en tu entorno.

Tarea 11: Busca fallos de IOMMU y errores de remapeo DMA

cr0x@server:~$ sudo dmesg -T | egrep -i 'DMAR|IOMMU|fault|vfio|remapping' | tail -n 30
[Tue Feb  4 01:12:11 2026] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[Tue Feb  4 01:13:09 2026] DMAR: [DMA Read] Request device [01:00.0] fault addr 0x7f2b0000 [fault reason 05] PTE Read access is not set

Qué significa: Los fallos DMA indican problemas de mapeo o comportamiento del dispositivo que viola los mapeos actuales. A veces es un driver de guest mal configurado; otras veces son peculiaridades de la plataforma.

Decisión: Si los fallos se correlacionan con crashes del guest o bloqueos del dispositivo, prioriza estabilidad sobre ajustes. Revisa el aislamiento de grupos, la versión del kernel y considera deshabilitar características avanzadas (como ATS) si tu plataforma lo permite.

Tarea 12: Confirma hugepages (higiene de latencia para guests)

cr0x@server:~$ grep -i huge /proc/meminfo | head
AnonHugePages:    1048576 kB
HugePages_Total:      256
HugePages_Free:       200
HugePages_Rsvd:        10
Hugepagesize:       2048 kB

Qué significa: Esto muestra si hay hugepages explícitas provisionadas. Muchas cargas sensibles a latencia con passthrough funcionan mejor con backing de memoria predecible.

Decisión: Si ves micro-tartamudeos bajo carga en una VM GPU o VM de procesamiento de paquetes, las hugepages son una palanca razonable—tras haber arreglado agrupamiento IOMMU y colocación NUMA.

Tarea 13: Comprueba la localidad NUMA de un dispositivo pasado

cr0x@server:~$ cat /sys/bus/pci/devices/0000:01:00.0/numa_node
1

Qué significa: El dispositivo reside en el nodo NUMA 1. Si los vCPUs y la memoria de tu VM están en el nodo 0, pagarás una penalización cross-socket.

Decisión: Fija los vCPUs y la memoria de la VM al nodo NUMA del dispositivo cuando sea posible. Si no puedes, reconsidera en qué ranura está el dispositivo (algunas ranuras mapean a raíces de CPU diferentes).

Tarea 14: Inspecciona la topología PCIe para entender causas de agrupamiento

cr0x@server:~$ lspci -t
-[0000:00]-+-00.0
           +-01.0-[01]----00.0
           +-14.0
           \-1c.0-[02]----00.0-[03]----00.0

Qué significa: Esto muestra el árbol de bridges. Los dispositivos detrás del mismo bridge descendente a menudo caen en el mismo grupo IOMMU a menos que ACS esté disponible y habilitado.

Decisión: Si tu GPU comparte bridge con dispositivos críticos del host, muévela a una ranura conectada a un puerto raíz distinto, o te quedarás negociando con la física.

Tarea 15: Verifica que VFIO está cargado y qué módulos están activos

cr0x@server:~$ lsmod | egrep 'vfio|kvm' | head
vfio_pci               65536  0
vfio_pci_core          90112  1 vfio_pci
vfio_iommu_type1       45056  0
vfio                   45056  2 vfio_pci_core,vfio_iommu_type1
kvm_intel             409600  0

Qué significa: VFIO core y type1 IOMMU están cargados. Si faltan, tu host no está listo para passthrough incluso si el BIOS está configurado.

Decisión: Carga los módulos, arregla initramfs y confirma que tu kernel tiene soporte VFIO. No intentes configuraciones de guest hasta que la base del host esté estable.

Tarea 16: Comprueba si el kernel usa remapeo de interrupciones

cr0x@server:~$ dmesg | egrep -i 'interrupt remapping|IR:' | head
[    0.615432] DMAR: Interrupt remapping enabled

Qué significa: En Intel esto es explícito. En AMD puedes ver una redacción distinta. De cualquier manera, buscas indicios de que el manejo moderno de interrupciones está habilitado.

Decisión: Si el remapeo de interrupciones está deshabilitado y ves inestabilidad o advertencias de seguridad, considera toggles del BIOS relacionados con VT-d/IOMMU de AMD y remapeo de interrupciones, y vuelve a probar.

Guion rápido de diagnóstico

Cuando el passthrough está roto, no empiezas reescribiendo tu configuración QEMU. Empiezas demostrando que la plataforma es capaz de estar correcta.
Aquí está el flujo “encontrar el cuello de botella rápido” que uso.

Primero: ¿La IOMMU está realmente activada y sensata?

Revisa /proc/cmdline por intel_iommu=on o amd_iommu=on.
Revisa dmesg por “IOMMU enabled” y cualquier queja de tablas DMAR/IVRS.
Confirma que los módulos VFIO se cargan.

Segundo: ¿Son aceptables los grupos IOMMU?

Enumera grupos en /sys/kernel/iommu_groups.
Verifica que tu dispositivo objetivo esté aislado o solo agrupado con sus propias funciones.
Si no lo está: cambia de ranura, deshabilita dispositivos a bordo no usados o acepta que la placa no sirve para este requisito.

Tercero: ¿Es esto una rareza de reset/firmware y no “tuning de VFIO”?

¿El primer arranque del VM funciona pero los posteriores fallan? Huele a problemas de reset/FLR.
¿Necesitas un reboot del host para recuperar el dispositivo? Eso es dolor de dominio de reset.
Actualiza BIOS. Luego actualiza kernel. Luego retesta. No cambies doce variables a la vez.

Cuarto: ¿Es NUMA/latencia de interrupciones que se disfraza de “passthrough lento”?

Revisa el nodo NUMA del dispositivo y alinea el pinning de la VM en consecuencia.
Mira el estado del remapeo de interrupciones y problemas MSI/MSI-X en los logs.
Sólo después: considera hugepages, aislamiento de CPU del host y ajuste del scheduler.

Broma #2: La IOMMU no “se rompió aleatoriamente.” Esperó hasta que estabas confiado.

Errores comunes: síntoma → causa raíz → arreglo

1) “VFIO funciona una vez, luego pantalla negra en segundo arranque”

Síntoma: El guest arranca y usa la GPU una vez. Tras apagar/reiniciar, la GPU nunca se inicializa de nuevo hasta reiniciar el host.

Causa raíz: El dispositivo no soporta un FLR limpio o el reset no se propaga a través del bridge; común con algunas GPUs de consumo.

Arreglo: Prefiere GPUs conocidas por resets amigables con virtualización; prueba otra ranura (cambia dominio de reset); actualiza BIOS; considera un módulo de workaround de reset si aplica; evita bucles de reinicio rápidos.

2) “El dispositivo está en un grupo IOMMU gigante con SATA/USB; no puedo pasarlo con seguridad”

Síntoma: Tu GPU comparte un grupo IOMMU con el controlador SATA del chipset y el controlador USB.

Causa raíz: No hay aislamiento ACS en el camino descendente relevante; la placa enruta múltiples funciones detrás de un bridge; el firmware expone un agrupamiento grosero.

Arreglo: Mueve la tarjeta a una ranura enraizada en el CPU; deshabilita dispositivos a bordo no usados; elige otra placa con mejor aislamiento PCIe. Usa ACS override solo si aceptas el trade-off de seguridad y estabilidad.

3) “Alto throughput pero latencia/jitter horrible”

Síntoma: Benchmarks NVMe van bien, pero la latencia de la aplicación se dispara; tiempos de frame de GPU irregulares; procesamiento de paquetes NIC entrecortado.

Causa raíz: Desajuste NUMA, problemas de manejo de interrupciones, contención en el host, falta de hugepages.

Arreglo: Alinea vCPU y memoria del guest con el nodo NUMA del dispositivo; asegura remapeo de interrupciones y que MSI/MSI-X funcionen; aisla CPUs del host para guests sensibles; usa hugepages para el guest.

4) “IOMMU está habilitada pero no aparecen grupos”

Síntoma: dmesg menciona IOMMU, pero /sys/kernel/iommu_groups está vacío o falta.

Causa raíz: Kernel arrancó sin parámetros de IOMMU; virtualización deshabilitada en BIOS; o hay un desajuste de modo kernel/boot (raro, pero ocurre).

Arreglo: Verifica toggles del BIOS (VT-d/IOMMU de AMD); verifica /proc/cmdline; actualiza kernel; asegúrate de no estar ejecutando un kernel recortado.

5) “Fallos de IOMMU bajo carga”

Síntoma: Aparecen fallos DMAR/AMD-Vi en dmesg durante I/O intenso; el guest se congela o el dispositivo cae.

Causa raíz: Bugs de firmware de plataforma, enlace PCIe inestable o interacción desafortunada de características avanzadas de traducción.

Arreglo: Actualiza BIOS y kernel; asienta la tarjeta; reduce la velocidad del enlace PCIe como prueba; verifica la entrega de energía; considera deshabilitar características avanzadas si tu stack provee toggles seguros. Si persiste, reemplaza la placa antes de normalizarla.

6) “El host pierde red o almacenamiento cuando arranco la VM”

Síntoma: Al iniciar una VM con passthrough, los servicios del host mueren.

Causa raíz: Pasaste el dispositivo equivocado (o el correcto que está en el mismo grupo que dispositivos críticos del host) porque se ignoró el agrupamiento.

Arreglo: Revisa los grupos IOMMU, vincula solo los IDs de dispositivo objetivo y mantiene los controladores críticos del host fuera de los grupos de passthrough. Si no puedes, el hardware no es apropiado para este diseño.

Tres micro-historias corporativas desde las trincheras

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

Una compañía mediana quería passthrough de GPU para un puñado de estaciones de trabajo de anotación ML ejecutándose como VMs.
El plan parecía simple: un host por equipo, una GPU por VM, escalado fácil.
Compras adquirió un lote de máquinas “listas para virtualización” porque la hoja de especificaciones del CPU decía soporte VT-d o AMD-Vi.

La primera semana fue bien. La segunda semana, tras parches rutinarios, empezaron los tickets: pantallas negras tras reinicio de VM, desconexiones aleatorias de USB y un host que se negaba a arrancar una VM si un hub USB específico estaba enchufado.
El equipo supuso que era “un problema de drivers” y pasó días culpando a actualizaciones del OS del guest.

La falla real fue la topología: la GPU y el controlador USB estaban en el mismo grupo IOMMU en esa placa base.
El “arreglo” que aplicaron por accidente fue reiniciar el host frecuentemente, lo que temporalmente limpiaba el estado de reset y enmascaraba el problema.
Una vez correlacionaron las fallas con los grupos IOMMU, el patrón fue embarazosamente consistente.

Terminaron moviendo GPUs a ranuras diferentes donde fue posible y, para un subconjunto de hosts, reemplazando el modelo de placa por completo.
La lección no fue “Intel vs AMD.” La lección fue: una lista de características del CPU no garantiza passthrough. El producto es la placa.

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

Otra organización ejecutaba una VM de appliance de almacenamiento virtualizada con un HBA pasado, más una NIC de alto rendimiento pasada para tráfico de replicación.
Perseguían unos puntos porcentuales de throughput y decidieron “optimizar” habilitando todas las características de rendimiento en BIOS: ajustes agresivos de energía, estados C más profundos y algunos knobs de rendimiento de IOMMU.

El throughput mejoró en un benchmark sintético. La latencia empeoró en producción.
Las ventanas de replicación empezaron a no cumplir sus objetivos y, peor aún: la VM de almacenamiento ocasionalmente registró timeouts de I/O bajo carga máxima.
Nada estaba completamente roto, lo que hizo más caro depurarlo porque parecía “la red comportándose raro”.

La causa raíz fue una combinación de gestión de energía e interacción de latencia de interrupciones con la NIC de passthrough.
Los vCPUs de la VM también estaban fijados en el nodo NUMA equivocado respecto a la NIC, así que cada interrupción era efectivamente una pequeña negociación cross-socket.
Habían optimizado la métrica equivocada y luego la desplegaron contra la única métrica que importa: la latencia vista por el usuario.

Revertir las “optimizaciones”, alinear el pinning NUMA y usar un perfil de energía conservador restauró la estabilidad.
La parte más divertida (en tono seco) fue que el sistema original estaba bien; su triunfo en el benchmark creó el incidente.

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

Una firma financiera ejecutaba un clúster de hosts de virtualización con cargas mixtas, incluidas algunas VMs con NICs en passthrough para captura de paquetes especializada.
Al principio trataron los hosts de passthrough como mascotas—afinados a mano, configurados con cariño e imposibles de reproducir.
Eventualmente se cansaron de sorpresas y estandarizaron.

La “práctica aburrida” fue una lista de verificación preflight ejecutada en cada host nuevo y después de cada actualización de BIOS:
confirmar IOMMU activada, confirmar remapeo de interrupciones, volcar grupos IOMMU, snapshot de la topología PCIe y registrar parámetros del kernel conocidos como buenos.
Nada glamuroso. Solo disciplina.

Luego una actualización de BIOS del proveedor cambió silenciosamente el orden de enumeración PCIe en un subconjunto de máquinas.
Sin el preflight lo habrían descubierto durante una ventana de mantenimiento en producción cuando dispositivos se adjuntaron a diferentes grupos y las antiguas vinculaciones VFIO tomaron el controlador equivocado.
Con el preflight lo detectaron en staging, ajustaron bindings y despacharon sin drama.

Su sistema no se volvió más rápido. Se volvió predecible. En operaciones, eso suele ser la mejor ganancia.

Listas de verificación / plan paso a paso

Paso a paso: seleccionar hardware para passthrough (para no comprar arrepentimientos)

Empieza por el modelo de placa base, no por el CPU. Verifica si la gente reporta grupos IOMMU limpios para los dispositivos y ranuras que planeas usar.
Prefiere ranuras PCIe enraizadas en la CPU para dispositivos de passthrough (GPU, adaptador NVMe, NIC). Las ranuras enraizadas en el chipset suelen agruparse más agresivamente.
Evita plataformas que requieran ACS override para un aislamiento básico. Si debes usarlo, documenta explícitamente la aceptación del riesgo.
Planifica acceso a la consola del host: iGPU, BMC/IPMI o serial. No dependas de la GPU pasada para acceso al host.
Presupuesta actualizaciones de firmware: elige proveedores con historial de mantenimiento de BIOS para estabilidad, no solo microcódigo de CPU.

Paso a paso: línea base de configuración del host (Linux + KVM/VFIO)

Habilita VT-d/IOMMU de AMD en BIOS/UEFI. También habilita cualquier ajuste llamado “interrupt remapping” si está presente.
Arranca con intel_iommu=on iommu=pt o amd_iommu=on iommu=pt.
Confirma que dmesg muestre IOMMU habilitada y sin errores serios de tablas DMAR/IVRS.
Confirma grupos IOMMU; verifica aislamiento del dispositivo objetivo.
Vincula IDs del dispositivo objetivo a vfio-pci en initramfs.
Fija CPU/memoria de la VM al nodo NUMA correcto si la latencia importa.
Prueba el ciclo de vida: arranca VM, somete a carga, apaga, arranca otra vez. Repite hasta aburrirte. Aburrirse es la meta.

Paso a paso: decidir entre passthrough y dispositivos paravirtualizados

Usa virtio cuando puedas (disco, red). Es más simple y a menudo “lo suficientemente rápido”.
Usa passthrough cuando debas (funciones especiales de NIC, cómputo/gráficos GPU, drivers que requieren acceso a la función física, HBAs para appliances de almacenamiento).
En caso de duda, evita pasar controladores críticos del host. Si pasas el único HBA que contiene el OS del host, estás a un error de una reinstalación remota.

Preguntas frecuentes

1) ¿Es Intel VT-d inherentemente más estable que AMD-Vi?

No inherentemente. La estabilidad depende sobre todo de la implementación de la plataforma: tablas de firmware (DMAR/IVRS), topología PCIe y comportamiento de reset del dispositivo.
En plataformas de servidor certificadas, ambos pueden ser muy estables. En placas de consumo, ambos pueden ser caóticos—solo que de maneras diferentes.

2) ¿Por qué mis grupos IOMMU son “peores” en una placa que en otra?

Porque el agrupamiento está influenciado por bridges PCIe, switches y la capacidad ACS a lo largo del camino.
Una placa que enruta múltiples ranuras detrás de un bridge descendente (sin ACS) pegará dispositivos en un mismo grupo.
Otra placa con más puertos raíz o mejor aislamiento ACS producirá grupos más limpios.

3) ¿Debería usar ACS override?

Sólo si entiendes el trade-off: puede hacer que los grupos parezcan aislados incluso cuando el hardware no aplica separación completa.
Para laboratorios caseros suele ser aceptable. Para entornos con requisitos de aislamiento más fuertes, es un riesgo que no deberías normalizar.

4) ¿Reduce `iommu=pt` el aislamiento del guest?

Normalmente hace que los mapeos DMA propios del host sean identidad/passthrough por rendimiento mientras sigue usando traducción para dispositivos asignados a guests.
Se usa comúnmente en hosts de virtualización. Si depuras o validas estrictitud, puedes probar sin él.

5) ¿Por qué falla el passthrough de GPU tras reiniciar una VM?

Normalmente por comportamiento de reset: la GPU no se reinicia limpiamente (sin FLR usable, o el reset no se propaga), quedando en un estado malo.
A veces también es interacción driver/firmware. La solución fiable es elegir hardware conocido por ser amigable en reset, más una topología correcta.

6) ¿SR-IOV es más fácil en plataformas Intel o AMD?

El éxito de SR-IOV depende mucho del modelo/firmware de la NIC, madurez del driver y corrección de la IOMMU.
Tanto Intel como AMD pueden ejecutar SR-IOV bien. La experiencia “más fácil” suele venir de NICs empresariales y placas de servidor con BIOS maduras.

7) ¿Cuál es la forma más rápida de saber si el passthrough será indoloro en un host?

Revisa grupos IOMMU y prueba ciclos de reinicio. Si el dispositivo está limpiamente aislado y puedes reiniciar el guest repetidamente sin reiniciar el host, estás en un 80% del camino.
El 20% restante es ajuste de rendimiento y manejo de casos límite.

8) ¿Importan las versiones del kernel para passthrough VT-d/AMD-Vi?

Sí. IOMMU, VFIO y quirks de PCIe reciben correcciones con el tiempo. Si persigues fallos raros o problemas de reset, kernels más nuevos pueden ayudar.
Simplemente actualiza de forma metódica: una variable a la vez, con plan de reversión.

9) ¿Es buena idea pasar un disco NVMe?

Puede ser excelente para rendimiento y para appliances de almacenamiento que quieren control directo.
Pero los NVMe pueden compartir grupos IOMMU con otros dispositivos del chipset en algunas placas, y debes evitar pasar cualquier cosa que el host necesite para arrancar.

10) ¿Debo elegir Intel o AMD para un build Proxmox/KVM con passthrough?

Elige la placa + plataforma que genere grupos limpios para tus dispositivos objetivo y que tenga buen soporte de firmware.
Si ya tienes el hardware, evalúalo con las tareas de inspección de grupos arriba antes de diseñar el servicio alrededor.

Pasos prácticos siguientes

Si estás decidiendo entre Intel VT-d y AMD-Vi para passthrough, no lo trates como una preferencia de marca.
Trátalo como un problema de cadena de suministro: escoge una plataforma donde la topología de la placa y la madurez del firmware coincidan con tus necesidades de aislamiento.

Para builds nuevos: preselecciona placas y luego verifica la calidad reportada de los grupos IOMMU para tus tipos de dispositivo y ranuras exactas.
Para hosts existentes: ejecuta las tareas de enumeración de grupos, confirma el remapeo de interrupciones y prueba ciclos de reinicio bajo carga.
Para despliegues en producción: estandariza una lista de verificación preflight, controla actualizaciones de BIOS y kernel, y documenta qué ranuras son “seguras para passthrough”.

La condición de victoria no es “máximo throughput.” Es “sin sorpresas al reiniciar.” Cuando logras eso, tanto VT-d como AMD-Vi se ven bastante bien.