Por qué tu GPU en passthrough queda en pantalla negra después del reinicio (a menudo es IOMMU)
febrero 10, 2026 • febrero 10, 2026 • Lectura: 24 min • Views: 0
¿Te fue útil?
Lo tenías funcionando. La VM arrancó, se instaló el controlador del invitado, incluso ejecutaste un benchmark como un adulto responsable.
Luego reiniciaste el host y—pantalla negra. Sin salida. Quizá la VM “funciona” pero no ves nada.
Quizá el host arranca bien pero la GPU está muerta para el invitado. Bienvenido al passthrough de GPU: donde el éxito de ayer no es un contrato.
Cuando esto ocurre después de un reinicio, la falla a menudo no es “la GPU” en abstracto. Casi siempre
es una de tres cosas: cambió el aislamiento IOMMU, el driver equivocado agarró el dispositivo primero, o el dispositivo no se reinició limpiamente.
El truco es dejar de adivinar y empezar a recoger evidencias que sobrevivan al reinicio.
Guía rápida de diagnóstico
Si estás de guardia o simplemente harto, usa este orden. Está optimizado para tiempo-hasta-la-primera-verdad, no por elegancia.
Haz estas comprobaciones en el host primero; tu invitado no puede decirte la verdad si nunca llegó a poseer realmente la GPU.
1) Confirma que el dispositivo sigue siendo el mismo
Verifica que la dirección PCI y los IDs del dispositivo no cambiaron (raro, pero ocurre con actualizaciones de BIOS o cambios de ranura).
Confirma que la GPU y su función de audio están ambas presentes.
2) Confirma que VFIO realmente enlazó la GPU al arrancar
Si el driver del kernel del host (nouveau, nvidia, amdgpu) se enlaza primero, VFIO “pierde” y tu VM se queda con un fantasma.
Los problemas de enlace son comunes tras actualizaciones de kernel y cambios en initramfs.
3) Confirma que los grupos IOMMU siguen aislados
Si tu GPU comparte un grupo IOMMU con algo que el host necesita, o no arrancarás o arrancarás y tendrás pantalla negra.
La pertenencia al grupo puede cambiar por toggles de BIOS, actualizaciones de firmware o diferentes parámetros del kernel.
4) Revisa problemas de reinicio/FLR
Si funciona una vez pero falla tras reiniciar o después de apagar/arrancar la VM, probablemente hay un quirk de reset.
Se manifiestan como “la VM arranca, sin display” o “el driver del invitado carga y luego el dispositivo desaparece”.
5) Confirma que la ruta de pantalla no está mintiendo
Entrada errónea del monitor, handshake DP extraño o un conmutador KVM pueden parecer una falla de VFIO.
Prueba con una salida diferente (HDMI vs DP) o usa un dummy plug conocido bueno.
Broma #1: El passthrough de GPU es el único sitio donde “funcionó ayer” se considera un modelo de amenaza.
Qué significa realmente “pantalla negra” en passthrough
“Pantalla negra” es un síntoma, no un diagnóstico. En VFIO GPU passthrough normalmente significa una de estas cosas:
El invitado nunca obtuvo la GPU: el driver del host la enlazó, o QEMU no pudo asignarla debido a conflictos de grupo IOMMU.
El invitado recibió la GPU, pero nunca inicializó salida: falta de option ROM, modo de firmware incorrecto (UEFI vs legacy), o estado de reset defectuoso.
El invitado inicializó, pero estás mirando la salida equivocada: confusión por multi-monitor o múltiples salidas; la GPU está renderizando en otro lugar.
La GPU está en un estado bloqueado: un problema conocido en algunas GPUs de consumo sin un Function Level Reset (FLR) apropiado.
Un modelo mental útil: el passthrough es una cadena de custodia. El dispositivo PCIe está “poseído” por algo en cada momento:
firmware, driver del host, VFIO, QEMU, driver del invitado. Las pantallas negras suelen ocurrir cuando la propiedad cambia
pero el estado no se reinicia limpiamente—or el propietario equivocado lo agarra primero.
Por qué IOMMU suele ser el culpable
IOMMU (Intel VT-d / AMD-Vi) es el portero del club de memoria. Restringe DMA para que los dispositivos no puedan leer y escribir
memoria aleatoria. Para passthrough eso no es negociable: tu GPU de invitado debe hacer DMA solo en memoria asignada al invitado,
no en la cache de páginas del host ni en los secretos del hypervisor.
La parte que te perjudica tras el reinicio es que la topología IOMMU no es solo “encendido/apagado.” Está moldeada por:
opciones de BIOS, topología PCIe, parámetros del kernel, capacidades ACS, y a veces la creatividad del fabricante de la placa.
Eso significa que puedes tener una configuración que funciona y que silenciosamente deja de estar aislada después de un reinicio,
una actualización de firmware, o incluso un orden de arranque diferente de los dispositivos.
Grupos IOMMU: la verdadera unidad de aislamiento
VFIO entrega grupos IOMMU enteros a los invitados, no dispositivos individuales arbitrarios (con matices, pero trátalo como “el grupo”).
Si tu GPU está en un grupo con, digamos, un controlador SATA o un controlador USB que el host necesita, tienes un conflicto:
o pasas demasiado y pierdes funcionalidad del host, o no puedes aislar la GPU de forma segura.
Tras un reinicio, la pertenencia al grupo puede cambiar porque el firmware reenumeró el árbol PCIe de forma diferente,
o porque un toggle de BIOS cambió el comportamiento de ACS. A veces una actualización de BIOS “inofensiva” decide que el puerto raíz del chipset
debe comportarse distinto, y ahora tu GPU está pegada a media máquina.
ACS override: tentador, a veces necesario, siempre un trade-off
El parámetro de kernel ACS override puede dividir grupos que el hardware no aísla correctamente.
Esto puede hacer posible el passthrough en plataformas de consumo, y también crear una falsa sensación de seguridad:
le estás diciendo al kernel que asuma un aislamiento que quizá no exista eléctricamente.
En entornos de producción trato ACS override como usar cinta adhesiva en la línea de frenos. Puede que llegues a casa.
No deberías construir una flota alrededor de ello.
Remapeo de interrupciones y por qué “IOMMU activado” no es suficiente
Algunas plataformas necesitan que el remapeo de interrupciones esté activado para un passthrough seguro. Sin ello, puedes ver fallos extraños:
dispositivos que parecen asignados pero actúan como muertos, invitados que se cuelgan al inicializar el driver, o patrones de “funciona hasta reiniciar”.
Aquí es donde “activé VT-d” se convierte en un cuento de hadas. Necesitas verificar que el kernel realmente ha activado las características.
Datos interesantes y contexto histórico
VFIO reemplazó enfoques antiguos de asignación de dispositivos en KVM moviendo el acceso a dispositivos a un marco más seguro impulsado por IOMMU en lugar de mapeos ad-hoc.
IOMMU existe principalmente para el aislamiento de DMA; la virtualización lo popularizó, pero el problema de seguridad (dispositivos como atacantes DMA) precede al auge del homelab actual.
PCIe ACS no fue “diseñado para gamers”; es una característica de servidores para aislamiento y control de enrutamiento, y los chipsets de consumo a menudo la implementan parcialmente o no la implementan.
Muchas GPUs exponen múltiples funciones PCI (gráficos + audio HDMI + a veces USB-C/VirtualLink). A menudo necesitas pasar todas las funciones relacionadas para estabilidad.
Function Level Reset (FLR) no es universal; algunas GPUs de consumo históricamente carecían de un reset fiable, causando fallos de passthrough de “funciona una vez”.
UEFI GOP vs ROM VGA legacy importa: las GPUs modernas prefieren la inicialización UEFI; las rutas CSM legacy pueden comportarse distinto entre reboots y versiones de firmware.
Resizable BAR cambió expectativas de dimensionado de recursos PCIe; activarlo/desactivarlo puede afectar cómo se mapea la memoria de los dispositivos y, ocasionalmente, cómo el firmware enumera los dispositivos.
La conciliación temprana de VGA sigue siendo relevante: el concepto de “GPU primaria” influye qué firmware inicializa primero, lo que afecta el enlace del driver del host y el passthrough.
Tareas prácticas: comandos, salidas, qué significa, qué hacer después
A continuación hay tareas de campo que puedes ejecutar ahora mismo en un host Linux KVM (incluidos hosts tipo Proxmox).
Cada una incluye: un comando, una salida realista, qué significa la salida y la decisión a tomar a partir de ella.
No hagas selección sesgada. Ejecuta las primeras aunque estés “seguro” de que es otra cosa.
Tarea 1: Confirma que IOMMU está realmente habilitado en el kernel
Significado: Solicitas Intel IOMMU, modo pass-through para dispositivos no pasados (iommu=pt), y pre-enlace VFIO a IDs PCI específicos.
Decisión: Si los parámetros faltan tras el reinicio, editaste la entrada de bootloader equivocada o no regeneraste la configuración de arranque. Arregla el bootloader y reconstruye initramfs si es necesario.
Tarea 3: Identifica la GPU y sus funciones (gráficos + audio)
Significado: Tu GPU está en 01:00.0 y la función de audio HDMI en 01:00.1. Normalmente deben pasarse juntas.
Decisión: Si la función de audio falta tras el reinicio, sospecha cambios en la enumeración PCIe, riser defectuoso o una opción BIOS de “ahorro de energía PCIe” comportándose mal.
Tarea 4: Ver qué driver posee actualmente la GPU (chequeo de la cadena de custodia)
Significado: Bien: Kernel driver in use: vfio-pci. El host no la está usando activamente.
Decisión: Si ves nouveau, nvidia o amdgpu como “in use”, tu passthrough será inestable o fallará. Arregla el enlace del driver antes de depurar grupos IOMMU.
Tarea 5: Verifica la pertenencia a grupos IOMMU (la verdad del aislamiento)
cr0x@server:~$ for d in /sys/kernel/iommu_groups/*/devices/*; do g=$(basename $(dirname $d)); printf "Group %s: " "$g"; lspci -nns ${d##*/}; done | egrep '01:00'
Group 16: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
Group 16: 01:00.1 Audio device [0403]: NVIDIA Corporation GP104 High Definition Audio Controller [10de:10f0] (rev a1)
Significado: Ideal: las funciones de la GPU están solas juntas en un grupo.
Decisión: Si el grupo incluye otros dispositivos (controlador USB, SATA, NIC), decide: mueve la GPU a otra ranura, cambia ajustes PCIe en BIOS, o acepta el riesgo del ACS override.
Tarea 6: Detecta si se está usando ACS override (y admite el riesgo)
cr0x@server:~$ dmesg | egrep -i 'ACS|override' | head
[ 1.245678] PCI: Using ACS override for IOMMU isolation
Significado: El kernel está simulando/dividiendo el aislamiento.
Decisión: En un homelab puede ser aceptable. En un entorno con modelos de amenaza reales, trátalo como un puente temporal mientras arreglas la topología hardware.
Tarea 7: Confirma que los módulos VFIO están cargados y no desaparecieron tras una actualización
Decisión: Si los módulos no están cargados, verifica initramfs y listas de bloqueo de módulos. Las actualizaciones de kernel pueden revertir tu configuración de formas aburridas.
Tarea 8: Comprueba indirectamente el contenido de initramfs (¿está el enlace vfio ocurriendo lo suficientemente pronto?)
Significado: Estás configurando enlace VFIO temprano vía opciones modprobe y asegurando la carga de módulos.
Decisión: Si esto parece correcto pero el driver del host aún se enlaza primero, regenera initramfs y reinicia. El enlace temprano es la diferencia entre “estable” y “demoníaco”.
Tarea 9: Confirma que la GPU no es el dispositivo de framebuffer de arranque/console
cr0x@server:~$ dmesg | egrep -i 'fb0|framebuffer|efifb|vesafb' | head -n 20
[ 0.401234] efifb: probing for efifb
[ 0.401567] efifb: framebuffer at 0xc0000000, using 3072k, total 3072k
[ 0.401890] fb0: EFI VGA frame buffer device
Significado: El host está usando el framebuffer EFI, que puede o no estar en tu GPU passthrough.
Decisión: Si la GPU de passthrough es el dispositivo de pantalla primario, lucharás contra el firmware y el enlace de la consola. Prefiere iGPU o una GPU secundaria barata para el host.
Tarea 10: Busca “GPU cayó del bus” / AER / errores de enlace tras el reinicio
cr0x@server:~$ journalctl -b -k | egrep -i 'AER|pcie|fallen off|vfio|DMAR|amdgpu|nvidia' | tail -n 30
Feb 04 09:11:21 server kernel: vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
Feb 04 09:11:22 server kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Feb 04 09:11:22 server kernel: pcieport 0000:00:01.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer
Significado: Tienes errores PCIe corregidos. No siempre son fatales, pero si correlacionan con pantallas negras, puedes tener problemas de integridad de señal o gestión de energía.
Decisión: Prueba otra ranura, desactiva ASPM en BIOS, actualiza BIOS o quita risers. No “optimices” hasta que esté estable.
Tarea 11: Revisa errores de asignación en QEMU/libvirt (el caso de “nunca realmente se adjuntó”)
cr0x@server:~$ journalctl -u libvirtd -b --no-pager | tail -n 30
Feb 04 09:15:02 server libvirtd[1123]: internal error: qemu unexpectedly closed the monitor: 2026-02-04T09:15:02.123456Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0: vfio 0000:01:00.0: group 16 is not viable
Feb 04 09:15:02 server libvirtd[1123]: internal error: qemu unexpectedly closed the monitor: 2026-02-04T09:15:02.123499Z qemu-system-x86_64: -device vfio-pci,host=0000:01:00.0: Please ensure all devices within the iommu_group are bound to their vfio bus driver.
Significado: Clásico: el grupo IOMMU contiene algo no enlazado a VFIO, por lo que QEMU rechaza o falla.
Decisión: O enlaza todo el grupo a VFIO (peligroso si incluye dispositivos críticos del host), o reestructura el aislamiento (preferible).
Tarea 12: Confirma el modo de firmware del invitado y el manejo de la ROM de la GPU
Significado: La VM usa OVMF (UEFI). ROM BAR está activada (no es lo mismo que suministrar un archivo ROM, pero es relevante).
Decisión: Si usas BIOS legacy (SeaBIOS) con una GPU moderna y ves pantallas negras tras reinicios, cambia a OVMF salvo que tengas una razón específica para no hacerlo.
Tarea 13: Revisa el clásico “NVIDIA Code 43” y diferéncialo de problemas IOMMU
cr0x@server:~$ virsh qemu-agent-command win11-gpu '{"execute":"guest-get-osinfo"}'
{"return":{"id":"mswindows","name":"Microsoft Windows","pretty-name":"Microsoft Windows 11","version":"10.0"}}
Significado: El agente invitado responde; el OS invitado está vivo incluso si ves una pantalla negra.
Decisión: Si el invitado está vivo, tu problema puede ser inicialización de display, estado del driver o selección de salida—no una falla total de attach del dispositivo.
Tarea 14: Valida que la GPU no esté todavía “en uso” por un proceso del host
Significado: El grupo VFIO lo mantiene el proceso QEMU. Eso es esperado cuando la VM está en ejecución.
Decisión: Si otro proceso lo tiene (o está retenido tras detener la VM), tienes un problema de limpieza/reset. Arregla los hooks de cierre y considera vendor-reset o una política de ciclo de energía completo.
Tarea 15: Forzar comprobación de flags de características IOMMU en plataformas Intel
Significado: Tienes las piezas que hacen que el passthrough sea menos embrujado.
Decisión: Si falta el remapeo de interrupciones, busca opciones BIOS como “Interrupt Remapping” o “Posted Interrupt.” Algunas placas lo ocultan bajo “Security”.
Tarea 16: Comprueba si la GPU soporta y anuncia capacidades de reset
Significado: Este fragmento por sí solo no confirma FLR, pero lspci -vv es donde buscas capacidades y comportamiento relacionado con reset.
Decisión: Si consistentemente ves “funciona una vez” y la tarjeta carece de buen comportamiento de reset, planifica mitigaciones: vendor-reset para algunas AMD, ciclo de energía del host tras detener la VM, o elige otra GPU.
Tres mini-historias corporativas desde el campo
Incidente #1: La suposición equivocada (“Reiniciar es un estado limpio”)
Una empresa mediana gestionaba una pequeña pool VDI para un equipo de diseño. Nada exótico: KVM, VFIO, unas GPUs por host, invitados Windows.
Funcionó en staging durante semanas. Luego llegó el primer patch Tuesday y reiniciaron los hosts durante un fin de semana.
Lunes por la mañana: un tercio de las VMs arrancaron con pantalla negra.
La suposición embebida en su runbook era simple: un reinicio del host reinicia el hardware, así que la GPU siempre volverá limpia.
Esa suposición fue errónea en dos sentidos. Primero, la GPU era el dispositivo de pantalla primario en el BIOS en algunos hosts,
así que el firmware y el framebuffer de la consola del host la tocaron antes de que VFIO pudiera reclamarla. Segundo, una opción de BIOS
(“fast boot”) alteró el timing de inicialización PCIe y cambió qué dispositivos terminaron en qué grupos IOMMU.
El diagnóstico tomó más tiempo del necesario porque el equipo persiguió logs del lado invitado.
Esos logs eran reales, pero no causales. La GPU nunca llegó a pertenecer verdaderamente al invitado en los casos fallidos.
La prueba estaba en lspci -nnk: el driver del host poseía la GPU en los hosts rotos.
La solución fue aburrida y efectiva: estandarizar ajustes de BIOS, forzar la iGPU como primaria para el host,
y asegurar que el enlace VFIO ocurriera en initramfs con los IDs correctos para GPU y función de audio.
Tras eso, los reinicios volvieron a ser previsibles—que es el único tipo de reinicio que quieres en producción.
Incidente #2: La optimización que salió mal (“Activemos todos los toggles de rendimiento”)
Otro equipo quería el máximo rendimiento GPU para cargas de cómputo en invitados. Alguien (con buenas intenciones)
activó Resizable BAR, Above 4G decoding y algunos knobs de gestión de energía PCIe en la flota.
En papel, esto puede ayudar ciertas cargas. En realidad, introdujo un layout de recursos PCIe inconsistente en tiempo de arranque.
El síntoma inmediato no fue el rendimiento. Fue pantallas negras intermitentes tras reinicios, concentradas en un modelo de placa.
Algunos hosts arrancaban con la GPU en un grupo IOMMU que ahora incluía un puente PCIe y un controlador USB.
QEMU a veces se negaba a arrancar, otras veces la VM arrancaba pero la GPU no inicializaba la salida.
El equipo perdió un día porque los cambios eran “ajustes de rendimiento” y nadie mentalmente los conectó con aislamiento.
El postmortem fue franco: si tu plataforma no está validada para esos toggles, trátalos como características experimentales.
Revirtieron primero los cambios de gestión de energía, luego validaron Resizable BAR host por host.
La estabilidad volvió. El rendimiento también—porque el rendimiento es lo que tienes después de la fiabilidad, no en su lugar.
Broma #2: Si activas cada switch de BIOS etiquetado “turbo”, no estás afinando—estás audicionando para la liga de ruleta de reinicios.
Incidente #3: La práctica aburrida que salvó el día (“Evidencia base después de cada cambio”)
Un equipo más disciplinado ejecutaba un pequeño programa de “host dorado”. Cada vez que cambiaban firmware, kernel o paquetes del hypervisor,
capturaban un paquete base: /proc/cmdline, líneas de dmesg que confirman IOMMU, listados de grupos IOMMU, y lspci -nnk para la GPU. Lo almacenaban con el ticket de cambio. Nadie lo celebraba.
Era papeleo con salidas de comandos.
Entonces una actualización rutinaria de kernel coincidió con un problema de pantalla negra tras reiniciar en dos hosts.
En lugar de discutir si era “el driver de GPU”, compararon los paquetes base.
La evidencia fue inmediata: la cmdline ya no tenía los IDs VFIO esperados en los hosts afectados.
Un fragmento de configuración del bootloader había sido sobrescrito durante una transición de paquetes.
La solución fue rápida porque no necesitaban redescubrir el sistema; solo restaurarlo.
Corrigieron la configuración de arranque, reconstruyeron initramfs y reiniciaron una vez. Las VMs volvieron.
La gran victoria no fue genialidad técnica—fue tener prueba de cómo se veía “funcionando”.
Esta es la realidad poco glamurosa de ejecutar virtualización en producción: no previenes cada fallo.
Previenes los que te hacen perder tiempo.
Errores comunes: síntoma → causa raíz → solución
1) Pantalla negra solo después de reiniciar; el primer arranque en frío está bien
Causa raíz: Quirk de reset de la GPU. El dispositivo no vuelve a un estado limpio en reinicios cálidos o al detener/arrancar la VM.
Solución: Prefiere GPUs con FLR adecuado; prueba una solución de reset en kernel/módulo (cuando aplique), o exige ciclo de energía del host tras detener la VM. Evita estados de “suspend” para el host.
2) La VM arranca, el invitado es accesible (RDP/SSH), pero el monitor físico sigue en negro
Causa raíz: Desajuste de salida (puerto equivocado), mismatch UEFI/ROM, o el driver del invitado eligiendo otra ruta de display.
Solución: Cambia la VM a OVMF; asegura el manejo correcto de la ROM de la GPU; prueba otra salida; elimina displays virtuales extra; verifica que el invitado vea la GPU y la salida seleccionada.
3) QEMU/libvirt se queja “group is not viable” tras reiniciar
Causa raíz: El grupo IOMMU contiene otros dispositivos no enlazados a VFIO, o el grupo cambió tras una actualización de firmware.
Solución: Revisa pertenencia al grupo; mueve la GPU de ranura; cambia ajustes PCIe en BIOS; evita ACS override a menos que aceptes el riesgo; enlaza todo el grupo solo si es seguro.
4) La GPU se enlaza a nouveau/nvidia/amdgpu en el host tras reiniciar
Causa raíz: El enlace VFIO no ocurre lo suficientemente pronto; initramfs carece de tu configuración vfio; los blacklists no se aplican al arranque.
Solución: Pon los IDs de vfio-pci en configuración modprobe; blacklistea drivers del host si hace falta; reconstruye initramfs; confirma con lspci -nnk después del reinicio.
5) Todo funcionaba hasta que activaste “fast boot” o cambiaste CSM/UEFI
Causa raíz: Cambió la ruta de inicialización del firmware; cambió la selección de GPU primaria; cambió el comportamiento del option ROM.
Solución: Desactiva fast boot para hosts de passthrough; estandariza modo UEFI; configura una GPU no-passthrough como primaria si es posible.
6) El driver del invitado carga y luego se bloquea; el dispositivo desaparece o da errores
Causa raíz: Remapeo de interrupciones o mismatch de características IOMMU; ocasionalmente quirks de MSI/MSI-X.
Solución: Verifica remapeo de interrupciones en dmesg; actualiza BIOS; asegura VT-d/AMD-Vi completamente habilitado; prueba un kernel más reciente.
7) La pantalla negra coincide con spam AER PCIe tras reiniciar
Causa raíz: Integridad de señal (cables riser), gestión de energía (ASPM), PSU límite, o problemas de entrenamiento de la ranura.
Solución: Quita risers; prueba otra ranura; desactiva ASPM; actualiza BIOS; valida la entrega de energía.
Listas de verificación / plan paso a paso
Lista básica (haz esto cuando esté funcionando)
Captura /proc/cmdline y guárdalo con tus notas de cambio.
Captura líneas de dmesg que confirmen IOMMU + remapeo de interrupciones.
Captura la pertenencia a grupos IOMMU para las funciones de la GPU.
Captura lspci -nnk mostrando vfio-pci como “in use” para GPU y audio.
Captura el modo de firmware de la VM (OVMF vs SeaBIOS) y el mapeo hostdev.
Plan de recuperación cuando reiniciaste y ahora está en negro
Detén la VM (si está ejecutándose) para evitar intentos repetidos de inicialización que compliquen los logs.
Confirma que las direcciones PCI de la GPU no cambiaron (lspci -nn).
Revisa la propiedad del driver (lspci -nnk -s 01:00.0 y 01:00.1).
Consulta los grupos IOMMU y verifica que el grupo sea viable.
Revisa logs del kernel por AER y errores VFIO (journalctl -b -k).
Verifica el modo de firmware (OVMF preferido para invitados modernos) y elimina dispositivos de display virtuales conflictivos.
Si es un problema de reset, prueba un ciclo de energía completo del host (no solo reboot). Si eso lo arregla, trata el comportamiento de reset como causa raíz y planifica mitigaciones.
Plan de endurecimiento (haz que los reinicios sean aburridos otra vez)
Estandariza ajustes BIOS en los hosts: VT-d/AMD-Vi ON, remapeo de interrupciones ON, fast boot OFF.
Prefiere un dispositivo de pantalla dedicado para el host (iGPU o GPU secundaria barata) para que el firmware no inicialice tu GPU de passthrough.
Enlaza VFIO en initramfs, no “tarde” en el arranque. El enlace tardío es una carrera que acabarás perdiendo.
Evita ACS override en entornos con necesidades de aislamiento serio; si debes usarlo, documenta y revisa.
Tras cualquier actualización de BIOS/kernel, vuelve a validar los grupos IOMMU. Trátalo como una migración de esquema, porque lo es.
Una idea parafraseada atribuida a menudo a Werner Vogels: construyes fiabilidad esperando fallos y diseñando para ellos, no esperando que el camino feliz se mantenga feliz.
Preguntas frecuentes
1) ¿Por qué funciona hasta que reinicio el host?
Reiniciar cambia la cadena de custodia. El firmware puede inicializar la GPU de forma distinta, el driver del host puede enlazarse antes,
y los grupos IOMMU pueden enumerarse de forma distinta. Los reinicios en caliente tampoco siempre reinician limpiamente las GPUs de consumo.
2) ¿IOMMU es siempre requerido para GPU passthrough?
Para un passthrough seguro y correcto en sistemas modernos: sí. Sin IOMMU, no se aplica el aislamiento DMA,
y VFIO no puede asignar el dispositivo de forma segura a un invitado.
3) ¿Cuál es la diferencia entre intel_iommu=on y iommu=pt?
intel_iommu=on habilita el IOMMU Intel. iommu=pt pone dispositivos no pasados en modo pass-through para reducir sobrecarga.
Aún obtienes aislamiento para dispositivos enlazados a VFIO; simplemente no fuerzas traducción para todo lo demás.
4) ¿Tengo que pasar también la función de audio de la GPU?
Normalmente, sí. Muchas GPUs son dispositivos multifunción y se comportan mejor cuando todas las funciones relacionadas en el mismo grupo IOMMU se asignan juntas.
Omitir la función de audio puede causar inicialización o comportamiento de reset extraño.
5) Si mi grupo IOMMU contiene otros dispositivos, ¿puedo pasar solo la GPU?
Prácticamente: a veces, con ACS override o configuraciones inseguras. Correctamente: el grupo es la unidad de aislamiento.
Si el grupo incluye dispositivos críticos del host, tu solución a largo plazo es cambios de hardware/ranura/topología, no “forzarlo”.
6) ¿Es seguro ACS override?
Puede ser aceptable en un entorno personal. Es un trade-off de seguridad y corrección: le dices al kernel que asuma separación que quizá no exista.
Si te importa la garantía de aislamiento, evítalo y arregla la plataforma.
7) ¿Por qué la VM funciona pero no tengo salida de video?
Porque “la VM funciona” solo significa que QEMU está vivo. La salida de video depende de la inicialización de la GPU, el modo de firmware y la selección de salida.
Verifica que el invitado vea la GPU y prueba OVMF más una ruta de salida física distinta.
8) ¿Debo usar OVMF (UEFI) o SeaBIOS?
Para Windows moderno y GPUs modernas, OVMF suele ser el camino menos doloroso. SeaBIOS puede funcionar, pero aumenta la posibilidad de quirks de ROM/inicio.
Si persigues pantallas negras tras reinicios, cambiar a OVMF suele ser una ganancia neta.
9) ¿Y si el host no tiene iGPU y solo tiene una GPU?
Aún puedes hacerlo, pero estás eligiendo “modo difícil”. El host probablemente inicializará esa GPU para la consola.
Espera luchar contra el enlace temprano y la posesión del framebuffer. Una GPU secundaria barata suele pagarse sola en tiempo ahorrado.
10) ¿Cuál es el comando más útil al depurar esto?
lspci -nnk en las funciones de la GPU. Te dice quién posee el dispositivo ahora mismo. La propiedad es la historia.
Conclusión: próximos pasos que puedes hacer hoy
Si tu passthrough de GPU se queda en pantalla negra tras reiniciar, deja de tratarlo como un capricho místico de la GPU.
Trátalo como un problema de sistemas: verifica que IOMMU esté habilitado y con todas sus características, verifica que VFIO se enlace temprano,
verifica que los grupos IOMMU sean estables y estén aislados, y solo entonces persigue quirks de reset y rarezas de la ruta de display.
Próximos pasos prácticos:
Ejecuta las Tareas 1–5 y guarda la salida. Ese es tu baseline y tu objetivo de diff.
Haz que el enlace VFIO sea determinista al arranque (initramfs), no “eventual”.
Vuelve a comprobar grupos IOMMU tras cualquier cambio de BIOS o kernel. Asúmelos cambiados hasta que se demuestre lo contrario.
Si tu plataforma necesita ACS override para comportarse, considera eso un problema de selección de hardware—no una victoria de tuning del kernel.
Si confirmas un problema de reset, planifica una política de mitigación (ciclo de energía, otra GPU, o un helper de reset donde aplique) en lugar de reiniciar y esperar suerte.
La meta no es hacerlo funcionar una vez. La meta es que sobreviva al próximo reinicio sin ceremonia.