Qué es la virtualización: hipervisores y la extensión del hardware

Una máquina virtual es la mentira más elaborada que cuenta un sistema operativo: convence a otro kernel entero de que posee una CPU, una memoria y unos discos que en realidad no existen, sino que son fragmentos prestados de la máquina real, multiplexados sin que el invitado lo note. Durante treinta años esa mentira fue cara —había que interpretar o reescribir el código del invitado en caliente— hasta que Intel y AMD grabaron en el silicio un modo de privilegio nuevo, por debajo del anillo 0, pensado para el hipervisor. Desde entonces el invitado corre a velocidad casi nativa y el kernel de Linux puede ser, él mismo, el hipervisor. Este nivel diseca esa mentira.

Trap-and-emulate y el pecado original de x86

La receta clásica para virtualizar una CPU se llama trap-and-emulate: dejas correr al invitado directamente sobre el procesador real mientras solo ejecute instrucciones inocuas, y colocas al hipervisor en el anillo 0 mientras el kernel invitado corre desprivilegiado en el anillo 1 o 3. Cuando el invitado intenta una instrucción sensible —tocar la tabla de páginas, deshabilitar interrupciones, leer un registro de control— la CPU dispara una excepción, el hipervisor la atrapa y la emula. El invitado cree que mandó sobre el hardware; en realidad pidió permiso sin saberlo.

En 1974 Popek y Goldberg formalizaron cuándo una arquitectura admite este truco: es virtualizable si el conjunto de sus instrucciones sensibles es un subconjunto de sus instrucciones privilegiadas, es decir, si todo lo que puede alterar el estado global de la máquina atrapa al ejecutarse sin privilegio. x86 violaba el teorema de forma flagrante. Robin e Irvine catalogaron en el año 2000 diecisiete instrucciones problemáticas —SGDT, SIDT, SLDT, SMSW, PUSHF, POPF, entre otras— que son sensibles pero no privilegiadas: en el anillo 3 no atrapan, simplemente se comportan distinto y en silencio, dejando al invitado ver el estado real del anfitrión o fallar sin aviso.

Sin trap-and-emulate limpio hubo dos escuelas. VMware recurrió a la traducción binaria dinámica: reescribía en caliente el flujo de instrucciones del kernel invitado, sustituyendo las diecisiete traidoras por secuencias que sí atrapaban. Xen eligió la paravirtualización: modificar el código fuente del invitado para que no ejecutara jamás una instrucción problemática, sino que pidiera el servicio con una llamada explícita al hipervisor, una hypercall.

Completa frente a paravirtual

De esa bifurcación nacen los dos grandes modelos que aún hoy conviven. En la virtualización completa el invitado no sabe que está virtualizado: se le presenta hardware que cree real —una tarjeta de red Intel e1000, un controlador IDE, una BIOS— y el hipervisor emula cada registro de esos dispositivos. La ventaja es la compatibilidad absoluta: arranca un sistema operativo sin tocar una línea de su código. El coste es la lentitud, porque cada acceso a un registro emulado es una trampa que cruza al hipervisor.

En la paravirtualización el invitado coopera. Sabe que vive dentro de una máquina virtual y, en lugar de fingir que habla con hardware real, usa un protocolo diseñado para la ocasión: virtio para los dispositivos (nivel 53.4), hypercalls para las operaciones privilegiadas. Renuncia a la ignorancia a cambio de velocidad. El Linux moderno mezcla ambos: virtualización completa para la CPU y la memoria, gracias al hardware, y paravirtualización para la E/S, gracias a virtio. Lo mejor de cada mundo.

Para cooperar, el invitado primero ha de saber que está virtualizado, y el hardware se lo confiesa. El bit 31 de ECX en la hoja 1 de CPUID —reservado y siempre a cero en una máquina real— lo enciende el hipervisor, y una hoja dedicada, 0x40000000, devuelve una firma que revela quién hospeda:

/* un invitado descubre si corre virtualizado y bajo qué hipervisor */
static void detectar_hipervisor(void)
{
	u32 eax, sig[3];

	if (!(cpuid_ecx(1) & (1u << 31)))   /* bit "hypervisor present" */
		return;                     /* corremos sobre metal desnudo */

	cpuid(0x40000000, &eax, &sig[0], &sig[1], &sig[2]);
	/* sig deletrea la firma: KVMKVMKVM, Microsoft Hv, XenVMMXenVMM ... */
}

Esa firma es la que consultan los drivers virtio y las rutinas de paravirtualización del kernel para activarse solo cuando hay un anfitrión con quien cooperar. Un invitado sin hipervisor debajo lee ese bit a cero y sigue tratando a la máquina como real.

Hipervisor de tipo 1 y de tipo 2

La segunda gran taxonomía clasifica dónde vive el hipervisor. El tipo 1, o bare metal, corre directamente sobre el hardware desnudo, sin sistema operativo anfitrión debajo: es el primer software que arranca y él mismo planifica las máquinas virtuales. Xen, VMware ESXi y Microsoft Hyper-V son de tipo 1. El tipo 2, o hosted, corre como un programa más sobre un sistema operativo convencional, que sigue gestionando el hardware; el hipervisor es solo otra aplicación con privilegios. VirtualBox y QEMU con su intérprete TCG son de tipo 2.

Linux con KVM desafía la dicotomía. No es un programa sobre el sistema operativo, porque KVM es parte del kernel; pero tampoco es un hipervisor desnudo, porque debajo hay un Linux completo con sus procesos, su planificador y sus drivers. Se le suele llamar tipo 1.5 o híbrido: el kernel de Linux, sin dejar de ser un sistema operativo de propósito general, se transforma en un hipervisor de tipo 1 en cuanto un proceso abre /dev/kvm. La misma máquina que sirve tu navegador puede, en el mismo instante, planificar el vcpu de una máquina virtual como si fuera un hilo más.

La extensión de hardware: VT-x y AMD-V

Lo que rescató a x86 del pecado original fue añadir, hacia 2005, un modo de privilegio enteramente nuevo por debajo del anillo 0. Intel lo llamó VT-x; AMD, AMD-V (o SVM). La idea es idéntica: partir la ejecución en dos mundos ortogonales a los anillos clásicos. El modo root es donde vive el hipervisor; el modo non-root es donde corre el invitado. Y aquí está la magia: dentro del modo non-root el kernel invitado ejecuta en su propio anillo 0, con todos sus privilegios aparentes intactos, pero cualquier instrucción sensible que el hipervisor elija provoca un VM exit que devuelve el control al modo root. Popek y Goldberg quedan satisfechos por hardware: ahora todas las instrucciones sensibles pueden atrapar.

El estado de cada CPU virtual se guarda en una estructura en memoria: el VMCS (Virtual Machine Control Structure) en Intel, el VMCB (Virtual Machine Control Block) en AMD. Contiene los registros del invitado, los del anfitrión a los que volver, y un mapa de bits que decide qué eventos causan VM exit. El hipervisor entra al invitado con VMLAUNCH la primera vez y VMRESUME después —el conjunto de la operación es el VM entry— y lee o escribe el VMCS con VMREAD y VMWRITE. Antes de todo ello, activa la extensión con VMXON. Comprobar si la CPU la ofrece es un solo CPUID:

/* arch/x86: ¿expone esta CPU la virtualización asistida por hardware? */
static bool cpu_tiene_vmx(void)
{
	u32 ecx = cpuid_ecx(1);        /* hoja 1 de CPUID, registro ECX */
	return ecx & (1u << 5);        /* bit 5 = VMX en Intel */
}

static bool cpu_tiene_svm(void)
{
	u32 ecx = cpuid_ecx(0x80000001); /* hoja extendida de AMD */
	return ecx & (1u << 2);          /* bit 2 = SVM en AMD */
}

Desde el espacio de usuario la señal equivalente está en las banderas de la CPU:

# vmx = Intel VT-x, svm = AMD-V; si aparece, el hardware puede virtualizar
grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i virtualization        # Virtualization: VT-x

El ciclo completo de vida de una CPU virtual es este vaivén entre los dos mundos: el hipervisor prepara el VMCS, hace VM entry, el invitado corre a velocidad de metal hasta que tropieza con algo que el hipervisor quiso interceptar, se produce el VM exit, el hipervisor lo atiende y vuelve a entrar.

sequenceDiagram
participant H as Hipervisor en modo root
participant G as Invitado en modo non-root
H->>G: VM entry con VMLAUNCH o VMRESUME
Note over G: el invitado corre casi a velocidad nativa
G->>H: VM exit por instruccion sensible o interrupcion
Note over H: KVM lee el VMCS, emula y decide
H->>G: VM entry de nuevo