Problema

En entornos Windows 11 con procesadores AMD, es frecuente encontrarse con la imposibilidad de iniciar Hyper‑V o una distribución WSL2. Los síntomas típicos son:

  • HCS_E_HYPERV_NOT_INSTALLED o “virtualization is not enabled”.
  • systeminfo muestra Virtualization Enabled In Firmware: Yes, pero coreinfo indica que los flags NX, SVM y NP están desactivados.
  • Los logs de Hyper‑V reportan el error ID 44: Hypervisor launch failed; Either VMX not present or not enabled in BIOS.
  • La BIOS tiene la opción SVM marcada como Enabled y, sin embargo, el hipervisor no se detecta.

Este patrón aparece en mini‑PCs, notebooks OEM y placas madre de fabricantes poco documentados, donde el firmware oculta deliberadamente o por error los bits de CPUID que exponen las capacidades de ejecución sin‑ejecución (NX), virtualización asistida (SVM/AMD‑V) y tablas de páginas anidadas (NPT/SLAT). El resultado es que Windows cree que la virtualización está disponible, pero el hipervisor no puede usarla.

Causa

1. Firmware que oculta características por defecto

Algunas versiones de AMI BIOS/UEFI incluyen una opción oculta (a veces llamada Secure Virtual Machine, NX Disable, o SVM Hidden) que desactiva los bits de CPUID aunque la opción visible de SVM esté activada. Esto se hace para cumplir con políticas de seguridad de ciertos OEM o para evitar conflictos con máquinas virtuales de terceros.

2. AGESA desactualizado o parcheado incorrectamente

El AMD Generic Encapsulated Software Architecture (AGESA) es el módulo que inicializa la CPU. Si la versión de AGESA es antigua o está modificada, puede no exponer correctamente los flags de NX, SVM y NPT, aunque la CPU los soporte nativamente.

3. Configuración de arranque de Windows que desactiva el hipervisor

El parámetro hypervisorlaunchtype en BCD puede estar establecido en Off o Auto con una política de grupo que anula la detección de SVM. En sistemas donde la BIOS reporta “VirtualizationFirmwareEnabled: True”, Windows todavía necesita que el hipervisor sea lanzado explícitamente.

4. Firmware de OEM sin documentación pública

Placas madre OEM (por ejemplo, la SHS AM4SFF23) a menudo utilizan una versión personalizada de AMI que no incluye herramientas de actualización accesibles. Sin la hoja de datos del chipset, es difícil saber si existen opciones ocultas o si el firmware está firmado para impedir modificaciones.

Solución

El objetivo es forzar al firmware a exponer los bits de CPUID y asegurarse de que Windows los reconozca. La solución se divide en tres fases: diagnóstico, ajuste del firmware y configuración de Windows.

1. Diagnóstico preciso

  1. Ejecutar coreinfo -v y guardar la salida. Verifica los flags NX, SVM y NP.
  2. Usar wmic cpu get DataWidth,Manufacturer,Name,ProcessorId,VirtualizationFirmwareEnabled para confirmar que el firmware declara virtualización.
  3. Consultar el registro de eventos de Hyper‑V (Microsoft-Windows-Hyper-V-VMMS/Operational) y buscar el ID 44.
  4. Si la BIOS tiene una versión disponible en el sitio del OEM, comparar el número de versión con la fecha de publicación.

2. Ajuste del firmware

a) Acceder a opciones ocultas

Muchas BIOS AMI permiten revelar opciones ocultas mediante la tecla Ctrl + F1 o Ctrl + F2 en la pantalla de configuración avanzada. Los pasos típicos son:

  1. Reiniciar y entrar al BIOS (tecla Del o F2).
  2. Pulsar Ctrl + F1 para activar el modo Advanced. Aparecerá un mensaje de “Advanced BIOS Features Enabled”.
  3. Navegar a Advanced → CPU Configuration y buscar entradas como SVM Mode, NX (No‑Execute) Feature, AMD‑V, SLAT/NPT.
  4. Cambiar cualquier opción marcada como Disabled a Enabled.
  5. Guardar y salir.

Si la combinación no funciona, probar Ctrl + F2 o consultar el manual del chipset (por ejemplo, AMD 600‑Series) para identificar la nomenclatura exacta.

b) Actualizar AGESA / BIOS

  1. Contactar al fabricante del OEM (en el caso del ejemplo, SHS) solicitando una versión de BIOS que incluya AGESA 1.2.0 o superior.
  2. Si el OEM no responde, buscar una BIOS genérica de la placa madre (por ejemplo, una versión de una placa madre ASRock o Gigabyte basada en el mismo chipset) y crear un modded BIOS que solo cambie el módulo AGESA. Este proceso es avanzado y requiere una herramienta como AMIBCP y una unidad USB de arranque con AFU.
  3. Flashar la BIOS siguiendo las instrucciones del fabricante y verificar la integridad con md5sum o sha256sum.

3. Configuración de Windows

Una vez que el firmware expone los flags, habilitar el hipervisor:

bcdedit /set hypervisorlaunchtype Auto
bcdedit /set nx OptIn
bcdedit /set vmx on

Reiniciar el equipo. Después del arranque, ejecutar systeminfo y confirmar:

  • Hyper-V Requirements: VM Monitor Mode Extensions: Yes
  • HypervisorPresent: True

Si coreinfo sigue mostrando los flags desactivados, volver a la BIOS y revisar que la opción SVM no sea sobrescrita por una política de seguridad (por ejemplo, Secure Boot con Platform Secure Boot activado puede forzar el ocultamiento).

Cuándo aplicar esta solución

Aplicable cuando:

  • systeminfo indica que la virtualización está habilitada, pero coreinfo muestra NX, SVM o NP como “No”.
  • Los logs de Hyper‑V reportan error 44 al iniciar.
  • El hardware es AMD (Ryzen 5/7/9, EPYC) y la BIOS es de un OEM sin documentación pública.

No aplicable si:

  • El procesador es Intel y los flags faltan; el problema suele ser diferente (VT‑x/VT‑d).
  • La BIOS ya muestra explícitamente que SVM está desactivado y no hay opción para habilitarlo. En ese caso, la placa no soporta virtualización.

Código

# 1. Verificar flags de CPUID
coreinfo -v | findstr /i "NX SVM NP"

# 2. Comprobar que Windows reconoce la virtualización
systeminfo | findstr /i "Hyper-V Requirements"

# 3. Forzar el arranque del hipervisor
bcdedit /set hypervisorlaunchtype Auto
bcdedit /set nx OptIn
bcdedit /set vmx on

# 4. Reiniciar y validar
shutdown /r /t 0

Verificación

  1. Después del reinicio, ejecutar coreinfo -v nuevamente. Los flags NX, SVM y NP deben aparecer como Yes.
  2. En PowerShell, lanzar Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V y comprobar que el estado sea Enabled.
  3. Instalar una distribución WSL2 (wsl --install -d Ubuntu) y verificar que arranca sin errores.
  4. En el Visor de eventos, confirmar que ya no aparecen entradas con ID 44 bajo Hyper‑V‑VMMS.

Notas adicionales

  • Algunas BIOS OEM ocultan la opción SVM cuando Secure Boot está activo. Desactivar temporalmente Secure Boot puede revelar la configuración.
  • En laptops con procesadores móviles, el firmware a veces desactiva NPT para ahorrar energía. Si la carga de trabajo no requiere SLAT, Windows puede seguir funcionando, pero WSL2 lo necesita.
  • Si después de actualizar la BIOS el problema persiste, usar una herramienta como CPU-Z para leer directamente los bits de CPUID y comparar con la tabla de AMD.
  • Mantener una copia de la BIOS original antes de cualquier flash es crítico; la mayoría de los fabricantes permiten restaurarla mediante un recovery USB en caso de fallo.

Con estos pasos, la mayoría de los sistemas que presentan “NX / SVM / NPT ocultos” pueden volver a exponer sus capacidades de virtualización y permitir que Hyper‑V y WSL2 funcionen sin obstáculos.