¿La actualización del kernel rompió el passthrough? Cómo diagnosticar IOMMU rápidamente

Guía de diagnóstico rápido (haz esto primero)

Si estás de guardia, no necesitas una filosofía del IOMMU. Necesitas una bifurcación rápida en el camino: ¿es esto BIOS, parámetros del kernel, binding del driver, agrupamiento o comportamiento de reset del dispositivo? Trabaja de arriba hacia abajo y para cuando encuentres una contradicción clara.

Primero: confirma que IOMMU está realmente habilitado y activo

1. Revisa los parámetros de arranque del kernel para las banderas de IOMMU.
2. Revisa dmesg para la inicialización del IOMMU.
3. Confirma que tienes grupos IOMMU bajo /sys/kernel/iommu_groups.

Decisión: Si IOMMU no está activo, no toques VFIO, libvirt, QEMU o ajustes de Proxmox todavía. Arregla primero firmware + args del kernel.

Segundo: confirma que el dispositivo está ligado a vfio-pci (y no al driver del host)

1. lspci -nnk para “Kernel driver in use”.
2. Comprueba que vfio-pci está cargado y que los IDs de dispositivo coinciden.
3. Verifica que initramfs incluya los módulos VFIO si necesitas binding temprano.

Decisión: Si tu GPU/HBA sigue siendo reclamada por amdgpu/nvidia/nouveau/ahci/megaraid_sas, la VM fallará. Arregla el binding antes de tocar grupos.

Tercero: revisa los grupos IOMMU y regresiones de aislamiento

1. Lista los grupos y ve qué se movió.
2. Busca síntomas de “grupo creció”: tu GPU ahora comparte con un controlador USB o un dispositivo de audio que no puedes pasar de forma limpia.
3. Comprueba si el comportamiento de ACS/ARI cambió con la actualización del kernel.

Decisión: Si el agrupamiento es el problema, o (a) cambias ranuras, (b) ajustas la configuración PCIe en BIOS, (c) aceptas el riesgo del ACS override, o (d) cambias la placa madre. Elige uno; no “simplemente sobreescribas” en producción sin un modelo de amenazas.

Cuarto: inspecciona fallos DMA/IOMMU y problemas de reset

1. Busca en dmesg fallos de IOMMU y errores DMAR/AMD-Vi.
2. Busca quirks de FLR/reset (especialmente en GPUs).
3. Valida que tu configuración de VM no solicite cosas imposibles (como mismatch de multifunction).

Decisión: Si es un quirk de reset, puede que necesites parámetros del kernel, otra GPU, o dejar de intentar reiniciar la VM como si fuera un servidor web.

Broma breve #1: Un grupo IOMMU es como una oficina de plan abierto: un vecino ruidoso y de repente nadie hace su trabajo.

Qué probablemente cambió tras una actualización del kernel

Las actualizaciones del kernel no “rompen al azar” el passthrough. Cambian cómo el kernel enumera dispositivos, cómo aplica quirks, cómo maneja características PCIe y, a veces, cómo prioriza seguridad frente a conveniencia. La falla se siente aleatoria porque tu modelo mental está desactualizado.

Disparadores comunes tras una actualización del kernel que originan regresiones en passthrough

• Diferente enumeración de topología PCIe: cambia un driver de bridge o un quirk y tu dispositivo termina comportándose detrás de un root port distinto.
• Cambios en manejo de ACS/ARI: los grupos pueden fusionarse o dividirse cuando el kernel decide que un puerto downstream no es confiable para aislar.
• Cambios en comportamiento de VFIO: comprobaciones más estrictas sobre interrupciones inseguras, tamaño de BARs o reset de dispositivo.
• Diferencias en initramfs: después de instalar un kernel, tu initramfs puede no incluir vfio-pci para binding temprano; el host atrapa el dispositivo primero.
• Interacciones con firma de módulos / Secure Boot: un módulo externo puede no cargarse, dejando drivers de fallback en control.
• Actualizaciones de firmware/BIOS encadenadas: las actualizaciones “mientras estás en ello” a veces modifican valores por defecto de virtualización o reinician ajustes PCIe.

Dos reglas que te mantienen cuerdo

Regla 1: Trata el passthrough como una cadena de custodia. Firmware expone, kernel enumera, IOMMU aísla, VFIO liga, hipervisor asigna. Las rupturas ocurren en un eslabón, no en lo abstracto.

Regla 2: No intentes arreglar el agrupamiento hasta haber probado el binding y la activación de IOMMU. Si no, “arreglarás” la capa equivocada y no aprenderás nada.

Hechos interesantes y breve historia que realmente ayudan

Saber un poco de contexto te ayuda a predecir qué perillas importan y cuáles son placebo.

1. “VT-d” de Intel y “AMD-Vi” de AMD son marcas diferentes para la misma idea central: remapeo DMA para que los dispositivos no puedan escribir en RAM arbitraria.
2. IOMMU no nació originalmente por conveniencia de virtualización; nació por seguridad y corrección cuando los dispositivos hacían DMA en memoria.
3. VFIO reemplazó enfoques más antiguos (como rutas legacy de asignación KVM) apoyándose en el IOMMU para aislamiento y en el kernel para mediación.
4. ACS (Access Control Services) es una característica de PCIe que ayuda a hacer cumplir límites de aislamiento; la falta de ACS es por qué las plataformas de consumo suelen tener grupos “pegajosos”.
5. ARI (Alternative Routing-ID Interpretation) afecta cómo se direccionan funciones detrás de un bridge; cambios en ARI pueden alterar agrupamientos y comportamiento multifunción.
6. El remapeo de interrupciones MSI/MSI-X importa: el passthrough es más seguro cuando la plataforma soporta remapeo de interrupciones; algunos kernels son más estrictos cuando falta.
7. FLR (Function Level Reset) es opcional en dispositivos PCIe; muchos dispositivos “soportan reset” en marketing pero se comportan mal con reinicios repetidos de VM.
8. El passthrough de GPU se volvió más fácil y más difícil con el tiempo: mejores funciones en VFIO y QEMU, pero GPUs más complejas, estados de energía y firmware que complican.
9. El ACS override existe porque la realidad es desordenada, no porque sea una buena práctica; obliga al kernel a fingir que existe aislamiento donde el hardware no lo garantiza.

Tareas prácticas de diagnóstico (comandos, salidas, decisiones)

Estas son las tareas que ejecuto en producción cuando el passthrough falla tras una actualización del kernel. Cada tarea incluye: comando, qué significa la salida y la decisión que tomas después. Ejecútalas en orden si quieres velocidad; elige según la capa que ya sabes que falló.

Task 1: Confirmar tu kernel en ejecución y contexto del último arranque

cr0x@server:~$ uname -r
6.8.0-48-generic

Qué significa: Estás depurando el kernel en ejecución. Si acabas de actualizar pero no reiniciaste, puedes estar persiguiendo fantasmas.

Decisión: Si la versión del kernel no coincide con la ventana de cambio “rota”, reinicia en el kernel sospechoso y reproduce. No hagas arqueología en el runtime equivocado.

Task 2: Revisa la línea de comando del kernel para parámetros IOMMU

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

Qué significa: Has pedido Intel IOMMU y “modo passthrough” para dispositivos del host (iommu=pt), lo que puede reducir overhead para dispositivos no asignados.

Decisión: Si estás en AMD, intel_iommu=on es decorativo. Usa amd_iommu=on. Si ninguno está presente, añade el correcto y regenera la configuración del gestor de arranque.

Task 3: Prueba que IOMMU realmente se inicializó (Intel DMAR / AMD-Vi)

cr0x@server:~$ dmesg -T | egrep -i 'DMAR|IOMMU|AMD-Vi' | head -n 20
[Tue Feb  4 10:18:11 2026] DMAR: IOMMU enabled
[Tue Feb  4 10:18:11 2026] DMAR: Host address width 46
[Tue Feb  4 10:18:11 2026] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[Tue Feb  4 10:18:11 2026] DMAR: Intel(R) Virtualization Technology for Directed I/O

Qué significa: El kernel dice que IOMMU está habilitado y encontró unidades DMAR.

Decisión: Si ves “IOMMU disabled” o nada, para. Ve a BIOS/UEFI: habilita VT-d/AMD-Vi, y desactiva “Above 4G decoding” solo si tienes una plataforma específica rota (raro; por lo general lo quieres activado).

Task 4: Confirma que existen grupos IOMMU

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups | head
0
1
10
11
12

Qué significa: El agrupamiento IOMMU está activo. No tener grupos suele significar que IOMMU no está habilitado o estás en un modo que no creó entradas sysfs de grupos.

Decisión: Si esta ruta está vacía o falta, vuelve a las tareas 2–3 y a la configuración de firmware. No pierdas tiempo en binding VFIO todavía.

Task 5: Inventario de dispositivos y binding de driver actual

cr0x@server:~$ lspci -nnk | sed -n '1,120p'
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:3e0f] (rev 0a)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Device [1462:3771]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia
01:00.1 Audio device [0403]: NVIDIA Corporation TU104 HD Audio Controller [10de:10f8] (rev a1)
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

Qué significa: La GPU está reclamada por el driver NVIDIA del host, y su función de audio está reclamada por snd_hda_intel. El passthrough fallará o será inestable si el host posee el dispositivo.

Decisión: Si tu objetivo es pasar la GPU, liga ambas funciones (VGA + audio) a vfio-pci. Si solo ligas una, a menudo acabarás con errores extraños o una VM que cuelga al arrancar.

Task 6: Identifica la membresía del grupo IOMMU para el dispositivo objetivo

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename "$g")"; ls -1 "$g/devices" | sed 's/^/  /'; done | sed -n '1,60p'
Group 1
  0000:00:01.0
Group 2
  0000:01:00.0
  0000:01:00.1
Group 3
  0000:00:14.0
  0000:00:14.2

Qué significa: Las funciones de la GPU comparten el Grupo 2 juntas (bien), pero necesitas comprobar si algo más está en ese grupo (mal). Aquí solo están las dos funciones de GPU.

Decisión: Si tu GPU comparte un grupo con otros dispositivos que no puedes pasar (como un controlador SATA que aloja tu disco root), tienes un problema de aislamiento. Pasa a la remediación de agrupamiento, no a la configuración de VFIO.

Task 7: Detecta qué cambió comparando grupos antes/después (si tienes logs)

cr0x@server:~$ journalctl -b -1 -k | egrep -i 'DMAR|IOMMU|ACS|vfio' | tail -n 20
Jan 31 09:12:02 server kernel: DMAR: IOMMU enabled
Jan 31 09:12:03 server kernel: vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)

Qué significa: El arranque anterior muestra que el binding VFIO se realizó (o al menos se intentó). Si el arranque actual no muestra líneas similares, algo cambió en initramfs/orden de carga de módulos o en IDs de dispositivo.

Decisión: Si en el arranque previo hubo VFIO y en el actual no, céntrate en initramfs y configuración de modprobe en lugar de BIOS o ACS.

Task 8: Verifica que los módulos VFIO estén cargados

cr0x@server:~$ lsmod | egrep 'vfio|kvm' | head
vfio_pci               163840  0
vfio_pci_core           73728  1 vfio_pci
vfio_iommu_type1        45056  0
vfio                    65536  2 vfio_pci_core,vfio_iommu_type1
kvm_intel              430080  0
kvm                  1335296  1 kvm_intel

Qué significa: Las piezas centrales de VFIO están presentes. Si vfio_iommu_type1 falta, VFIO no puede mapear DMA de forma segura y la asignación de dispositivos fallará.

Decisión: Si faltan módulos, cárgalos y arregla la persistencia. Para Debian/Ubuntu, ponlos en /etc/modules o asegúrate de que tu initramfs los incluya.

Task 9: Enlazar un dispositivo a vfio-pci (temporal, en runtime)

cr0x@server:~$ sudo modprobe vfio-pci
cr0x@server:~$ echo 10de 1e87 | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id
10de 1e87
cr0x@server:~$ sudo lspci -nnk -s 01:00.0
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2080] [10de:1e87] (rev a1)
	Subsystem: Device [1462:3771]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: El dispositivo ahora está ligado a vfio-pci (runtime). Esto prueba que el binding funciona sin reiniciar.

Decisión: Si falla porque el dispositivo está “en uso”, debes detener el servicio del host que lo posee (display manager, daemon de persistencia, audio). Para GPUs, los hosts sin entorno gráfico son tu amigo.

Task 10: Hacer persistente el binding VFIO (config modprobe + initramfs)

cr0x@server:~$ sudo tee /etc/modprobe.d/vfio.conf >/dev/null <<'EOF'
options vfio-pci ids=10de:1e87,10de:10f8 disable_vga=1
EOF
cr0x@server:~$ sudo tee -a /etc/modules >/dev/null <<'EOF'
vfio
vfio_pci
vfio_iommu_type1
vfio_pci_core
EOF
cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0-48-generic

Qué significa: Has pedido a vfio-pci que reclame IDs de dispositivo específicos y te has asegurado de que los módulos estén presentes temprano. disable_vga=1 puede ayudar con problemas de arbitraje VGA primario en algunas plataformas.

Decisión: Si tras reiniciar el host sigue agarrando la GPU, probablemente necesites listar en blacklist a los drivers del host (nouveau/nvidia/amdgpu) o eliminar los consoles de framebuffer. Sé deliberado; no pongas en blacklist drivers de almacenamiento/red a la ligera a menos que disfrutes del trabajo manual remoto.

Task 11: Valida el estado de blacklist para drivers GPU conflictivos

cr0x@server:~$ grep -R "blacklist nouveau\|blacklist nvidia\|blacklist amdgpu" /etc/modprobe.d || true
/etc/modprobe.d/blacklist-nouveau.conf:blacklist nouveau
/etc/modprobe.d/blacklist-nouveau.conf:options nouveau modeset=0

Qué significa: Nouveau está en blacklist. Eso reduce una carrera común donde el driver abierto se liga primero.

Decisión: Si el driver propietario aún se liga temprano, asegura que sus paquetes no estén instalados o que sus servicios no arranquen. Para una GPU dedicada al passthrough, el host debería comportarse como si no existiera.

Task 12: Comprueba si el remapeo de interrupciones está disponible (seguridad y estabilidad)

cr0x@server:~$ dmesg -T | egrep -i 'interrupt remap|IR:' | head
[Tue Feb  4 10:18:11 2026] DMAR-IR: Enabled IRQ remapping in x2apic mode

Qué significa: El remapeo de IRQ está habilitado. Esto importa para la asignación segura de dispositivos y puede afectar si VFIO advierte sobre “interrupciones inseguras”.

Decisión: Si no tienes remapeo de interrupciones, aún puedes ejecutar passthrough, pero entras en territorio “funciona hasta que no funciona”. Para entornos corporativos, trata la falta de remapeo de IRQ como un riesgo de plataforma, no como una molestia ajustable.

Task 13: Detectar capacidad ACS y si el kernel confía en la topología

cr0x@server:~$ sudo lspci -s 00:01.0 -vv | egrep -i 'ACSCap|ACSctl|ARI|SR-IOV' -n
82:	ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+
84:	ACSctl: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl+ DirectTrans+

Qué significa: El puerto upstream anuncia características ACS. Eso aumenta las probabilidades de obtener grupos limpios sin overrides.

Decisión: Si ACS está ausente en bridges clave, acepta que “grupos perfectos” pueden ser imposibles en esa placa. Mueve dispositivos a ranuras diferentes/root ports antes de recurrir al ACS override.

Task 14: Buscar fallos de IOMMU durante el arranque de la VM

cr0x@server:~$ dmesg -T | egrep -i 'fault|DMAR:.*fault|AMD-Vi:.*Event|vfio.*error' | tail -n 20
[Tue Feb  4 10:26:44 2026] DMAR: DRHD: handling fault status reg 2
[Tue Feb  4 10:26:44 2026] DMAR: [DMA Read NO_PASID] Request device [01:00.0] fault addr 0x7f3c0000 [fault reason 0x06] PTE Read access is not set

Qué significa: El dispositivo intentó DMA a una dirección no mapeada en las tablas del IOMMU. Eso puede ser una configuración errónea del invitado, comportamiento buggy del dispositivo durante el reset, o un problema de mapeo en el host.

Decisión: Si los fallos aparecen justo al iniciar la VM, sospecha del estado de reset/firmware del dispositivo o de un passthrough incompleto (función compañera faltante). Si los fallos aparecen bajo carga, sospecha bugs en drivers/firmware o módulos externos que interactúan mal.

Task 15: Verificar que el dispositivo soporte el comportamiento de reset que puedes tolerar

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'Capabilities: \[.*\] Express|FLR|PowerCtl|LnkCtl' -n | head -n 30
10:	Capabilities: [60] Express (v2) Endpoint, MSI 00
45:	DevCtl: CorrErr- NonFatalErr+ FatalErr+ UnsupReq+
72:	Capabilities: [100] Advanced Error Reporting

Qué significa: Puedes ver capacidades Express PCIe, pero puede que no veas líneas FLR explícitas; el soporte FLR varía y algunas GPUs se comportan mal aun cuando nominalmente soportan reset.

Decisión: Si tu problema es “la primera VM arranca, la segunda falla”, probablemente enfrentas quirks de reset. La solución a menudo es: evitar reinicios frecuentes de VM, reiniciar el host en frío entre asignaciones, o elegir hardware con mejores semánticas de reset.

Task 16: Validar que QEMU/KVM ve el IOMMU y los dispositivos VFIO

cr0x@server:~$ sudo virsh nodedev-list | egrep 'pci_0000_01_00_[01]' || true
pci_0000_01_00_0
pci_0000_01_00_1

Qué significa: Libvirt ve los dispositivos PCI como node devices. Esa es la comprobación de inventario a nivel del hipervisor.

Decisión: Si libvirt no puede verlos, tu entorno udev/libvirt está roto o los permisos son incorrectos. No sigas cambiando IDs VFIO si la capa de gestión no puede enumerar.

Task 17: Confirma permisos y propiedad de grupo del nodo de dispositivo vfio

cr0x@server:~$ ls -l /dev/vfio
total 0
crw-rw---- 1 root kvm  10, 196 Feb  4 10:20 0
crw-rw---- 1 root kvm  10, 196 Feb  4 10:20 2
crw-rw---- 1 root kvm  10, 196 Feb  4 10:20 vfio

Qué significa: Existen dispositivos de caracteres de grupo VFIO, típicamente propiedad de root:kvm. Si tu libvirt/QEMU corre sin privilegios, la pertenencia a grupos importa.

Decisión: Si los permisos son incorrectos, arregla los grupos de la cuenta de servicio del hipervisor o las reglas udev. No hagas chmod 666 y lo llames “resuelto”. Eso no es ingeniería; es rendición.

Task 18: Revisa problemas con Secure Boot/firmas de módulos (común tras actualizaciones)

cr0x@server:~$ dmesg -T | egrep -i 'Lockdown|Secure boot|module verification|taint' | tail -n 10
[Tue Feb  4 10:18:12 2026] Lockdown: Loading of unsigned modules is restricted; see man kernel_lockdown.7

Qué significa: El kernel está en un modo que restringe la carga de módulos sin firmar. Si tu configuración depende de módulos externos (común para drivers de GPU de vendor), puede que no se carguen tras una actualización.

Decisión: O inscribe claves/firma módulos correctamente, o evita depender de módulos externos en el host para una GPU en passthrough. Si el host necesita drivers del vendor, trata Secure Boot como un requisito de primera clase, no como una sorpresa.

Tres microhistorias corporativas (dolor, soberbia, victoria aburrida)

Microhistoria 1: El incidente causado por una suposición equivocada

Tenían un pequeño clúster de virtualización para acelerar builds: un puñado de VMs con passthrough de GPU para pruebas de render. No era “crítico”, que en lenguaje corporativo significa que se vuelve crítico a las 2 a.m. cuando los ejecutivos quieren una demo.

Se desplegó una actualización del kernel como parte del parcheo rutinario. Tras el reinicio, la mitad de las VMs no arrancaban. El operador de guardia vio la GPU aún listada en el host con el driver del vendor cargado y supuso: “Está bien; la VM aún puede adjuntarla.” Esta suposición convierte un bug solucionable en un incidente de cuatro horas.

El problema real fue más simple: cambió el binding temprano. El initramfs actualizado dejó de incluir los módulos vfio-pci por una deriva en la configuración de su pipeline de imagen. El host agarró las GPUs antes de que VFIO tuviera oportunidad. Perdieron tiempo cambiando ajustes de BIOS y moviendo ranuras PCIe porque los grupos “se veían diferentes”, cuando en realidad los grupos estaban bien—el binding era incorrecto.

Cuando volvieron a añadir los módulos VFIO al initramfs y fijaron los IDs vfio-pci, todo volvió. El postmortem no fue sobre VFIO. Fue sobre “verificar la capa que estás cambiando”. El arreglo fue incluir en la build de imagen una comprobación explícita: fallar la build si los módulos vfio no están presentes en el initramfs para hosts con GPU.

Microhistoria 2: La optimización que salió mal

Un equipo de plataforma quiso reducir el overhead de virtualización. Pusieron iommu=pt por doquier porque lo habían visto recomendado para rendimiento. Es una perilla válida en contexto correcto. Lo desplegaron ampliamente sin entender el intercambio que implicaba.

Tras una actualización del kernel, una SKU de hardware empezó a lanzar fallos DMA intermitentes bajo una carga muy específica: I/O alto más creación/destrucción frecuente de VMs. Los logs de fallos apuntaban a accesos DMA del dispositivo que no estaban mapeados como esperaban. Su reacción instintiva fue culpar al kernel.

El modo real de fallo fue más feo: la combinación de “passthrough mode para dispositivos del host” y un quirk de plataforma alrededor de ATS/PRI creó un comportamiento sensible al timing durante adjuntos/desadjuntos rápidos. En kernels antiguos, un quirk lo enmascaraba. En el nuevo kernel, ese quirk cambió. La “optimización” sacó a la luz un problema de corrección.

Hicieron rollback del flag de rendimiento para esa SKU, y lo reintrodujeron solo después de validar el conjunto de características PCIe y el comportamiento del dispositivo en su flota. La lección: los flags de rendimiento no son adornos. Trátalos como cambios de código. Fléjalos con pruebas, no con sensaciones.

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

Un equipo de almacenamiento operaba una pequeña flota de hipervisores haciendo passthrough de HBA a VMs que corrían servicios de almacenamiento. Eran conservadores hasta resultar molestos: cada actualización del kernel requería un reinicio en seco en un host canario, y siempre capturaban una “instantánea de salud del passthrough” antes de tocar nada.

La instantánea era aburrida: versión del kernel, /proc/cmdline, estado IOMMU desde dmesg, listado completo de grupos IOMMU y lspci -nnk para los HBAs. Luego lo almacenaban junto con la solicitud de cambio. A nadie le encantaba este proceso. No era glamuroso. Funcionaba.

Una actualización cambió el agrupamiento IOMMU en una revisión específica de placa madre. El reinicio canario mostró inmediatamente que el grupo del HBA ahora contenía un root port compartido con una NIC. Eso habría bloqueado la asignación segura y forzado un ACS override arriesgado. Pausaron el despliegue, rerutearon cargas de trabajo y ajustaron la colocación de ranuras en ese modelo.

No hubo incidente. Solo un ticket aburrido con “despliegue pausado” y un plan corto. Ese es el tipo de aburrimiento que protege tus fines de semana.

Errores comunes: síntoma → causa raíz → solución

Esta sección es intencionalmente directa. Estos son los modos de fallo principales tras actualizaciones del kernel, mapeados a las soluciones que realmente cierran el ciclo.

1) La VM no arranca: “vfio: failed to setup container” o “No such device”

Síntoma: El inicio de la VM falla inmediatamente; los logs mencionan errores de contenedor VFIO o de mapeo IOMMU type1.

Causa raíz: IOMMU no está habilitado en firmware/kernel, o falta vfio_iommu_type1.

Solución: Habilita VT-d/AMD-Vi en BIOS; añade los args correctos al kernel; carga los módulos VFIO; reconstruye initramfs.

2) El dispositivo aparece, pero el driver del host aún se liga tras reiniciar

Síntoma: lspci -nnk muestra nvidia/amdgpu/snd_hda_intel aún “in use”.

Causa raíz: El binding VFIO no ocurre lo suficientemente temprano; initramfs carece de vfio-pci; drivers conflictivos se cargan primero.

Solución: Usa options vfio-pci ids=... y asegura que los módulos VFIO estén en initramfs; haz blacklist de drivers conflictivos cuando corresponda; mantén el host fuera de la consola GPU.

3) Los grupos IOMMU empeoraron tras la actualización (dispositivos fusionados)

Síntoma: GPU/HBA comparte grupo con un controlador USB, SATA u otro dispositivo crítico.

Causa raíz: El kernel cambió la confianza/quirks de ACS; toggles de BIOS cambiaron el routing PCIe; la placa carece de ACS en bridges.

Solución: Mueve el dispositivo a otra ranura/root port; habilita ACS/ARI en BIOS si está disponible; evita ACS override a menos que aceptes el riesgo de aislamiento.

4) La primera VM arranca; la segunda falla o el dispositivo desaparece

Síntoma: La VM arranca una vez después de reiniciar el host; arranques posteriores cuelgan o el dispositivo no se vuelve a adjuntar.

Causa raíz: Quirks de reset de dispositivo (problemas de FLR en GPU, comportamiento de energía D3cold), o el driver del invitado deja el dispositivo en mal estado.

Solución: Prefiere hardware conocido por resetearse limpiamente; usa reinicios completos del host entre asignaciones si es necesario; ajusta el shutdown del invitado; evita “bucles rápidos de reinicio”.

5) Fallos IOMMU aleatorios bajo carga

Síntoma: dmesg muestra fallos DMA cuando el invitado está ocupado; el rendimiento cae o la VM se cae.

Causa raíz: Firmware de plataforma inestable, firmware/driver del dispositivo con bugs, o situación insegura de remapeo de interrupciones.

Solución: Valida el remapeo de interrupciones; actualiza firmware de la placa madre; prueba con otro kernel; elimina flags de rendimiento hasta que la estabilidad esté demostrada.

6) “ACS override lo arregló” y luego aparecen cosas raras

Síntoma: Forzaste que los grupos se dividieran; la VM arranca; después ves errores de bus extraños, fallos DMA o preocupaciones de seguridad.

Causa raíz: ACS override finge límites de aislamiento; los dispositivos aún pueden hacer DMA de formas que el hardware no aísla correctamente.

Solución: Trata ACS override como último recurso; en entornos multi-inquilino o sensibles, no lo uses. Arregla la topología del hardware en su lugar.

Broma breve #2: ACS override es como usar cinta adhesiva en un interruptor—todo queda en silencio hasta que no.

Listas de verificación / plan paso a paso

Checklist A: El plan “lo necesito en 30 minutos”

1. Captura evidencia: guarda uname -r, /proc/cmdline, líneas IOMMU de dmesg, lspci -nnk para los dispositivos objetivo y el listado de grupos.
2. Prueba que IOMMU está activo: si no hay líneas DMAR/AMD-Vi, arregla primero BIOS/args del kernel.
3. Prueba el binding: el dispositivo debe aparecer como vfio-pci en lspci -nnk.
4. Prueba los grupos: el grupo del dispositivo objetivo no debe incluir dispositivos críticos no pasables.
5. Intenta arrancar la VM una vez: recoge errores. No intentes reinicios en bucle; eso oculta problemas de reset.
6. Si sospechas quirks de reset: haz un reinicio limpio del host, arranca la VM una vez y evita reinicios frecuentes hasta tener una solución permanente.

Checklist B: El plan “hacer que se quede arreglado”

1. Fija args del kernel en la configuración del gestor de arranque y documenta (Intel vs AMD importa).
2. Haz persistente el binding VFIO vía /etc/modprobe.d/vfio.conf y reconstrucción de initramfs.
3. Blacklist de drivers conflictivos solo cuando estés seguro de que el host no los necesita.
4. Registra una línea base de grupos IOMMU y compara después de updates en un host canario.
5. Valida el remapeo de IRQ y trata su ausencia como riesgo de plataforma.
6. Decide una política sobre ACS override (¿permitido dónde? ¿nunca en hosts compartidos? ¿solo en laboratorio?). Escríbela.
7. Prueba comportamiento cold/warm reboot para cada clase de dispositivo en passthrough (GPU, HBA, NIC). Algunos dispositivos mienten sobre la calidad del reset.
8. Automatiza comprobaciones para que la próxima actualización no sea una búsqueda del tesoro.

Checklist C: Instantánea mínima de “salud del passthrough” que deberías almacenar

• Versión del kernel: uname -r
• Args de arranque: cat /proc/cmdline
• Líneas de activación IOMMU: dmesg -T | egrep -i 'DMAR|AMD-Vi|IOMMU' | head
• Listado de grupos: enumerar /sys/kernel/iommu_groups
• Binding de drivers: lspci -nnk filtrado a dispositivos asignados
• Vista del hipervisor: virsh nodedev-list o el equivalente de tu plataforma

Una idea de fiabilidad que vale la pena robar

Idea parafraseada (de Werner Vogels, CTO de Amazon): “Tú lo construyes, tú lo ejecutas.” El equipo que despliega el cambio debe hacerse cargo del resultado operativo.

El passthrough no es un “problema de hardware” o “problema del kernel” que lances por encima del muro. Si lo operas, necesitas una lista de regresión y un camino de rollback.

Preguntas frecuentes (FAQ)

1) Mis grupos IOMMU cambiaron tras una actualización del kernel. ¿Es eso normal?

No es raro. El agrupamiento se deriva de la topología PCIe más lo que el kernel cree sobre características de aislamiento (ACS/ARI/quirks). Si un kernel cambia cómo confía en un bridge, los grupos pueden fusionarse o dividirse. Trátalo como una regresión para triage, no como que “el sistema está embrujado”.

2) ¿Debo usar acs_override=downstream,multifunction para arreglar el agrupamiento?

Sólo si entiendes el intercambio de seguridad y corrección. ACS override obliga al kernel a fingir que el aislamiento existe. En una caja de laboratorio, quizá esté bien. En entornos compartidos o sensibles, evítalo y arregla la topología (ranuras, plataforma, otra placa madre).

3) ¿Cuál es la forma más rápida de saber si el passthrough falla por binding?

lspci -nnk. Si “Kernel driver in use” no es vfio-pci para el dispositivo que quieres pasar (y sus funciones compañeras), aún no tienes passthrough. Todo lo demás es secundario.

4) ¿Por qué tengo que pasar también la función de audio de la GPU?

Porque es una función PCI separada en el mismo dispositivo. Dejarla en el host puede impedir un reset correcto, confundir al invitado o provocar conflictos de grupo/propiedad. Trata GPU + audio GPU como un par a menos que tengas una razón específica y pruebas de que es seguro separarlos.

5) Mi VM funciona solo después de un reinicio completo del host. ¿Qué está pasando?

Comportamiento de reset. Algunos dispositivos no se resetean limpiamente cuando se los desprende de un invitado, especialmente GPUs de consumo. El dispositivo queda en un estado del que el siguiente arranque de VM no puede recuperarse. Las soluciones incluyen evitar reinicios frecuentes de VM, usar hardware distinto o aceptar reinicios de host entre ejecuciones.

6) ¿iommu=pt ayuda o perjudica?

Pueda ayudar al rendimiento para dispositivos poseídos por el host al reducir la sobrecarga de traducción, pero no es gratis. Si topas con quirks de plataforma o comportamientos complejos de dispositivos, quítalo durante la resolución de problemas. Asegura la corrección primero y luego optimiza.

7) ¿Cómo afectan Secure Boot y las actualizaciones del kernel al passthrough?

Si dependes de módulos externos (común con drivers de GPU de vendors), Secure Boot puede bloquearlos tras una actualización a menos que estén firmados/inscritos correctamente. Eso cambia el binding de drivers y puede romper tu configuración indirectamente. Revisa dmesg para mensajes de lockdown y verificación de módulos.

8) Veo fallos IOMMU en dmesg. ¿Es eso siempre fatal?

No siempre, pero nunca es “normal”. Los fallos significan que un dispositivo intentó DMA fuera de las mappings permitidas. Si está asociado con tu dispositivo en passthrough, trátalo como una señal seria: passthrough incompleto, quirks de reset, drivers buggy o inestabilidad de plataforma.

9) ¿Puedo hot-plugar dispositivos en passthrough de forma segura?

A veces, pero no lo des por sentado. El hot-plug añade complejidad: estados de energía, semánticas de reset y carreras de enumeración. Para fiabilidad en producción, prefiere asignación estática con hardware bien probado.

10) ¿Qué debería capturar antes de actualizaciones del kernel en hosts con passthrough?

Versión del kernel, args de arranque, líneas de activación IOMMU, inventario de grupos IOMMU y binding de drivers para dispositivos asignados. Si no puedes comparar “antes” y “después”, adivinarás, y adivinar cuesta caro.

Conclusión: siguientes pasos que perduran

Cuando una actualización del kernel rompe el passthrough, la jugada ganadora es negarse a hacer cambios frenéticos. Verifica la activación de IOMMU, luego el binding VFIO, luego los grupos, luego los fallos/quirks de reset. Ese orden evita que “arregles” tres cosas no relacionadas y no aprendas nada.

Haz lo siguiente:

1. Construye un script de “instantánea de salud del passthrough” con un comando y guarda su salida antes y después de actualizaciones.
2. Reinicia en canario un host por SKU de hardware antes de desplegar parches a toda la flota.
3. Escribe tu política sobre ACS override y cúmplela.
4. Para dispositivos con mal comportamiento de reset, cambia el patrón operativo (menos reinicios, reinicios en frío) o cambia el hardware. Las heroicidades no son una estrategia.

Si no haces nada más: la próxima vez que esto falle, no empieces por la configuración de la VM. Empieza con dmesg, /proc/cmdline y lspci -nnk. La máquina ya te está diciendo la verdad. Tu trabajo es escuchar en el orden correcto.