ACS Override en Proxmox: El atajo que puede costarte estabilidad (Haz esto en su lugar)

febrero 21, 2026 • febrero 21, 2026 • Lectura: 29 min • Views: 1

¿Te fue útil?

Lo hiciste. Activaste el passthrough PCIe en Proxmox, miraste grupos IOMMU que parecían un cajón de trastos,
y alguien en un foro pronunció las palabras mágicas: “ACS override”. Un reinicio después tu GPU por fin aparece dentro de la VM.
Te sientes astuto. Te vas a dormir.

Y entonces el host empieza a comportarse como si estuviera encantado: congelaciones intermitentes de VMs, timeouts de NVMe, reinicios espontáneos bajo carga,
o ese goteo lento de errores PCIe “corregidos” que se convierte en una interrupción un viernes. ACS override no “arregló” tu plataforma.
Le dijo al kernel que fingiera que tu hardware está más aislado de lo que realmente está. A veces eso está bien. A veces es una trampa.

Qué hace realmente ACS override (y qué no hace)

En el mundo PCIe, no “haces passthrough de un dispositivo” tanto como convenceras al host de dejar de tocarlo y luego darle a una VM
la propiedad directa vía VFIO. La seguridad y estabilidad de ese arreglo dependen de límites de aislamiento que la plataforma
provee: agrupación IOMMU, capacidades ACS, remapeo de interrupciones, comportamiento de reset y la topología PCIe en sí.

ACS (Access Control Services) es un conjunto de funciones PCIe que pueden hacer cumplir cómo se enrutan las transacciones y pueden prevenir DMA peer-to-peer
donde no debería suceder. En la práctica, ACS es una gran razón por la que los dispositivos pueden acabar en grupos IOMMU separados. Si ACS no está presente
(o no está habilitado) en una ruta descendente dada, el kernel puede tener que asumir que los dispositivos detrás del mismo puente PCIe pueden comunicarse entre sí.
Esa suposición los obliga a estar en el mismo grupo IOMMU.

La opción “ACS override” de Linux no hace que tu placa base de repente aprenda trucos nuevos. Es un parámetro del kernel que puede
dividir artificialmente grupos IOMMU al fingir que existe aislamiento ACS donde el kernel no puede probarlo.
Eso es útil cuando quieres pasar un dispositivo de un grupo que contiene otras cosas que quieres mantener en el host.

Aquí viene la parte incómoda: con ACS override puedes crear una configuración que parece aislada para VFIO y el gestor de VM,
pero que no está aislada en el bus. Si dos dispositivos todavía pueden hacer DMA peer-to-peer o compartir una ruta ascendente sin el aislamiento adecuado,
has construido un sistema que “funciona” hasta que deja de hacerlo. Puedes ver fallos, riesgos de corrupción de datos o patologías de rendimiento raras
que no se reproducen de forma limpia.

Si haces esto en un laboratorio casero, tu tolerancia al riesgo puede ser “aceptable”. En producción—o en cualquier cosa por la que te culpen—trata ACS override
como una herramienta diagnóstica temporal, no como una arquitectura permanente.

Qué cambia ACS override

Cambia la formación de grupos. Los dispositivos pueden aparecer en grupos IOMMU separados incluso si la plataforma no aplica esa separación.
Cambia lo que Proxmox te permite hacer. Puedes vincular un único dispositivo a VFIO sin arrastrar todo el grupo.

Qué no cambia ACS override

No añade aislamiento hardware. Si la ruta PCIe carece de ACS, sigue careciendo de ACS.
No arregla resets defectuosos. Los “bugs” de reset de GPU y los problemas con FLR permanecen.
No garantiza seguridad frente a DMA. En el peor caso, un dispositivo pasado puede aún influir en la memoria del host u otros dispositivos.
No soluciona problemas de remapeo de interrupciones. Si tu plataforma no puede remapear interrupciones correctamente, aún puedes tener bloqueos difíciles de depurar.

Una cita que debería vivir en tu cabeza cuando te tientan las banderas mágicas es de John Ousterhout:
“La complejidad es incremental.” Rara vez notas la primera concesión. Seguro que notas la décima.

Por qué la gente recurre a ACS override en Proxmox

Proxmox hace accesible VFIO. Eso es bueno. Pero los fabricantes de hardware no diseñan plataformas de consumidor para crear grupos IOMMU limpios;
las diseñan para cumplir puntos de precio y listas de características de marketing. Así que obtienes las molestias clásicas:

Tu GPU está agrupada con el controlador USB del chipset y el controlador SATA.
Tus ranuras NVMe comparten un puerto raíz con algo que necesitas en el host.
Tu HBA está detrás de un puente con otros dispositivos que no puedes pasar.
Tu plataforma tiene IOMMU habilitado pero el remapeo de interrupciones es parcial o inestable.

ACS override parece la salida más fácil. Y para mucha gente, “funciona”. La VM arranca, el dispositivo aparece, los benchmarks se ven bien,
y sigues con tu vida.

Broma #1: ACS override es como usar cinta adhesiva como viga estructural. Aguanta hasta que la gravedad recuerda que existes.

El coste para la estabilidad: modos de fallo reales que puedes encontrar

Hablemos de formas concretas en que esto se complica. No teorías tipo “investigadores de seguridad podrían…”. Dolor operativo real.

1) Sorpresas de DMA y peer-to-peer

Si dos dispositivos no están realmente aislados, un dispositivo pasado puede alcanzar memoria u otros dispositivos de maneras que no pretendías.
Incluso si no te preocupa un comportamiento malicioso, el “peer-to-peer inesperado” puede manifestarse como:

Inestabilidad del host cuando el driver de la VM habilita características avanzadas.
Timeouts de dispositivo bajo carga que parecen problemas de cableado (aunque sea PCIe).
Comportamiento no determinista cuando varias VMs compiten en rutas ascendentes compartidas.

2) Remapeo de interrupciones y congelaciones “aleatorias”

Algunas plataformas soportan la traducción IOMMU pero tienen remapeo de interrupciones débil o con bugs. Cuando pasas dispositivos que generan muchas interrupciones
(GPUs, NVMe, HBAs, NICs), puedes obtener bloqueos de VM o bloqueos totales del host. La gente culpa a los drivers. A veces el driver está bien.
La tubería de interrupciones de la plataforma es la villana.

3) Spam de AER de PCIe que ignoras hasta que muerde

Advanced Error Reporting (AER) registra errores PCIe corregidos y no corregidos. Los errores corregidos pueden parecer inofensivos—hasta que la tasa aumenta y el rendimiento cae,
o hasta que un error no corregido escala a un reset de dispositivo en medio de una IO. ACS override no provoca errores AER por sí mismo, pero puede hacer que pongas
dispositivos de alta carga detrás de topologías cuestionables, lo que hace que los enlaces marginales muestren su verdadera personalidad.

4) El fallo “funcionó durante meses”

Las interrupciones más desagradables son las que esperan. Una actualización del kernel cambia el timing. Una carga de VM cambia las tasas de interrupción. Un nuevo driver habilita ASPM de forma diferente.
De repente tu passthrough previamente “estable” se convierte en una ruleta.

5) Riesgo de corrupción de almacenamiento al pasar el dispositivo equivocado

Pasar un HBA puede ser una gran opción para ZFS dentro de una VM—cuando se hace sobre límites de aislamiento reales. Con ACS override en una topología inestable,
el perfil de riesgo cambia. “Pero ZFS tiene sumas de verificación” no es un campo de fuerza. Las sumas te dicen que algo salió mal; no garantizan que puedas recuperar
sin tiempo de inactividad, pérdida de datos o ambos.

6) Acantilado de rendimiento: complejos raíz compartidos y contención oculta

La división de grupos puede engañarte haciéndote creer que los dispositivos tienen rutas independientes. Podrían aún compartir el presupuesto de ancho de banda de un puerto raíz,
compartir el uplink de un switch o compartir carriles del chipset con cuellos de botella DMI. Puedes obtener:

Picos de latencia NVMe cuando la GPU está bajo carga.
Pérdida de paquetes o jitter en NICs en passthrough durante ráfagas de almacenamiento.
Soft lockups de CPU causados por tormentas de interrupciones cuando el sistema no puede remapear eficientemente.

Datos e historia interesantes (breve, útil y algo nerd)

La semántica de grupos IOMMU en Linux es conservadora por diseño. El kernel agrupa dispositivos si no puede probar aislamiento. Eso es paranoia intencional, no pereza.
ACS surgió de la necesidad de la especificación PCIe para gestionar multi-función y telas con switches. Los servidores con switches PCIe y muchos endpoints necesitaban funciones de aplicación; los sobremesas a menudo no se molestan.
VT-d (Intel) y AMD-Vi (IOMMU de AMD) maduraron con el auge de la virtualización. Hubo implementaciones tempranas, pero el passthrough robusto se volvió corriente cuando la virtualización dejó de ser nicho.
Proxmox no inventó VFIO; lo operacionalizó. VFIO es un framework del kernel Linux; Proxmox es la cara amigable que hace a la gente valiente para pulsar “Add PCI Device”.
El remapeo de interrupciones fue el momento “ah, claro”. La traducción de direcciones por sí sola no bastaba; la asignación segura de dispositivos necesita que las interrupciones se manejen con igual rigor.
Los chipsets de consumo frecuentemente cuelgan dispositivos del mismo puerto ascendente. Por eso tu controlador USB y tu controlador SATA pueden acabar casados en el mismo grupo IOMMU.
El comportamiento de reset de GPUs ha sido un punto doloroso recurrente. El soporte FLR varía, los drivers de los fabricantes varían, y el resultado es el famoso patrón “funciona hasta que reinicias la VM”.
El registro AER es más antiguo de lo que mucha gente piensa. PCIe hace tiempo que tiene forma de decirte que el enlace está enfermo; simplemente nos volvimos muy buenos ignorándolo.
ACS override existe porque los usuarios lo pidieron. Es una herramienta pragmática para desarrollo y laboratorios caseros, no un sello de aprobación arquitectónica.

Guía de diagnóstico rápido (encuentra el cuello de botella)

Cuando el passthrough es inestable, puedes perder días en folklore de drivers. No lo hagas. Empieza por la topología y la evidencia.
Este es el orden que más tiempo me ha ahorrado.

Primero: confirma que realmente tienes IOMMU + remapeo de interrupciones

Revisa la línea de comandos del kernel para las opciones IOMMU de AMD/Intel.
Busca en dmesg “DMAR” (Intel) o “AMD-Vi” y remapeo de interrupciones habilitado.
Si falta/está deshabilitado el remapeo de interrupciones, espera bloqueos extraños bajo carga.

Segundo: inspecciona grupos IOMMU y la topología PCIe real

Lista los grupos desde /sys/kernel/iommu_groups.
Compáralo con lspci -t y lspci -vv para ver qué dispositivos comparten puentes/puertos raíz.
Si ACS override está habilitado, trata las divisiones de grupo como “lógicas”, no necesariamente “físicas”.

Tercero: busca AER, reset y errores VFIO

Busca en los logs AER, DPC, “BAR”, “vfio”, “DMAR fault”, “IOMMU fault”.
Correlaciona con los tiempos de carga. Si los errores aparecen cuando la VM arranca/para, sospecha comportamiento de reset/FLR.

Cuarto: aísla variables con un cambio a la vez

Desactiva ACS override temporalmente y comprueba si el problema desaparece (aunque rompa tu layout).
Mueve el dispositivo a otra ranura/puerto raíz si es posible.
Actualiza firmware/BIOS solo después de haber capturado logs base.

Quinto: decide si esto es un problema arquitectónico

Si la plataforma no puede proveer aislamiento estable, no vas a “afinar” para solucionarlo. Reemplazas hardware, o cambias el diseño:
otra NIC, otra GPU, otra ranura, otra placa, o no usar passthrough.

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

Estas son las comprobaciones que realmente ejecuto en Proxmox (basado en Debian) cuando alguien dice “ACS override lo arregló” y quiero saber a qué nos comprometimos.
Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Confirmar que IOMMU está habilitado en el kernel en ejecución

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet amd_iommu=on iommu=pt

Qué significa: Has arrancado con AMD IOMMU habilitado; iommu=pt usa modo passthrough para dispositivos del host (a menudo bien para rendimiento).

Decisión: Si no ves intel_iommu=on o amd_iommu=on, arregla eso antes de tocar ACS override o VFIO.

Task 2: Verificar IOMMU y remapeo de interrupciones en dmesg (Intel)

cr0x@server:~$ dmesg -T | egrep -i "DMAR|IOMMU|remapping" | head -n 20
[Tue Feb  4 10:12:11 2026] DMAR: IOMMU enabled
[Tue Feb  4 10:12:11 2026] DMAR-IR: Enabled IRQ remapping in x2apic mode

Qué significa: Intel VT-d está activo y el remapeo de IRQ está habilitado. Ese es el camino bueno.

Decisión: Si ves “IRQ remapping disabled” o nada sobre IR, asume mayor riesgo para la estabilidad del passthrough.

Task 3: Verificar IOMMU y remapeo de interrupciones en dmesg (AMD)

cr0x@server:~$ dmesg -T | egrep -i "AMD-Vi|IOMMU|remap|IVRS" | head -n 30
[Tue Feb  4 10:12:10 2026] AMD-Vi: IOMMU performance counters supported
[Tue Feb  4 10:12:10 2026] AMD-Vi: Interrupt remapping enabled

Qué significa: AMD IOMMU funciona y el remapeo de interrupciones está habilitado.

Decisión: ¿Sin remapeo de interrupciones? No “taparlo” con ACS override. Espera problemas con dispositivos de alta interrupción.

Task 4: Comprobar si ACS override está habilitado

cr0x@server:~$ grep -R "pcie_acs_override" -n /etc/default/grub /etc/kernel/cmdline 2>/dev/null
/etc/default/grub:6:GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"

Qué significa: ACS override está explícitamente habilitado.

Decisión: Trata cada grupo IOMMU “limpio” como sospechoso hasta probar topología y bits de capacidad ACS.

Task 5: Enumerar grupos IOMMU de forma directa

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}:"; lspci -nns $(ls "$g"/devices | sed 's/^/0000:/'); echo; done | head -n 40
Group 12:
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
03:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba] (rev a1)

Group 13:
04:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Qué significa: GPU y su función de audio están agrupadas (esperado). NVMe está en un grupo diferente (bien, tal vez).

Decisión: Si controladores críticos del host comparten grupo con el dispositivo que quieres, no saltes aún a ACS override. Mapea la topología primero.

Task 6: Ver la topología PCIe como un árbol (quién comparte qué puente)

cr0x@server:~$ lspci -t
-+-[0000:00]-+-00.0
 |           +-01.0-[01]----00.0
 |           +-03.0-[02-05]--+-00.0
 |           |               +-00.1
 |           |               \-01.0
 |           \-08.1-[06]----00.0

Qué significa: Los dispositivos detrás del mismo puerto descendente pueden compartir restricciones de aislamiento. La división de grupos que contradice este árbol es una bandera roja.

Decisión: Si tu dispositivo objetivo está bajo un switch/puente con otros dispositivos, considera mover ranuras o usar una placa con mejor separación de puertos raíz.

Task 7: Comprobar si los puentes relevantes anuncian capacidad ACS

cr0x@server:~$ lspci -vv -s 00:03.0 | egrep -i "ACSCap|ACSCtl|PCIe Cap|Root Port" -n
45:00:03.0 PCI bridge: Intel Corporation Device 7a44 (rev 11)
86:	Capabilities: [148 v1] Access Control Services
87:		ACSCap: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+ EgressCtrl- DirectTrans+
88:		ACSCtl: SrcValid+ TransBlk+ ReqRedir+ CmpltRedir+ UpstreamFwd+

Qué significa: Este puente tiene ACS. Eso es bueno; la separación de grupos aquí tiene más probabilidad de ser “real”.

Decisión: Si el puente carece de capacidad ACS pero dependes de ACS override para dividir dispositivos detrás de él, estás apostando a una mentira.

Task 8: Confirmar bindings VFIO para el dispositivo en passthrough

cr0x@server:~$ lspci -nnk -s 03:00.0
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:5162]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Qué significa: La GPU está vinculada a vfio-pci, no al driver gráfico del host.

Decisión: Si ves el driver del fabricante en uso, arregla el binding antes de depurar estabilidad. Dispositivos medio vinculados crean problemas fantasma.

Task 9: Buscar fallos IOMMU y errores DMAR/AMD-Vi durante el uso de la VM

cr0x@server:~$ journalctl -k --since "2 hours ago" | egrep -i "DMAR|AMD-Vi|IOMMU fault|vfio|AER" | tail -n 30
Feb 04 09:41:22 server kernel: vfio-pci 0000:03:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258
Feb 04 09:58:03 server kernel: pcieport 0000:00:03.0: AER: Corrected error received: 0000:04:00.0
Feb 04 09:58:03 server kernel: nvme 0000:04:00.0: AER: [0] RxErr (First)

Qué significa: Errores PCIe corregidos en el enlace NVMe. No son instantáneamente fatales, pero te dicen que el enlace físico está descontento.

Decisión: Si los errores corregidos ocurren bajo carga o aumentan con el tiempo, trátalo como si fuese un cable defectuoso—aunque el “cable” sea tu ranura, riser, alimentación o señalización PCIe marginal.

Task 10: Comprobar si tu NVMe está perdiendo colas o haciendo timeouts

cr0x@server:~$ journalctl -k --since "24 hours ago" | egrep -i "nvme.*timeout|I/O.*timeout|resetting controller|frozen" | tail -n 20
Feb 03 22:14:19 server kernel: nvme nvme0: I/O 124 QID 7 timeout, aborting
Feb 03 22:14:19 server kernel: nvme nvme0: Abort status: 0x371
Feb 03 22:14:20 server kernel: nvme nvme0: resetting controller

Qué significa: El controlador NVMe está haciendo timeout y reiniciándose. Si esto coincide con carga de GPU/VM, sospecha contención en la ruta PCIe compartida o problemas de señalización.

Decisión: No culpes a ZFS primero. Arregla el transporte. Considera mover el NVMe a una ranura conectada a CPU o desactivar la gestión de energía agresiva.

Task 11: Confirmar funciones de virtualización y visibilidad IOMMU

cr0x@server:~$ pveversion -v | head -n 5
proxmox-ve: 8.2.2 (running kernel: 6.8.12-4-pve)
pve-manager: 8.2.2 (running version: 8.2.2/1a3f7d3e)
pve-kernel-6.8: 6.8.12-4

Qué significa: Puedes correlacionar comportamiento con versiones de kernel. Regresiones de VFIO y peculiaridades PCIe pueden ser específicas del kernel.

Decisión: Si la inestabilidad empezó justo después de una actualización de kernel, prueba el kernel anterior de Proxmox antes de cambiar hardware o “tocar” a ciegas.

Task 12: Inspeccionar la configuración QEMU de la VM para opciones de passthrough que afectan reset y ROM

cr0x@server:~$ cat /etc/pve/qemu-server/101.conf
agent: 1
bios: ovmf
boot: order=scsi0;net0
cpu: host
hostpci0: 0000:03:00,pcie=1,x-vga=1
machine: q35
memory: 16384
name: gpu-vm
net0: virtio=DE:AD:BE:EF:00:01,bridge=vmbr0
ostype: win11
scsi0: local-lvm:vm-101-disk-0,size=200G

Qué significa: OVMF + q35 + cpu: host es una configuración típica de passthrough de GPU.

Decisión: Si ves BIOS legacy, i440fx, o combinaciones raras, estandariza primero. Depurar configs VM a medida es un impuesto que no necesitas.

Task 13: Comprobar si el dispositivo soporta FLR (Function Level Reset)

cr0x@server:~$ lspci -vv -s 03:00.0 | egrep -i "FLR|Reset" -n
210:	Capabilities: [1b0 v1] Transaction Processing Hints
233:	Capabilities: [300 v1] Secondary PCI Express
262:	Kernel driver in use: vfio-pci

Qué significa: Este fragmento no muestra FLR explícitamente; muchos dispositivos no lo anuncian claramente de forma que los usuarios lo noten. El comportamiento de reset sigue siendo importante operacionalmente.

Decisión: Si los reinicios de VM fallan a menos que reinicies el host, sospecha comportamiento de reset. Considera otro modelo de GPU o una topología donde el dispositivo se pueda apagar/power-cycle (p. ej., control de alimentación de ranura en algunas placas servidor).

Task 14: Validar que el host no está usando accidentalmente la GPU pasada para la consola

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x  2 root root       80 Feb  4 10:12 by-path
crw-rw----  1 root video 226,   0 Feb  4 10:12 card0
crw-rw----  1 root render 226, 128 Feb  4 10:12 renderD128

Qué significa: Existen dispositivos DRM. Si la GPU en passthrough está vinculada a VFIO, normalmente no debería aparecer como un dispositivo DRM activo para la pila del host.

Decisión: Si el host está usando la GPU (framebuffer/DRM), arregla eso: pon en blacklist los drivers, establece la GPU primaria en BIOS como iGPU/otra GPU, y asegúrate de que VFIO se vincule temprano.

Task 15: Confirmar que tu HBA está en un grupo limpio antes del passthrough

cr0x@server:~$ lspci -nn | egrep -i "SAS|HBA|LSI|Broadcom|MegaRAID"
81:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)

cr0x@server:~$ readlink -f /sys/bus/pci/devices/0000:81:00.0/iommu_group
/sys/kernel/iommu_groups/26

Qué significa: El HBA está en el grupo 26. Ahora lista qué más hay en ese grupo antes de pasarlo.

Decisión: Si el grupo contiene algo además del HBA (o sus funciones esperadas), no confíes en ACS override para “hacerlo bien”. Cambia ranuras o placa.

Task 16: Comprobar pistas de conexión CPU/chipset (rápido e informal)

cr0x@server:~$ lspci -vv -s 04:00.0 | egrep -i "LnkCap|LnkSta" 
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 16GT/s, Width x4

Qué significa: El enlace está a la velocidad/anchura esperada. Si ves ancho x1 o velocidad menor a la esperada, has encontrado una pista de rendimiento y estabilidad.

Decisión: Arregla el asiento físico, ajustes BIOS PCIe, risers o elección de ranura antes de culpar a Proxmox o VFIO.

Tres microhistorias corporativas del mundo real

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana montó un clúster Proxmox para agentes de build y algunos servicios internos. Tenían una máquina con GPU para cargas de CI:
pruebas de navegador, codificación de vídeo y algunos trabajos CUDA. La GPU vivía en una placa tipo workstation que parecía “casi servidor”.

El ingeniero que lo montó encontró grupos IOMMU feos y habilitó ACS override. La VM con la GPU arrancó. Los benchmarks se veían bien. Todos siguieron con su trabajo.
Su suposición era simple: “Si está en su propio grupo IOMMU, está aislada.” El kernel lo dijo. Así que debe ser verdad.

Semanas después empezaron a ver fallos esporádicos en VMs completamente no relacionadas en ese mismo host. No todos los días. No con todas las cargas.
Los fallos eran enloquecedores: una VM se congelaba 30–90 segundos, se recuperaba y luego tenía estado de aplicación corrupto. A veces el host registraba errores PCIe corregidos.
A veces nada.

El patrón eventual fue que las congelaciones se correlacionaban con actividad DMA alta de la GPU y IO NVMe alta al mismo tiempo.
La topología PCIe mostraba ambos dispositivos detrás de un puerto ascendente compartido sin capacidad ACS adecuada. ACS override había dividido los grupos lógicamente,
pero el bus aún podía comportarse como un vecindario compartido con paredes delgadas.

La solución fue aburrida y cara: movieron la GPU a otra ranura, que la puso en un puerto raíz distinto, y reemplazaron un riser que era marginal a velocidades Gen4.
Deshabilitaron ACS override después de confirmar que los grupos estaban limpios sin él. La estabilidad volvió inmediatamente. Nadie extrañó la “astucia”.

Microhistoria 2: La optimización que salió mal

Otra organización intentó exprimir máximo rendimiento de un host Proxmox orientado a storage. Pasaban un HBA a una VM TrueNAS
y también pasaban una NIC de alta velocidad a una VM router. La placa no les daba grupos limpios. ACS override parecía una forma de evitar comprar nueva plataforma.

También activaron iommu=pt y varios ajustes “de rendimiento” en BIOS: tweaks de ASPM, desactivar ahorros agresivos de energía y forzar velocidades PCIe.
El objetivo era baja latencia y alto rendimiento. El resultado fue… benchmarks inicialmente impresionantes.

Luego llegó el contragolpe: bajo tráfico sostenido, la VM de la NIC a veces perdía enlace por un segundo. No lo suficiente para disparar alarmas claras,
pero lo bastante para provocar retransmisiones TCP y timeouts en aplicaciones aguas arriba. Mientras tanto la VM de almacenamiento registraba resets ocasionales de controlador.
El host en sí no se colgó, así que todos trataron el problema como si fuera de invitado.

No lo era. Era contención y recuperación de errores en una ruta PCIe compartida que ACS override había hecho fácil de ignorar.
La “optimización” aumentó la carga y empujó el enlace a un régimen de recuperación de errores. Los AER corregidos subieron. La latencia se volvió irregular.

Revirtieron los ajustes forzados de BIOS, luego movieron un dispositivo a una ranura conectada a CPU. El rendimiento bajó ligeramente en papel, pero la red dejó de fallar.
Las gráficas de servicio volvieron a ser aburridas. Aburrido es el objetivo.

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

Un equipo de servicios financieros ejecutaba Proxmox para cargas internas con un estricto proceso de gestión de cambios (sí, existen).
Querían passthrough de GPU para una pequeña carga analítica. El hardware era una placa servidor adecuada con puertos raíz claros y VT-d validado.

El SRE líder insistió en una lista de chequeo: capturar topología PCIe, registrar grupos IOMMU antes de cambios, validar remapeo de interrupciones y ejecutar una prueba burn-in.
Nada de ACS override a menos que pudieran probar capacidad ACS en la ruta ascendente. Esto fue impopular. La gente quería la VM ya.

Durante el burn-in, detectaron una corriente constante de errores AER corregidos en el puerto ascendente de la GPU a Gen4. El sistema “funcionaba”, pero los logs no estaban contentos.
Cambiaron la GPU a otra ranura y los errores desaparecieron. Probablemente era seating o integridad de señal en esa ranura, pero no necesitaban una respuesta filosófica.
Necesitaban operación limpia.

Meses después, una actualización de firmware cambió el comportamiento de equalización PCIe y otro equipo empezó a ver ruido AER en hosts similares.
Este equipo ya tenía logs base y snapshots de topología, así que pudieron comparar inmediatamente “antes” y “después”.
Evitaron días de conjeturas y acotaron el problema a una revisión BIOS específica.

Su práctica no era glamorosa. También fue la razón por la que nadie recibió una llamada a las 2 a.m.

Haz esto en su lugar: formas más seguras de conseguir passthrough

Si te tienta ACS override, normalmente significa que la plataforma no te da límites limpios. La respuesta correcta es arreglar límites,
no fingir que existen.

Opción A: Usa la ranura correcta (la topología es una característica)

Muchas placas tienen una o dos ranuras cableadas directamente al root complex de la CPU y otras cableadas a través del chipset.
Las ranuras conectadas a CPU tienden a tener aislamiento más limpio y menos sorpresas de “todo comparte todo”.

Mueve el dispositivo. Sí, físicamente. Es asombroso cuántos “problemas VFIO” son en realidad “elegiste la ranura que el diseñador de la placa usó por conveniencia”.

Opción B: Elige hardware con ACS real y agrupación IOMMU sensata

Placas servidor, placas workstation y algunas placas de consumidor de gama alta proporcionan mejor comportamiento ACS y más puertos raíz.
Esto no se garantiza por marca; es específico del modelo. Quieres:

Separación clara de carriles CPU vs carriles chipset
Capacidad ACS adecuada en puentes/puertos raíz
VT-d/AMD-Vi validado con remapeo de interrupciones

Opción C: Pasar todo el grupo (cuando sea razonable)

El kernel agrupa dispositivos porque no puede probar aislamiento. A veces el movimiento más simple y estable es aceptarlo:
pasa todo el grupo IOMMU a una sola VM y mantiene al host lejos de esos dispositivos por completo.

Esto funciona bien cuando el grupo es “GPU + audio GPU” o “controlador USB que puedes desprender”. Funciona mal cuando el grupo incluye almacenamiento o red
que necesitas para el host. Esa es tu señal de que la plataforma es el problema, no Proxmox.

Opción D: Deja de pasar la clase de dispositivo equivocada

Si quieres rendimiento de almacenamiento, no siempre necesitas passthrough de HBA. A veces una configuración virtio-scsi en el host con ZFS es más simple y segura.
Si quieres aceleración GPU para una aplicación específica, a veces un contenedor con acceso a dispositivo es suficiente (y evita el riesgo a nivel de bus).

Opción E: Si debes usar ACS override, delimítalo y prueba en serio

A veces estás atrapado. Presupuesto, restricciones de hardware, tiempo. Si decides usar ACS override aun así, trátalo como una quema controlada:

Habilítalo solo para validar viabilidad y luego intenta eliminarlo cambiando ranuras/hardware.
Haz pruebas burn-in bajo IO e interrupciones realistas.
Monitoriza AER, fallos IOMMU, resets y latencias de forma continua.
Tener un plan de reversión y documentar por qué se aceptó este riesgo.

Broma #2: Si tu plan de disponibilidad es “habilité ACS override y recé”, enhorabuena—has implementado infraestructura basada en la fe.

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

Aquí están los reincidentes. No son faltas morales. Solo patrones.

1) Síntoma: La VM funciona hasta el reinicio; luego falla el passthrough de la GPU

Causa raíz: Comportamiento de reset de la GPU (sin FLR o ruta de reset con bugs). El dispositivo no vuelve a un estado limpio tras apagar/reiniciar el invitado.

Solución: Prueba otro modelo de GPU, asegúrate de que el dispositivo no esté compartido, considera reiniciar el host como último recurso y evita que ACS override oculte problemas de topología. Si la estabilidad importa, elige hardware conocido por comportamiento de reset sensato.

2) Síntoma: El host se congela completamente bajo IO o carga de GPU

Causa raíz: Remapeo de interrupciones ausente/deshabilitado, o bugs de IOMMU de la plataforma desencadenados por altas tasas de interrupciones.

Solución: Confirma en dmesg que el remapeo de interrupciones está habilitado. Actualiza BIOS/firmware. Si IR no puede habilitarse de forma fiable, no hagas passthrough de dispositivos de alta interrupción en esa plataforma.

3) Síntoma: Picos de latencia en almacenamiento cuando la VM de GPU está ocupada

Causa raíz: Contención de ancho de banda en puerto raíz/switch uplink compartido, a menudo ocultada por la división de grupos ACS override.

Solución: Mueve dispositivos a diferentes puertos raíz de CPU; evita carriles del chipset para ambos dispositivos pesados. Verifica con lspci -t y ancho/velocidad de enlace.

4) Síntoma: Errores AER corregidos suben lentamente en los logs

Causa raíz: Señalización PCIe marginal (asiento de ranura, riser, alimentación, forzado de velocidad Gen, o diseño de placa).

Solución: Vuelve a asentar el dispositivo, quita risers, revierte ajustes PCIe forzados, prueba otra ranura y considera limitar la velocidad de enlace (como diagnóstico) para ver si los errores desaparecen.

5) Síntoma: “El dispositivo está en su propio grupo IOMMU” pero ocurren efectos cruzados raros

Causa raíz: ACS override creó grupos lógicos sin aplicación ACS real.

Solución: Desactiva ACS override y vuelve a comprobar grupos. Si la separación desaparece, no confíes en la división falsa—cambia hardware/topología.

6) Síntoma: VFIO se vincula, pero el dispositivo aún aparece usado por drivers del host

Causa raíz: Problemas de orden de binding de drivers; configuración initramfs para VFIO faltante; consola del host usando la GPU.

Solución: Asegura que los módulos VFIO se carguen temprano, pon en blacklist módulos conflictivos, establece la GPU primaria en BIOS como iGPU/otra GPU y revisa lspci -nnk.

7) Síntoma: Pasar un HBA causa errores ZFS esporádicos dentro de la VM de almacenamiento

Causa raíz: El HBA comparte grupo/topología con otros dispositivos; errores/reset de PCIe; o peculiaridades de gestión de energía.

Solución: Coloca el HBA en un puerto raíz limpio; evita ACS override; usa HBAs empresariales con firmware estable; vigila AER y resets de controlador.

Listas de verificación / plan paso a paso

Checklist A: Antes de habilitar ACS override (el pase “no te arrepentirás”)

Confirma que IOMMU está habilitado en /proc/cmdline.
Confirma que el remapeo de interrupciones está habilitado en dmesg (DMAR-IR o remapeo AMD-Vi).
Captura la salida de lspci -t para topología.
Captura el listado de grupos IOMMU desde /sys/kernel/iommu_groups.
Comprueba los puentes relevantes por capacidad ACS usando lspci -vv.
Decide si puedes pasar todo el grupo en vez de un único dispositivo.
Decide si mover ranuras puede arreglar la agrupación sin override.

Checklist B: Si ya habilitaste ACS override (estabilizar o revertir)

Documenta los parámetros exactos del kernel y la versión de Proxmox.
Ejecuta un burn-in de 2–4 horas que coincida con tu carga real (GPU + almacenamiento + red).
Monitoriza journalctl -k por AER, fallos IOMMU y mensajes de reset VFIO.
Si ves AER corregidos en aumento, trátalo primero como problema de hardware/topología.
Prueba mover el dispositivo a otra ranura y repite el burn-in.
Prueba deshabilitar ACS override y vuelve a comprobar si la agrupación es aceptable ahora.
Si no puedes quitar ACS override, establece expectativas: mayor riesgo operativo, más monitorización y un plan de reversión probado.

Checklist C: Prueba de aceptación de passthrough de grado producción

Arranque en frío del host, inicia la VM, ejecuta carga durante 60 minutos.
Detén la VM, inicia la VM de nuevo (prueba de ruta de reset), ejecuta carga otra vez.
Migra VMs no relacionadas fuera y hacia el host si tu entorno hace eso (estresar scheduling).
Captura contadores AER y compara inicio vs fin.
Valida que no haya resets NVMe, no haya flaps de enlace NIC ni soft lockups del host.

Preguntas frecuentes (FAQ)

1) ¿ACS override es “inseguro” o solo “no soportado”?

Es una compensación deliberada. Puede reducir las garantías de aislamiento al crear divisiones de grupos IOMMU que el hardware puede no hacer cumplir.
Eso es una preocupación de seguridad y de integridad, no solo de soporte.

2) Si mi VM funciona, ¿por qué debo preocuparme por el aislamiento “real”?

Porque tu modo de fallo puede ser raro y dependiente de la carga. Los problemas de aislamiento tienden a aparecer como congelaciones intermitentes, resets y acantilados de rendimiento.
Esos son los peores tipos de incidentes para depurar.

3) ¿ACS override siempre causa inestabilidad?

No. En algunas topologías el riesgo práctico es bajo, y el override mainly ayuda al kernel a ser menos conservador. Pero generalmente no sabes en qué caso estás
a menos que inspecciones capacidades ACS y topología.

4) ¿Puedo usar ACS override solo para un dispositivo?

El parámetro del kernel afecta el comportamiento de agrupación en general (según modo). No puedes limitarlo limpiamente a un único endpoint como sí puedes con el binding VFIO.
Trátalo como un cambio de comportamiento a nivel host.

5) ¿Cuál es la mejor alternativa cuando mi GPU comparte grupo con SATA o USB?

Mueve la GPU a otra ranura/puerto raíz, o cambia la placa. Si eso es imposible, considera pasar otra GPU o usar una plataforma diseñada para virtualización.
Si debes, pasa todo el grupo—solo si puedes prescindir de todo lo que hay en él.

6) Estoy usando ZFS en una VM con passthrough de HBA. ¿ACS override es aceptable alguna vez?

Es un multiplicador de riesgo. Si el HBA no está verdaderamente aislado, estás creando una vía donde las rarezas a nivel de bus pueden afectar la fiabilidad del almacenamiento.
Para almacenamiento, soy más estricto: evita ACS override salvo que hayas validado ACS en la ruta ascendente y hayas hecho burn-in bajo IO real.

7) ¿Qué debo vigilar en los logs para detectar problemas temprano?

Mensajes AER, “resetting controller” para NVMe, fallos IOMMU, errores DMAR/AMD-Vi y mensajes VFIO sobre reset de dispositivo o mapeo de BAR.
Si los errores corregidos muestran una tendencia al alza, no los ignores.

8) ¿Hace `iommu=pt` el passthrough menos seguro?

Puede reducir overhead mapeando dispositivos del host de forma más directa, pero no sustituye el aislamiento correcto. Para la mayoría de setups Proxmox es común.
Tu mayor palanca de seguridad sigue siendo la agrupación IOMMU real y el remapeo de interrupciones.

9) ¿Puede una actualización de kernel cambiar los agrupamientos IOMMU?

Sí. Los quirk del kernel PCI y el manejo de ACS pueden cambiar. Por eso deberías capturar agrupamientos “conocidos buenos” y topología, y revalidar tras actualizaciones mayores.

10) ¿Cuándo es ACS override una herramienta temporal razonable?

Cuando estás validando viabilidad, haciendo una prueba de laboratorio o desbloqueando una migración mientras esperas hardware correcto. Temporal significa que ya planificaste la salida:
otra ranura, otra placa o otra arquitectura.

Próximos pasos que puedes hacer esta semana

Si actualmente estás ejecutando ACS override en un host Proxmox que importa, no lo “configures y olvides”. Haz lo siguiente:

Captura evidencia: guarda /proc/cmdline, lspci -t y un listado completo de grupos IOMMU.
Verifica el remapeo: confirma el remapeo de interrupciones en dmesg. Si no está, deja de considerarlo estable.
Audita los bridges: comprueba la capacidad ACS en la ruta ascendente de los dispositivos que pasas.
Burn-in: ejecuta la carga real y vigila mensajes AER/IOMMU/NVMe reset. Si los logs están ruidosos, arregla primero físico/topología.
Intenta quitar el override: mueve ranuras, pasa grupos completos o cambia hardware hasta que los grupos estén limpios sin que el kernel finja.

El objetivo no es la pureza. El objetivo es dominios de fallo predecibles. Si ACS override es lo único entre tú y un sistema funcional,
eso es una señal para rediseñar—no una razón para celebrar.