Passthrough de controlador USB que realmente permanece estable (IOMMU + reasignación de interrupciones)
febrero 28, 2026 • febrero 28, 2026 • Lectura: 27 min • Views: 0
¿Te fue útil?
Has pasado directamente un controlador USB completo porque estás harto de que el “passthrough de dispositivos USB” falle cada vez que el dispositivo tiene un desliz.
Funciona durante un día. Luego la VM pierde el teclado, el dongle desaparece o el host registra una tormenta de resets como si estuviera expulsando un demonio.
El passthrough estable de un controlador USB no es cuestión de suerte. Es cuestión de corrección de IOMMU, reasignación de interrupciones, aislamiento limpio y negarse a ser ingenioso en los lugares incorrectos. Hagámoslo aburrido—y por tanto fiable.
Qué significa realmente “estable” para el passthrough USB
“Estable” no es “arrancó una vez.” Estable es:
Sin desconexiones inesperadas durante la reenumeración del dispositivo (común en interfaces de audio, lectores de tarjetas inteligentes, SDR, dongles HID).
Sin bloqueos del host cuando el guest reinicia el controlador o un dispositivo se comporta mal.
Latencia predecible sin tartamudeos periódicos debido a tormentas de interrupciones o conflictos con drivers del host.
Suspend/resume y reinicios del guest que sobreviven sin dejar el controlador atascado hasta un reinicio del host.
Pertenencia limpia: o el host posee el controlador o lo posee el guest. No ambos “a veces”.
El passthrough de un controlador USB es “passthrough de dispositivo PCIe con maneras extra de fallar.” Los controladores se reinician, los endpoints renegocian,
los hubs mienten y el silicio de bajo coste interpreta la especificación creativamente. Si tratas el passthrough USB como una casilla para marcar,
obtendrás fiabilidad de casilla.
Broma #1: USB significa “Usualmente Se Portan Bien”—hasta que intentas virtualizarlo.
Hechos e historia interesantes que puedes usar
USB 1.1 usaba controladores OHCI/UHCI de host; USB 2.0 estandarizó en EHCI más controladores complementarios para dispositivos low/full-speed.
xHCI (USB 3.x) unificó el desorden: un modelo de controlador para low/full/high/super speed. Genial para sistemas operativos, pero las rutas de reset y gestión de energía son más complejas.
La reasignación de interrupciones se volvió imprescindible cuando empezamos a dar acceso directo a dispositivos a las VMs; sin ella, un dispositivo puede inyectar interrupciones de forma insegura.
VT-d (Intel) y AMD-Vi (AMD IOMMU) resuelven el aislamiento de DMA, pero las primeras generaciones tuvieron problemas con ATS/PRI y el enrutamiento de interrupciones.
MSI/MSI-X reemplazó en gran medida a INTx para dispositivos PCIe modernos; es buena noticia para el passthrough, pero solo si la reasignación está habilitada y funciona correctamente.
ACS (Access Control Services) en switches/puertos raíz PCIe influye en la separación de grupos IOMMU; las plataformas de consumo suelen recortar esquinas aquí.
Los controladores USB pueden compartir silicio con otras funciones (SATA, Ethernet, audio), creando grupos IOMMU multifunción que resisten un passthrough limpio.
“Passthrough de dispositivo USB” y “passthrough de controlador USB” son universos distintos: uno es emulación/proxy, el otro es propiedad real del hardware.
La arquitectura real: IOMMU, DMA, interrupciones y por qué USB es especial
El passthrough de controladores USB es una historia de DMA e interrupciones
Cuando pasas un controlador USB PCIe (xHCI/EHCI), le estás entregando un dispositivo capaz de DMA al guest. El driver del guest
programa el controlador con direcciones físicas (“físicas” del guest, traducidas por el hipervisor/IOMMU), y el controlador
hace DMA hacia la memoria del guest. Ese es el objetivo: eliminar al host del camino de datos.
Esto funciona cuando se cumplen dos condiciones:
El aislamiento de DMA es correcto. El controlador debe alcanzar solo la memoria del guest, no la del host, y las traducciones no deben fallar bajo carga.
La entrega de interrupciones es correcta. Las interrupciones del controlador deben llegar al guest de forma fiable, sin quedarse “atascadas”, enrutadas incorrectamente o causando tormentas en el host.
Dónde se rompe en la práctica
La inestabilidad suele provenir de una (o combinación) de estas causas:
Falta de reasignación de interrupciones (o está desactivada/bugguy), lo que provoca entrega MSI insegura o poco fiable en escenarios de passthrough.
Contaminación de grupos IOMMU: el controlador comparte grupo con algo que el host debe mantener (o que el guest no debería obtener).
Gestión de energía: ASPM, runtime PM y USB autosuspend interactúan mal con el passthrough, especialmente en placas de consumo.
Semántica de reset: algunos controladores xHCI no se reinician limpiamente vía FLR (Function Level Reset) y pueden quedar atascados hasta un ciclo completo de energía.
Quirks del kernel y propiedad del driver: el host captura el controlador temprano (xhci_hcd), luego VFIO intenta enlazarlo más tarde; los resultados varían de bien a inestables.
Configuraciones de firmware/BIOS: IOMMU habilitado pero “reasignación de interrupciones” apagada; o “Above 4G decoding” desactivado; o tablas de enrutamiento PCIe defectuosas.
Qué debes buscar
Una configuración estable tiene estas propiedades:
El controlador USB está solo en su grupo IOMMU (o agrupado solo con hermanos inocuos que puedas pasar juntos).
El host nunca carga su driver normal para ese controlador; VFIO lo posee desde el arranque temprano.
IOMMU está habilitado y funcionando en un modo que soporte la traducción DMA a escala (sin caer en fallback).
La reasignación de interrupciones está habilitada y confirmada en los logs del kernel.
Se usa MSI/MSI-X (controladores modernos), y se evita INTx heredado a menos que sepas por qué lo haces.
Una idea parafraseada que la gente de operaciones aprende a las malas: idea parafraseada: “La esperanza no es una estrategia.” — a menudo atribuida a varios líderes de fiabilidad; el punto sigue siendo válido.
Reasignación de interrupciones: el héroe silencioso
La reasignación de interrupciones es la parte que muchas guías tratan como un adorno opcional. No es opcional cuando te importa la estabilidad.
En el mundo VFIO, “funciona” sin ella a veces, hasta que escalas interrupciones, saturas I/O o encuentras un edge case de dispositivo/firmware.
Qué hace realmente la reasignación de interrupciones
Con PCIe, los dispositivos típicamente usan interrupciones MSI/MSI-X: escrituras a una pareja dirección/dato específica que la plataforma interpreta como una interrupción.
Sin reasignación, esas escrituras pueden estar mal acotadas. Con reasignación, el IOMMU/el reasignador de interrupciones provee una capa de traducción para que
el hipervisor pueda encaminar de forma segura y fiable las interrupciones del dispositivo al vector/CPU correcto del guest.
Modos de fallo que verás cuando la reasignación está ausente o rota
Caídas aleatorias de dispositivos cuando cambia la carga (chasquidos de audio, retraso en HID, resets de dongles).
“Congelamientos” del guest donde el dispositivo está vivo pero las interrupciones dejan de llegar, por lo que el driver agota tiempos.
El dmesg del host muestra fallos de IOMMU o síntomas tipo “IRQ stuck”.
VFIO se niega a arrancar la VM con advertencias sobre interrupciones inseguras, dependiendo de la configuración del kernel.
Conclusión: si tu plataforma no hace la reasignación de interrupciones correctamente, deja de intentar forzarla. Cambia la plataforma o aísla la carga.
Gastarás menos dinero que el tiempo que perderás intentando arreglarlo a la fuerza.
Decisiones de hardware que deciden tu destino
Elige controladores conocidos por comportarse bien
Si puedes elegir el controlador USB, escoge uno con reputación de comportamiento de reset limpio y entrega MSI estable.
En el campo, las tarjetas USB PCIe discretas suelen ser más fáciles que los controladores integrados porque:
tienden a aislarse en su propio grupo IOMMU y es menos probable que compartan líneas/funciones.
Además: evita pasar el único controlador USB de la plataforma si el host lo necesita para acceso de consola de emergencia.
Dale al host su propio camino USB “aburrido” (incluso un controlador USB2 básico) y pasa un controlador xHCI separado al VM.
El firmware de la placa importa más de lo que quieres
Dos placas con el mismo chipset pueden comportarse de forma muy distinta debido a configuraciones BIOS y calidad de tablas ACPI/PCIe del proveedor.
Busca específicamente:
Intel VT-d / AMD IOMMU habilitado.
Reasignación de interrupciones habilitada (a veces llamada “IRQ remapping” o incluida bajo VT-d).
Above 4G decoding habilitado en sistemas con muchos dispositivos PCIe.
SR-IOV no afecta directamente a USB, pero las placas que lo exponen tienden a ser menos “de juguete”.
CSM/Arranque legacy desactivado si es posible; solo UEFI suele ser más limpio para virtualización moderna.
No uses “ACS override” para escapar de la física salvo que sea necesario
ACS override puede dividir grupos IOMMU en software pretendiendo que existen características ACS donde no las hay.
Es tentador. También aumenta el radio de explosión si un dispositivo se comporta mal, porque el aislamiento pasa a ser aspiracional.
Si este es un sistema de tipo producción, evita ACS override salvo que hayas aceptado el riesgo y puedas tolerar las consecuencias.
Broma #2: Activar ACS override para “arreglar” grupos es como etiquetar una caja de cartón “segura” y llamarla caja fuerte ignífuga.
Tareas prácticas: comandos, salidas esperadas y decisiones
Estas son las tareas que realmente ejecuto cuando alguien dice: “El passthrough USB es inestable.” Cada tarea incluye:
un comando, qué significa la salida y la decisión que tomas a partir de ello.
Task 1: Confirmar que IOMMU está habilitado en la línea de comandos del kernel
Significado: Quieres ver intel_iommu=on (Intel) o amd_iommu=on (AMD). iommu=pt es común para reducir la sobrecarga para dispositivos del host usando mappings de passthrough.
Decisión: Si las banderas IOMMU no están presentes, añádelas en tu gestor de arranque y reinicia. Sin IOMMU, no hay passthrough confiable.
Task 2: Verificar que la IOMMU se inicializó realmente (no confíes en la cmdline)
Significado: La línea clave es “IOMMU enabled” y “Interrupt remapping enabled.” En AMD verás mensajes AMD-Vi/IOMMU.
Decisión: Si no ves la reasignación de interrupciones habilitada, ve al BIOS/UEFI y arréglalo. Si la plataforma no puede, considéralo un punto de parada para la estabilidad.
Task 3: Buscar advertencias de “no interrupt remapping” o “unsafe interrupts”
Significado: “No interrupt remapping support” es la bandera roja. La línea de VFIO es ruido normal.
Decisión: Si la plataforma carece de remapeo, a veces puedes limitarte, pero debes esperar problemas esporádicos. Para producción, reemplaza el hardware.
Task 4: Identificar la dirección PCI y el vendor/device ID del controlador USB
cr0x@server:~$ lspci -nn | egrep -i 'usb|xhci|ehci'
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
00:14.0 USB controller [0c03]: Intel Corporation 200 Series PCH USB 3.0 xHCI Controller [8086:a2af]
Significado: Ahora tienes el BDF (03:00.0) y el ID (1b21:2142).
Decisión: Preferir pasar una tarjeta discreta (03:00.0) en lugar del integrado del chipset (00:14.0).
Task 5: Comprobar el aislamiento de IOMMU groups
cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename "$g")"; ls -l "$g/devices"; done | sed -n '1,40p'
Group 13
total 0
lrwxrwxrwx 1 root root 0 Feb 4 09:12 0000:03:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:03:00.0
Group 7
total 0
lrwxrwxrwx 1 root root 0 Feb 4 09:12 0000:00:14.0 -> ../../../../devices/pci0000:00/0000:00:14.0
lrwxrwxrwx 1 root root 0 Feb 4 09:12 0000:00:14.2 -> ../../../../devices/pci0000:00/0000:00:14.2
Significado: El Grupo 13 contiene solo 03:00.0—bien. El Grupo 7 contiene 00:14.0 y 00:14.2—funciones compartidas.
Decisión: Pasa dispositivos que estén aislados, o pasa todo el grupo. No extraigas quirúrgicamente una función de un grupo multifunción.
Task 6: Ver qué driver posee actualmente el controlador
cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Subsystem: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
Significado: El driver del host (xhci_hcd) lo posee actualmente. Eso no es lo que queremos para passthrough.
Decisión: Vincula este dispositivo a vfio-pci temprano, antes de que xHCI lo capture, o desvincúlalo/revínculalo con cuidado.
Task 7: Vincular el controlador a vfio-pci (método en tiempo de ejecución)
Significado: Hemos desvinculado del driver actual y le hemos dicho a vfio-pci que reclame ese vendor/device ID.
Decisión: Si el dispositivo se niega a desvincularse, puede que lo esté usando el host (sistema raíz en USB, teclado de consola, etc.). Soluciona la dependencia primero.
Task 8: Confirmar que vfio-pci está ahora en uso
cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Subsystem: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller [1b21:2142]
Kernel driver in use: vfio-pci
Kernel modules: xhci_pci
Significado: Correcto. El host ya no lo está gestionando.
Decisión: Procede a adjuntarlo a la VM. Si vuelve a xHCI tras un reinicio, implementa el binding persistente.
Task 9: Hacer persistente el binding de vfio-pci con config de modprobe
Significado: El initramfs incluirá el binding para que vfio-pci capture el controlador de forma temprana.
Decisión: Reinicia y confirma que la propiedad del driver sigue siendo vfio-pci. El binding temprano previene carreras en el arranque y rarezas del tipo “funciona salvo…”.
Task 10: Confirmar el modo de interrupción (MSI/MSI-X) para el controlador pasado
Significado: Mientras el host lo posee, usa “IR-PCI-MSI” (MSI de interrupción reasignada). Una vez ligado a vfio-pci, debería desaparecer de las interrupciones del host.
Decisión: Si solo ves líneas INTx heredadas o no aparece “IR-” en plataformas que deberían soportarlo, sospecha de remapeo faltante o firmware extraño.
Task 11: Validar la salud del mapeo VFIO/IOMMU bajo carga (buscar fallos)
Significado: Fallo de DMA. Esto no es “inofensivo.” El controlador intentó hacer DMA a un lugar que la IOMMU no mapeó.
Decisión: Si los fallos ocurren solo bajo carga, sospecha hardware con bugs, un quirk de IOMMU en la plataforma o un driver del guest que hace algo que el controlador/firmware maneja mal.
Prueba con otro controlador, actualiza BIOS, actualiza el kernel y desactiva características PCIe sospechosas (ver tareas posteriores).
Task 12: Buscar spew de PCIe Advanced Error Reporting (AER)
Significado: Los errores corregidos no son instantáneamente fatales, pero se correlacionan sospechosamente bien con resets aleatorios y eventos “USB desapareció”.
Decisión: Reasienta la tarjeta, cambia de ranura, fuerza Gen3 en vez de “Auto”, desactiva ASPM agresivo o reemplaza el hardware sospechoso.
Task 13: Inspeccionar configuraciones de gestión de energía que suelen romper el passthrough USB
Significado: ASPM está en “default.” Algunas plataformas se comportan. Otras inventan nuevos modos de fallo.
Decisión: Si ves flaps de enlace o AER alrededor del controlador pasado, considera arrancar con pcie_aspm=off como prueba.
Si la estabilidad mejora, encontraste un bug de gestión de energía, no un bug de virtualización.
Task 14: Confirmar que la VM ve el controlador y usa un driver real
cr0x@server:~$ sudo virsh domiflist win11
Interface Type Source Model MAC
-------------------------------------------------------
vnet0 bridge br0 virtio 52:54:00:aa:bb:cc
Significado: La configuración de la VM incluye el dispositivo pasado.
Decisión: Si el guest no puede instalar/usar el controlador xHCI, puede que falten ajustes UEFI, o que el dispositivo no esté realmente ligado a vfio-pci en el host.
Task 15: Comprobar problemas de reset (FLR/D3cold) tras reinicio del guest
cr0x@server:~$ sudo dmesg | egrep -i 'reset|flr|D3cold|vfio-pci 0000:03:00.0' | tail -n 30
[ 1322.333444] vfio-pci 0000:03:00.0: not ready 1023ms after FLR; waiting
[ 1323.444555] vfio-pci 0000:03:00.0: not ready 2047ms after FLR; giving up
Significado: El dispositivo no volvió del reset limpiamente. Este es un clásico problema de “funciona hasta que reinicias la VM”.
Decisión: Prueba otro modelo de controlador USB, actualiza BIOS y evita ahorro de energía en caliente. Algunos controladores simplemente no se reinician de forma fiable en contextos de passthrough.
Task 16: Confirmar el modo IOMMU y el tipo de dominio (compensación rendimiento vs seguridad)
Significado: El host usa mappings de passthrough por defecto; los dispositivos VFIO aún obtienen dominios aislados.
Decisión: Si estás depurando fallos de DMA raros, temporalmente elimina iommu=pt para ver si la traducción completa cambia el comportamiento. No como solución permanente, sino como palanca diagnóstica.
Playbook de diagnóstico rápido (comprobar primero/segundo/tercero)
Cuando el passthrough de un controlador USB es inestable, quieres identificar el cuello de botella rápido: capacidad de plataforma, aislamiento, comportamiento de reset
o algo tan aburrido como una ranura defectuosa.
Primero: “¿Puede esta plataforma manejar interrupciones de forma segura?”
Revisa dmesg buscando “Interrupt remapping enabled.” Si no está, no pierdas una semana afinando.
Comprueba si el controlador usa MSI/MSI-X bajo el driver del host (antes de que VFIO lo capture). Si estás atascado en INTx heredado, espera problemas.
Busca advertencias de VFIO sobre interrupciones inseguras.
Segundo: “¿El aislamiento es real, o estoy peleando con la física de grupos IOMMU?”
Lista los grupos IOMMU. Si el controlador USB está pegado a otros dispositivos que no puedes pasar, tus opciones son: diferente ranura, diferente controlador, diferente placa base.
Evita ACS override como primera solución. Úsalo solo cuando el riesgo sea aceptable y puedas probar a fondo.
Tercero: “¿Se reinicia limpiamente?”
Reinicia el guest repetidamente y observa timeouts de FLR, mensajes de dispositivo no listo o la desaparición del controlador del espacio de configuración PCI.
Si se queda atascado tras un solo reinicio del guest, suele ser comportamiento del silicio/firmware del controlador. Cambia el controlador antes de reescribir tu arquitectura.
Cuarto: “¿Es un problema de enlace/energía disfrazado?”
Busca errores AER corregidos alrededor del root port del controlador.
Prueba con ASPM deshabilitado y fuerza la generación PCIe (Gen3/Gen4) en vez de Auto.
Mueve la tarjeta a otra ranura y vuelve a probar. Sí, en serio. Las ranuras pueden fallar, la bifurcación puede ser extraña y el root port importa.
Quinto: “¿La carga de trabajo dispara un caso límite real de USB?”
Interfaces de audio: vigila transferencias isócronas y comportamientos periódicos tipo XRUN. A menudo es entrega de interrupciones o planificación.
Dongles HID: busca breves caídas de energía o bucles de reenumeración; a menudo provienen de gestión de energía y resets.
Almacenamiento de alto ancho de banda: comprueba si el controlador comparte lanes o se estrangula; el almacenamiento USB3 puede generar patrones de interrupciones brutales.
Tres mini-historias corporativas desde la trinchera
1) El incidente causado por una suposición errónea: “IOMMU está activada, así que estamos seguros”
Una empresa mediana ejecutaba VMs Windows para varios flujos de trabajo ligados al hardware: dongles de licencias, dispositivos de medida, un lector de tarjetas inteligentes.
Ya habían aprendido que el passthrough por dispositivo USB era inestable, así que estandarizaron en pasar un controlador USB dedicado.
El despliegue parecía limpio en el laboratorio. Luego los usuarios de producción empezaron a reportar que el dongle “se caía” cada pocas horas.
El equipo de virtualización hizo lo que hacen los equipos: culpar a Windows, culpar a QEMU, culpar a los rayos cósmicos. Cambiaron dongles. Cambiaron hubs.
Incluso asignaron CPU al guest. El problema persistió y tenía un patrón feo: ocurría más durante las horas pico, cuando los hosts
estaban más ocupados y las VMs tenían más interrupciones en vuelo.
La suposición errónea fue sutil: habían confirmado intel_iommu=on y vieron logs DMAR, así que concluyeron que la plataforma era “capaz de IOMMU.”
Lo que no verificaron fue la reasignación de interrupciones. El BIOS tenía VT-d habilitado pero un toggle adicional “Interrupt Remapping” estaba apagado por defecto
tras una actualización de firmware. El kernel se lo dijo educadamente, pero nadie buscó exactamente esa línea.
Una vez habilitada la reasignación de interrupciones, las desconexiones misteriosas cesaron. La resolución se sintió anticlimática, que es como suelen sentirse los buenos arreglos.
La nota del postmortem que importó: “IOMMU habilitada” no es un estado binario. La traducción DMA y la reasignación de interrupciones son patas separadas del taburete.
Quita una y estás equilibrándote en vibras.
2) La optimización que salió mal: “Ahorremos una ranura PCIe y compartamos el controlador onboard”
Otra organización estandarizó servidores compactos con ranuras PCIe limitadas. Alguien propuso una optimización:
en vez de comprar una tarjeta USB dedicada por host, pasarían el controlador xHCI onboard y mantendrían las necesidades USB del host al mínimo.
En papel, ahorraba ranuras y reducía costes. En la realidad, hizo el host frágil.
El controlador onboard estaba en un grupo IOMMU con otra función de la plataforma. A veces era un dispositivo companion; otras era un subsistema del chipset que el host necesitaba para operar con estabilidad. Forzaron la cuestión con trucos de separación de grupo. Funcionó—hasta que no funcionó.
Un reinicio del guest disparó un reset del controlador que el host notó de forma inadecuada, y de repente el host perdió su único teclado USB local
y un par de dispositivos internos. Hicieron falta manos remotas. A Operations le encantó eso.
El siguiente intento fue “optimizar” interrupciones y energía: permitir estados C más profundos y ASPM agresivo porque los sistemas estaban “mayormente inactivos.”
Eso volvió el problema intermitente y por tanto más caro. La VM era estable durante horas de trabajo, inestable por la noche, y los logs parecían inocentes.
Eventualmente los logs AER y cambios de estado de enlace relacionaron la inestabilidad con la gestión de energía interactuando con la ruta de reset del controlador.
Revirtieron la optimización: tarjetas USB discretas dedicadas, el host retuvo el USB onboard, configuraciones de energía PCIe conservadoras.
Costó más. También eliminó toda una categoría de fallo. Ese es el ROI del que nadie alardea en las presentaciones, pero que todos agradecen a las 3 a.m.
3) La práctica aburrida pero correcta que salvó el día: “Validación previa y una ruta de respaldo conocida”
Un equipo de servicios financieros tenía una política que parecía excesivamente cautelosa: cada nuevo build de host debía pasar una “validación de passthrough” antes de entrar en el clúster de virtualización. Incluía verificar reasignación de interrupciones, comprobar grupos IOMMU, ejecutar un bucle de reinicio del guest,
e intencionalmente hotplug/unplug de dispositivos detrás del controlador pasado mientras se recopilan logs.
Durante una compra de servidores, recibieron un lote con una revisión de placa ligeramente distinta. La ficha técnica parecía igual.
Las pantallas del BIOS eran casi iguales. Pero los grupos IOMMU eran diferentes: el controlador USB onboard ahora estaba agrupado con otro dispositivo
debido a un cambio de enrutamiento. La generación anterior tenía aislamiento limpio; esta no.
Como la validación era obligatoria, el problema se detectó antes de que los servidores llegaran a producción.
Ajustaron el diseño: los hosts usaron una tarjeta USB PCIe discreta de conocida buena conducta para passthrough, y el controlador onboard se quedó con el host.
La práctica “aburrida” aquí no fue heroica—fue negarse a aceptar “hardware casi igual” como la misma plataforma.
Lo mejor: cuando un ejecutivo preguntó por qué la fecha de puesta en marcha no se retrasó, la respuesta honesta fue “porque hicimos las tediosas pruebas que siempre hacemos.”
Nadie aplaudió. Los sistemas se mantuvieron en pie. Ese es el aplauso que realmente quieres.
Errores comunes: síntoma → causa raíz → solución
1) La VM pierde aleatoriamente dispositivos USB detrás del controlador pasado
Síntoma: Dispositivos HID/audio/almacenamiento se desconectan y reconectan; los logs del guest muestran resets de dispositivo; los logs del host parecen mayormente limpios.
Causa raíz: Reasignación de interrupciones desactivada o rota, provocando entrega MSI poco fiable bajo carga.
Solución: Habilitar reasignación de interrupciones en BIOS/UEFI, confirmar en dmesg. Si no es compatible, cambia la plataforma.
2) El host se congela o se vuelve lento cuando el guest reinicia
Síntoma: Un reinicio del guest provoca un bloqueo del host; a veces solo stalls de I/O; a veces bloqueo total que requiere ciclo de energía.
Causa raíz: El comportamiento de reset del controlador interactúa con el driver del host o el chipset; el host aún posee funciones relacionadas o comparte recursos en el grupo.
Solución: Asegurar que vfio-pci se enlace temprano; evitar pasar un dispositivo en un grupo IOMMU compartido; usar un controlador discreto; actualizar BIOS.
3) VFIO se niega a iniciar la VM o queja de interrupciones inseguras
Síntoma: La VM falla al arrancar; errores mencionan mapeo de interrupciones o “no interrupt remapping support.”
Causa raíz: La plataforma carece o tiene desactivada la reasignación de interrupciones; a veces ajustes del kernel imponen seguridad.
Solución: Habilitar remapeo; si es imposible, no uses passthrough de controlador para esa carga (o acepta menor seguridad con los ojos abiertos).
4) Funciona hasta que reinicias la VM; luego el controlador no vuelve
Síntoma: Primer arranque bien; tras reinicio del guest, el arranque siguiente falla o el dispositivo falta; dmesg muestra timeouts de FLR.
Causa raíz: El controlador no puede realizar FLR de forma fiable; atascado en un estado de baja potencia (D3cold), o bug de firmware.
Solución: Cambia el modelo de controlador; prueba otra ranura; desactiva ahorro de energía PCIe runtime; a veces solo un reinicio/power cycle del host lo arregla.
5) El audio USB hace ruidos o tiene cortes periódicos en el guest
Síntoma: Pops de audio cada pocos segundos; la interfaz USB sigue conectada pero el rendimiento es pésimo.
Causa raíz: Latencia en manejo de interrupciones: scheduling de vCPU, estados de energía de CPU del host, o problemas de reasignación/afinidad de interrupciones.
Solución: Fija vCPUs, aísla CPUs del host para cargas de baja latencia, evita estados C profundos y verifica MSI con remapeo. Considera un controlador dedicado por VM.
6) El controlador comparte un grupo IOMMU con SATA/NIC/otros dispositivos críticos
Síntoma: No puedes pasar sin perder algo que el host necesita.
Causa raíz: La plataforma no tiene separación ACS; el diseño de la placa agrupa funciones detrás del mismo puerto upstream.
Solución: Usa otra ranura PCIe o una tarjeta discreta; elige una placa con mejor separación de grupos IOMMU; evita ACS override en producción.
7) Todo parece correcto, pero el rendimiento es inconsistente
Síntoma: Caídas de throughput; picos aleatorios de latencia; almacenamiento USB a veces se cuelga.
Causa raíz: Problemas de enlace PCIe (AER corrected errors), cables marginales o problemas de suministro de energía a dispositivos USB de alto consumo.
Solución: Revisa logs AER, desactiva ASPM, prueba un hub con alimentación limpia, reemplaza la tarjeta PCIe y no uses cableado de panel frontal para dispositivos críticos.
Listas de verificación / plan paso a paso
Paso a paso: construir una configuración estable de passthrough de controlador USB
Elige el controlador: prefiere una tarjeta PCIe xHCI discreta que caiga en su propio grupo IOMMU.
Configuración del firmware: habilita VT-d/AMD IOMMU y reasignación de interrupciones; habilita Above 4G decoding si tienes múltiples dispositivos PCIe.
Línea de comandos del kernel: establece intel_iommu=on o amd_iommu=on. Opcionalmente iommu=pt una vez estable.
Verificar en dmesg: confirma IOMMU y reasignación de interrupciones habilitadas. Si no, detente y corrígelo.
Comprobar grupos IOMMU: asegúrate de que el controlador pueda aislarse o pasarse como grupo completo.
Vincular a vfio-pci temprano: usa /etc/modprobe.d/vfio.conf y reconstruye initramfs. Evita el rebinding en tiempo de ejecución como configuración permanente.
Adjuntar a la VM: usa libvirt hostdev o el equivalente de tu plataforma. Mantenlo simple: un controlador, una VM, una tarea.
Prueba de estabilidad: bucle de reinicios del guest, desconectar/conectar dispositivos detrás del controlador y carga sostenida (copias de almacenamiento USB, stream de audio, etc.).
Vigila logs: busca DMAR/IOMMU faults, errores AER y timeouts FLR.
Bloquea características de energía: si ves errores de enlace o resets raros, desactiva ASPM y evita estados de energía profundos. Luego vuelve a probar.
Lista operacional: qué mantener después de que funcione
Registra el BDF y el vendor/device ID del dispositivo pasado en tu gestión de configuración.
Mantén una vía USB accesible para el host para recuperación de emergencia (IPMI virtual media, USB onboard dedicado o un controlador separado).
Tras actualizaciones de BIOS, verifica de nuevo reasignación de interrupciones y grupos IOMMU. Las actualizaciones de firmware adoran “restablecer a valores por defecto.”
Mantén una versión de kernel conocida y buena para cargas VFIO; actualiza intencionalmente con validación, no “porque es martes”.
Alerta sobre DMAR/IOMMU faults y tormentas AER; son advertencias tempranas, no trivia.
Preguntas frecuentes (FAQ)
¿Realmente necesito reasignación de interrupciones para passthrough de controlador USB?
Si quieres estabilidad, sí. El aislamiento DMA por sí solo no garantiza una entrega fiable de interrupciones. Sin remapeo puedes obtener un comportamiento “funciona hasta carga”
que te hará perder días en depuración.
¿Por qué no pasar simplemente dispositivos USB individuales en vez del controlador?
Porque el passthrough por dispositivo USB normalmente hace proxy de transacciones USB a través del host. Puede ser suficiente para un ratón.
Suele ser terrible para dispositivos que se reinician, transmiten audio isócrono o hacen bailes extraños de enumeración.
El passthrough de controlador da al guest el hardware real y elimina al host del datapath.
¿Es iommu=pt bueno o malo?
Normalmente está bien y a menudo se recomienda por rendimiento en el host porque los dispositivos no-VFIO obtienen mappings de identidad.
Para depurar fallos de traducción extraños, quítalo temporalmente para ver si el comportamiento cambia. No lo trates como un arreglo mágico.
Mi controlador USB está en el mismo grupo IOMMU que otros dispositivos. ¿Qué hago?
La mejor respuesta: cambia la ranura PCIe, usa otra tarjeta controladora o una placa base con mejor separación ACS/IOMMU.
Pasar grupos parciales es pedir inestabilidad. ACS override puede funcionar, pero es un trade-off de riesgo, no una solución gratuita.
¿Por qué el controlador desaparece tras reiniciar el guest?
Comportamiento de reset. Algunos controladores no implementan FLR correctamente, o quedan atascados en un estado de baja potencia. Si ves “vfio not ready after FLR”,
deja de tratarlo como bug de software y prueba con otro hardware.
¿Debo desactivar ASPM y ahorro de energía?
Si ves errores AER, flaps de enlace o resets extraños: sí, como prueba y a menudo como elección permanente para hosts sensibles a latencia o con mucho passthrough.
Ahorrar energía está bien; tener interrupciones estables es mejor.
¿Puedo pasar el controlador USB del chipset (onboard) de forma segura?
A veces. Pero es más probable que esté en grupo con otras funciones de plataforma y que el host lo necesite.
Para operaciones fiables, un controlador discreto dedicado al guest es el diseño limpio.
¿Cuál es la diferencia entre MSI y INTx para passthrough?
MSI/MSI-X son interrupciones basadas en mensajes y son el default moderno. INTx son líneas de interrupción heredadas compartidas y pueden ser más problemáticas en entornos virtualizados.
En general quieres MSI/MSI-X con reasignación de interrupciones habilitada.
Mi VM arranca, pero el controlador USB muestra errores en el driver del guest. ¿Es un problema del host?
No siempre. Puede ser un problema del driver del guest, pero empieza revisando el dmesg del host por DMAR faults, timeouts FLR y errores AER.
Si el host está limpio, entonces revisa logs de eventos del guest y versiones de drivers.
¿Es necesario un controlador USB por VM?
Para configuraciones de alta estabilidad, sí. Compartir un controlador entre varios guests no es típico porque una sola función PCIe física no puede ser propiedad segura
de múltiples OS al mismo tiempo. Si necesitas múltiples dominios USB aislados, añade más controladores.
Próximos pasos que puedes hacer hoy
Abre el dmesg de tu host y confirma “Interrupt remapping enabled.” Si falta, corrige primero la configuración del firmware.
Escoge el objetivo de controlador USB adecuado: tarjeta discreta, grupo IOMMU aislado, no la línea de vida del host.
Vincúlalo a vfio-pci temprano mediante config de modprobe + initramfs, no mediante rebinding ad-hoc después del arranque.
Ejecuta la prueba de reinicio y carga: reinicios repetidos del guest más tráfico USB sostenido mientras vigilas DMAR faults, timeouts FLR y errores AER.
Si sigue fallando, deja de tocar perillas y cambia el controlador o la plataforma. Algunas combinaciones simplemente son malas parejas.
El objetivo no es hacer que el passthrough USB “funcione.” El objetivo es hacerlo predecible. Los sistemas predecibles son los que puedes operar sin
desarrollar una relación personal con tus logs.