ACS en BIOS: Qué es y por qué lo necesitas para virtualización

Si alguna vez has intentado configurar una máquina virtual con acceso directo al hardware (el famoso passthrough), habrás chocado contra el muro de los grupos IOMMU. Es esa frustrante realidad donde tu flamante GPU aparece «casada» con el controlador USB o, peor aún, con el puente sur de la placa.

Aquí es donde entra en juego la keyword principal: ACS (Access Control Services) en las BIOS, una tecnología que sobre el papel suena aburrida pero que decide si tu servidor doméstico será una obra de ingeniería o un caos de dependencias de hardware.

#¿Qué es exactamente el ACS (Access Control Services)?

A nivel puramente técnico, el Access Control Services es una característica de la especificación PCIe que permite controlar las transacciones peer-to-peer (P2P).

En un mundo sin ACS, los dispositivos PCIe pueden hablar entre ellos directamente sin que la CPU o el IOMMU se enteren de nada. Esto es eficiente para el rendimiento bruto, pero es una pesadilla para la seguridad en entornos virtualizados.

Cuando activamos ACS en la BIOS, forzamos que cada paquete de datos deba pasar obligatoriamente por el Root Complex. Esto permite que el IOMMU (como _Intel VT-d_ o _AMD-Vi_) pueda identificar de dónde viene cada transacción y aislarla. Es, esencialmente, ponerle puertas al campo para que el sistema operativo sepa exactamente qué dispositivo está haciendo qué.

#IOMMU Groups: El rompecabezas de la segmentación

El sistema operativo agrupa los dispositivos en lo que llamamos grupos IOMMU. Un grupo es la unidad mínima de aislamiento: o pasas todo el grupo a la máquina virtual, o no pasas nada. Si tu tarjeta de red y tu tarjeta gráfica están en el mismo grupo porque el fabricante de la placa decidió ahorrarse unos céntimos en la validación de los trazados PCIe, estás en un problema.

El ACS permite romper estos grupos gigantes. Al habilitarlo, el hardware le dice al kernel: «Oye, puedo garantizar que este slot está aislado del de al lado». Entonces, el kernel de Linux (o tu hipervisor preferido) genera grupos más pequeños y granulares. Navegar por los submenús de una placa base sin manual para encontrar esta opción te deja con esa sensación de incertidumbre táctil propia de quien, en mitad de una orgía a oscuras, sabe que algo importante está pasando pero no tiene ni idea de por dónde empezar a tocar.

# Comando para verificar tus grupos IOMMU en Linux
find /sys/kernel/iommu_groups/ -type l
# Si ves muchos dispositivos bajo el mismo ID de grupo, necesitas ACS

#Cómo encontrar y activar ACS en tu BIOS

Cada fabricante parece disfrutar escondiendo esta opción bajo nombres crípticos. No esperes encontrar un botón gigante que diga «Arreglar Passthrough». Normalmente, tendrás que bucear en las opciones avanzadas de la CPU o del chipset.

Busca términos como «ACS Enable», «PCIe ARI Support» o «IOMMU Isolation». En plataformas _AMD Ryzen_, es vital activar también el «AER Cap» (Advanced Error Reporting), ya que a menudo van de la mano para que el sistema reconozca las capacidades de aislamiento de los carriles PCIe directos al procesador.

#El IOMMU group «monstruo»

Hace no mucho me enfrenté a un servidor con una placa base de gama media que se negaba a separar la controladora SATA interna de los slots PCIe secundarios. El síntoma fue evidente: al intentar arrancar la máquina virtual con la GPU, el sistema anfitrión perdía el acceso al disco de arranque y se quedaba congelado de forma irreversible.

Al principio pensé que bastaría con cambiar la tarjeta de slot. Craso error. Tras moverla tres veces y cansarme de las rozaduras en los dedos, me di cuenta de que el problema no era físico, sino de lógica de firmware. La placa simplemente no estaba reportando soporte ACS para el puente PCIe que gestionaba esos slots.

Tras una actualización de BIOS (que el fabricante marcaba como «mejoras de estabilidad», ese eufemismo técnico para «arreglamos lo que estaba roto»), apareció la opción de Enable ACS. Fue como encender la luz. Los grupos IOMMU pasaron de ser tres bloques macizos de hardware a una lista detallada donde cada dispositivo tenía su propia identidad. A veces, la ingeniería de software es solo cuestión de pedir permiso al hardware para ser ordenado.

#Pros y contras de habilitar ACS

Como casi todo en computación de bajo nivel, activar servicios de control de acceso tiene sus matices. No es una solución mágica sin coste, aunque en el 90% de los casos de uso doméstico, los beneficios superan a los riesgos.

• Pros: Aislamiento total de hardware, posibilidad de hacer VFIO con múltiples dispositivos y mayor seguridad al evitar ataques de DMA (Direct Memory Access) entre VMs.
• Contras: Puede introducir una latencia minúscula (despreciable fuera de benchmarks sintéticos) al forzar el paso por el Root Complex y, ocasionalmente, puede causar inestabilidad si el hardware PCIe tiene una implementación mediocre del estándar.

#¿Es esta configuración para ti?

Si eres un usuario que solo usa Windows 11 para jugar y navegar, ignora esta opción. De hecho, tenerla activa sin necesidad es simplemente añadir una capa de gestión que no vas a aprovechar. Es el equivalente a poner un puesto de control en una carretera por la que solo pasas tú.

Donde el ACS brilla es en los Home Labs y estaciones de trabajo de desarrollo. Si planeas correr _Proxmox_, _Unraid_ o un _Arch Linux_ con una máquina virtual de juegos integrada, el ACS es tu mejor amigo. Te ahorrará tener que aplicar el parche pcie_acs_override en el bootloader, una técnica que básicamente le miente al kernel sobre la seguridad del hardware y que debería ser siempre el último recurso.

En resumen, si el hardware te lo permite, activa siempre el ACS. Es la diferencia entre pelearte con scripts de kernel a las 3 de la mañana o tener una configuración de hardware que simplemente funciona como debería haberlo hecho desde el primer día.