- El FLR en KVM/VFIO deja a RTX 5090 y RTX 6000 PRO sin respuesta, mientras H100/B200/RTX 4090 no replican el fallo.
- NVIDIA reconoce el bug; existe una mitigación parcial con kernel de Proxmox, pero no es solución definitiva.
- Mitigar D3cold, bind temprano con VFIO y ajustar Hyper-V/VBS mejora estabilidad y rendimiento en VMs.
La comunidad está detectando un fallo de virtualización que afecta a dos gráficas clave de NVIDIA: GeForce RTX 5090 y RTX 6000 PRO. No hablamos de un contratiempo menor; en entornos con KVM y VFIO, tras días o semanas de carga continua, hay casos en los que la GPU queda bloqueada dentro de la máquina virtual sin responder a ningún estímulo.
Este comportamiento, reportado con detalle por desarrolladores que montan nubes de GPU para IA, no se replica en otros modelos como H100, B200 o incluso en una RTX 4090 previa. El patrón apunta a que el problema se concentra en las gamas de consumo y ProViz, mientras que las tarjetas orientadas a centros de datos parecen librarse del fallo en cuestión.
Qué está pasando exactamente
El síntoma más repetido es una congelación total de la VM tras periodos prolongados de uso intensivo, que aparece de forma aleatoria, sin un desencadenante claro ni eventos previos que lo anticipen. Quien lo sufre describe que la GPU deja de responder por completo y el host termina registrando un error de tiempo de espera.
Se ha verificado el comportamiento comparando varias generaciones y familias de GPU. Equipos de pruebas han alternado aceleradoras de la familia Blackwell y Ada con resultados dispares: H100, B200 y RTX 4090 no manifestaron el bug, pero la pareja RTX 5090/RTX 6000 PRO sí lo hizo. Esta diferencia sugiere que el origen no es el hipervisor ni el kernel en sí, sino algo particular del manejo del reset en estas dos tarjetas.
La congelación no requiere cargas exóticas: basta con ejecutar cargas sostenidas durante días o semanas en máquinas que hacen passthrough de GPU. Cuando el dispositivo debe reinicializarse como parte de los ciclos de vida normales de una VM, la tarjeta no vuelve a un estado operativo y queda inaccesible para el sistema.
Para incentivar la investigación, un proveedor implicado ha ofrecido una recompensa pública de 1.000$ a quien consiga aislar y resolver el problema, lo cual da una idea tanto de la severidad del bug como del interés en que llegue una solución estable cuanto antes.
La mecánica técnica del fallo
En términos de bajo nivel, el eslabón crítico es el PCIe Function-Level Reset (FLR), que el host ejecuta al parar una VM o mover el dispositivo. En entornos con KVM y VFIO, ese FLR forma parte de la rutina de limpieza para dejar la GPU en un estado consistente antes del siguiente uso.
El comportamiento incorrecto se produce justo después del FLR: en lugar de reanudar correctamente, la tarjeta no retorna a D0 ni responde a las operaciones de inicialización subsiguientes. El kernel espera el tiempo máximo y finalmente informa de que se da por vencido.
El mensaje de error más característico que han visto los afectados aparece en el log del kernel y luce así:
"not ready 65535ms after FLR; giving up"
Este texto es una pista clara: el FLR ha ocurrido, pero la GPU no está lista tras más de 65,5 segundos, que es el umbral de paciencia por defecto del kernel antes de abandonar. Dado que el resto de la cadena (hipervisor, VFIO, pila del kernel) hace su trabajo, el foco de la culpa apunta a la electrónica o firmware de la propia tarjeta en estas SKU concretas.
Reconocimiento de NVIDIA y estado del parche
Según usuarios y administradores que lo han reportado en foros técnicos de referencia, NVIDIA ha reconocido el bug. A día de hoy se habla de una mitigación parcial basada en actualizar el kernel de Proxmox a una compilación específica mediante apt, lo que reduce la frecuencia o severidad del problema, pero no lo elimina al cien por cien.
La instrucción concreta que se está compartiendo como atajo temporal es:
apt install proxmox-kernel-6.14.8-2-bpo12-pve/stable
Es importante entender que esto es una mitigación y no una solución definitiva. Se espera un parche oficial que llegue en forma de actualización de driver, del kernel de Linux, o potencialmente de ambos, de manera que el FLR vuelva a dejar la tarjeta en un estado operativo garantizado y estable.
Ecosistema y ruido en las fuentes
Buena parte de los testimonios y datos proviene de foros técnicos y redes sociales. Algunos hilos en Reddit incluyen las típicas capas de consentimiento de cookies y páginas intersticiales de privacidad, y en X hay vistas que exigen JavaScript habilitado para leer el contenido, lo que añade ruido al seguimiento del caso.
Aun con ese ruido, la tendencia es clara: más usuarios se suman a los reportes, y los patrones técnicos coinciden entre sí, reforzando la validez de la hipótesis del problema ligado al manejo del reset/energía en estas tarjetas concretas bajo virtualización.
Casos prácticos: rendimiento en juegos y ajustes de VM
Además del fallo de reset, hay experiencias de usuarios que, al configurar passthrough de gráficas de la serie 50 en Windows invitado, han visto rendimientos irregulares en juegos actuales. En un caso, títulos como Lies of P o Elden Ring se quedaban clavados en torno a 60 FPS o promediaban 40 FPS a máxima calidad sin trazado de rayos, pese a tener CPU y almacenamiento lejos del límite.
En esa misma configuración, se habían reservado 16 hilos de CPU (agrupados en el mismo L3) y se ocultaba la naturaleza virtual a Windows con el ajuste de KVM oculto. Tras investigar, el cuello resultó estar relacionado con VBS (Virtualization-Based Security) y ciertos flags de Hyper-V/virtio en el XML de libvirt, que al ajustarse mejoraron de forma notable los fotogramas por segundo.
La activación de hyperv passthrough con parámetros concretos, junto con mantener oculto KVM y desactivar el vmport, elevó el rendimiento a cifras acordes con el hardware: 60 FPS estables en Elden Ring a 3840×1600 con calidad máxima y RT alto (con pequeñas caídas durante cargas), y más de 144 FPS en Lies of P.
El bloque de características de libvirt que propició esa mejora incluía algo similar a esto (representación escapada):
<features>
<acpi/>
<apic/>
<hyperv mode="passthrough">
<relaxed state="on"/>
<vapic state="on"/>
<spinlocks state="on" retries="8191"/>
</hyperv>
<kvm><hidden state="on"/></kvm>
<vmport state="off"/>
<smm state="on"/>
</features>
<cpu mode="host-passthrough" check="full" migratable="on">
<topology sockets="1" dies="1" cores="8" threads="2"/>
<cache mode="passthrough"/>
<feature policy="require" name="topoext"/>
<feature policy="disable" name="svm"/>
<feature policy="require" name="hypervisor"/>
</cpu>
En paralelo, mantener KVM oculto en el invitado fue clave, con el clásico bloque:
<kvm><hidden state="on"/></kvm>
Configuración de hardware y sistema reproducida
Para contextualizar los resultados anteriores, el equipo anfitrión y el invitado estaban construidos así, con detalles que ayudan a replicar el entorno y a descartar otros cuellos de botella ajenos a la GPU.
Build y versiones relevantes: Ubuntu 24.04, kernel 6.8.0-52, Secure Boot activo; Looking-Glass B7; placa TRX50 Sage WiFi; CPU Threadripper 7980X; GPU del host RTX A2000 12 GB con controladores abiertos 570.133.07; GPU invitada RTX 5080 con controladores Windows 576.02.
En BIOS se especificó lo siguiente: CSM habilitado, Resizable BAR desactivado, SR-IOV desactivado, SVM habilitado. Aunque no todos estos puntos afectan al bug del FLR, sí condicionan la estabilidad general del passthrough y el soporte de dispositivos.
Para amarrar el arranque, la línea de GRUB incluía parámetros de IOMMU y binding de VFIO, junto con un ajuste para reasignación PCIe:
GRUB_CMDLINE_LINUX_DEFAULT="pci=realloc=off amd_iommu=on iommu=pt \
vfio-pci.ids=10de:2c02,10de:22e9 \
vfio_iommu_type1.allow_unsafe_interrupts=1"
La configuración de módulos también contemplaba dependencias suaves para dar prioridad a VFIO frente a los drivers de NVIDIA o nouveau y atar los IDs de dispositivo de la RTX 5080 a vfio-pci:
# /etc/modprobe.d/vfio.conf
softdep nvidia pre: vfio-pci
softdep nouveau pre: vfio-pci
options vfio-pci ids=10de:2c02,10de:22e9
Y el dispositivo PCI se expuso a la VM con ROM BAR habilitado mediante un hostdev estándar como el siguiente:
<hostdev mode="subsystem" type="pci" managed="yes">
<driver name="vfio"/>
<source>
<address domain="0x0000" bus="0x42" slot="0x00" function="0x0"/>
</source>
<alias name="hostdev0"/>
<address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
</hostdev>
Con todo lo anterior se demostró que, una vez ajustado el stack de virtualización y las flags de Hyper-V, el rendimiento de juegos modernos se alineaba con lo esperable, manteniendo la GPU en torno al 100% cuando tocaba y a latencias estables en la ruta de presentación.
Síntomas de energía: D3cold → D0 y mitigaciones
Un conjunto de registros del kernel apunta a problemas al reactivar el dispositivo desde estados de energía profundos. En particular, mensajes del tipo:
vfio-pci 0000:02:00.0: Unable to change power state from D3cold to D0, device inaccessible
vfio-pci 0000:02:00.1: Unable to change power state from D3cold to D0, device inaccessible
Estos logs sugieren que la GPU o su función de audio quedan en D3cold y no vuelven a D0 a tiempo para que la VM las inicialice, lo que encaja con los fallos post-FLR. Varias mitigaciones ayudan a contener este escenario en el host, evitando que el dispositivo entre en estados de reposo demasiado agresivos.
Mitigación 1: añadir un parámetro de kernel para desactivar el idle D3 en general. En /etc/default/grub, sumar a las opciones:
disable_idle_d3=1
Mitigación 2: bind temprano y bloqueo del runtime D3 de la GPU y su función de audio, por ejemplo con una RTX 5090 (IDs 10de:2b85 y 10de:22e8):
# /etc/modprobe.d/vfio-pci.conf
# RTX 5090 GPU (10de:2b85) + Audio (10de:22e8)
# Bind a vfio-pci y evita runtime D3 (D3cold)
options vfio-pci ids=10de:2b85,10de:22e8 disable_vga=1 disable_idle_d3=1
Mitigación 3: reglas de udev para forzar power/control=on y negar d3cold en ambas funciones del dispositivo:
# /etc/udev/rules.d/99-vfio-gpu-pm.rules
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{device}=="0x2b85", ATTR{power/control}="on", ATTR{d3cold_allowed}="0"
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{device}=="0x22e8", ATTR{power/control}="on", ATTR{d3cold_allowed}="0"
Tras aplicar los cambios conviene regenerar el initramfs, recargar reglas y reiniciar para consolidar el estado del sistema:
update-initramfs -u
udevadm control --reload-rules
udevadm trigger -s pci
update-grub
reboot
Estas medidas no arreglan el bug de raíz, pero reducen la probabilidad de que el dispositivo entre en estados del tipo D3cold de los que no pueda volver a tiempo, lo que en la práctica disminuye la incidencia de cuelgues tras ciclos de apagado/encendido de la VM.
Por qué no fallan H100, B200 y RTX 4090
La evidencia recopilada sugiere que las tarjetas de centros de datos y algunas de la generación anterior manejan mejor la secuencia de reset y la transición de energía. H100 y B200 (y, en las pruebas referenciadas, también la RTX 4090) superan el FLR y regresan a D0 sin dramas, lo que apunta a diferencias de firmware, lógica de gestión de energía o tolerancias de tiempo en cada SKU.
Esto explica por qué infraestructuras con mezcla de GPUs no ven el problema en todos los nodos. Aun así, los entornos con RTX 5090 o RTX 6000 PRO en modo passthrough son los que, a día de hoy, están en el punto crítico y deben extremar mitigaciones hasta que lleguen parches oficiales.
Buenas prácticas mientras llega el parche oficial
Mientras se estabiliza el stack, conviene acotar cambios y documentar a conciencia. Mantén un único vector de modificación cada vez (kernel, driver, libvirt, firmware de la placa) para poder aislar efectos. Y evita reinicios/suspensiones automáticos de VMs que disparen FLR innecesarios en horarios de producción.
También ayuda configurar watchdogs/alertas en el host para detectar eventos de FLR y estados de energía profundos, y orquestar reinicios controlados de la VM si se detecta que el dispositivo no vuelve a un estado operativo tras un timeout.
Si operas en Proxmox, evaluar la mitigación del kernel propuesta puede reducir impactos, pero no olvides que es una solución temporal. En entornos críticos, considera escalonar despliegues y mantener ventanas de mantenimiento más generosas.
Para cargas de gaming/creativas dentro de VMs Windows, revisa los flags de Hyper-V, el modo host-passthrough de CPU, la ocultación de KVM y parámetros como vmport=off. En el caso práctico descrito, ajustar VBS y Hyper-V marcó la diferencia entre un techo artificial de FPS y el rendimiento real de la tarjeta.
Qué podemos esperar a corto y medio plazo
El reconocimiento del bug por parte de NVIDIA sugiere que veremos una corrección distribuida vía controlador, kernel, o ambos. Hasta entonces, la combinación de evitar D3cold, asegurar binding temprano con VFIO, y minimizar FLR innecesarios es la estrategia más razonable.
Iniciativas como la recompensa de 1.000$ indican voluntad de acelerar el diagnóstico. A medida que se publiquen más datos oficiales, irá quedando claro si el arreglo requiere cambios de firmware en las tarjetas, ajustes de tiempo en la ruta de reset o modificaciones en el manejo de energía del lado del driver.
Mientras tanto, los hilos de foros y redes —pese a banners de cookies o requisitos de JavaScript— siguen aportando trazas, dmesg y configuraciones reproducibles que ayudan a perfilar el problema y a afinar workarounds en producción sin arriesgar la estabilidad del resto del clúster.
El panorama actual dibuja un fallo real pero acotable con buenas prácticas y mitigaciones prudentes. Con la evidencia de que H100, B200 y RTX 4090 no están afectadas en las mismas condiciones, y con un kernel Proxmox que reduce el impacto en RTX 5090/RTX 6000 PRO, es razonable seguir operando con cautela, vigilando los logs y aplicando parches en cuanto estén disponibles.