NVIDIA ha comenzado a posicionar sus CPUs Vera como SoCs independientes para terceros, con la ambición de competir directamente frente a Intel Xeon y AMD EPYC en servidores y centros de datos. Sin embargo, la primera generación de Vera arrastra un problema de compatibilidad a nivel de hardware que afecta al uso de GPUs y aceleradores que no sean NVIDIA.
A diferencia de una CPU de propósito general, capaz de operar con aceleradores de cualquier proveedor, Vera muestra un comportamiento anómalo cuando se combina con GPUs AMD u otros dispositivos PCIe de terceros. El fallo impide una operación fiable del sistema e incluso puede provocar errores durante la instalación del entorno, lo que limita seriamente su adopción fuera del ecosistema cerrado de NVIDIA.
Un problema en los controladores PCIe y la gestión de direcciones
El origen del fallo se encuentra en la forma en que los controladores PCIe de las CPUs Vera generan direcciones de memoria bajo determinadas condiciones. Durante operaciones de PCIe Memory-Mapped I/O (MMIO), el sistema puede emitir direcciones inválidas cuando se realizan escrituras con habilitación parcial de bytes sobre regiones MMIO.
El problema se agrava cuando dichas regiones se asignan utilizando el atributo de memoria MT_NORMAL_NC (Normal Non-Cacheable) de Arm, un modo que emplea un ordenamiento de memoria más relajado. Este comportamiento puede activar el erratum, provocando corrupción de datos, errores de comunicación PCIe e incluso fallos completos del dispositivo, especialmente bajo cargas intensivas de DMA como entrenamiento de IA o simulaciones HPC a gran escala.
Diseñadas para funcionar juntas: Vera y GPUs NVIDIA
Este fallo no se manifiesta cuando las CPUs Vera se combinan con GPUs NVIDIA, ya que ambas plataformas han sido cocreadas teniendo en cuenta el modelo específico de ordenamiento de memoria empleado por Vera. En este escenario, el acceso PCIe y las operaciones DMA se mantienen estables, sin errores de direccionamiento.
El resultado práctico es que Vera funciona correctamente solo dentro del stack completo de NVIDIA, mientras que el uso de aceleradores de terceros queda comprometido, algo especialmente sensible en infraestructuras abiertas de centros de datos.
Workarounds mediante kernels específicos de NVIDIA
Para mitigar el problema, NVIDIA ha implementado soluciones a nivel de kernel Linux dentro de sus NV-Kernels, mantenidos en repositorios independientes para su hardware. Estos kernels incluyen un parche que convierte el atributo MT_NORMAL_NC a Device-nGnRE (non-Gathering, non-Reordering, Early acknowledgement).
Esta conversión fuerza un ordenamiento de memoria más estricto en los mapeos coherentes para DMA, reduciendo los errores de direccionamiento sin eliminar por completo el impacto en rendimiento. En determinados workloads sensibles a E/S, esta solución puede introducir mayor latencia, aunque NVIDIA intenta preservar el rendimiento global del sistema.
Un problema recurrente en plataformas Arm para servidores
NVIDIA no es el único proveedor que se ha encontrado con esta limitación. Ampere Computing ha experimentado problemas similares en sus CPUs Arm Altra, donde los controladores PCIe también generan direcciones inválidas durante escrituras MMIO bajo ciertas cargas.
En el caso de Ampere, la solución pasa igualmente por modificaciones dinámicas en el kernel Linux, lo que apunta a que la raíz del problema podría estar en la gestión de memoria de Arm para dispositivos externos. No obstante, Ampere no ha reportado penalizaciones de rendimiento significativas, lo que sugiere que estos workarounds pueden ser efectivos si se implementan correctamente.
El caso de Vera deja claro que, al menos en su primera iteración, NVIDIA prioriza la integración vertical de su ecosistema, incluso a costa de la compatibilidad abierta tradicional en plataformas de servidor. Un enfoque que puede funcionar en entornos cerrados de IA y HPC, pero que plantea dudas en despliegues heterogéneos donde la interoperabilidad es clave.
Vía: TechPowerUp
