Las operaciones VMX permiten controlar las interrupciones externas al guest y al host. Con el control del host de las interrupciones externas, el VMM administra los controladores de interrupciones físicas en la plataforma y las interrupciones generadas a través de ella. El VMM expone dispositivos de control de interrupciones virtuales emuladas por software (como las PIC y APIC) para cada instancia de VM guest. Las arquitecturas IA-32 y Intel 64 usan vectores de 8 bits de los cuales 244 (desde 20H hasta FFH) están disponibles para interrupciones externas. Estos vectores se utilizan para seleccionar la entrada apropiada en la tabla de descriptores de interrupciones (IDT).
Para conocer los requisitos de virtualización de interrupciones, el VMM necesita ser propietario de las interrupciones físicas y de los controladores de interrupciones en la plataforma. Para ello necesita exponer los dispositivos de control de interrupciones virtuales en las máquinas virtuales y restringir el acceso al guest a la plataforma de controladores de interrupciones. En la IA-32 y en Intel 64 existen 3 tipos de mecanismos de control de interrupciones externas: los controladores de interrupciones programables (PIC), los controladores de interrupciones programables avanzados (APIC), y las interrupciones señaladas por mensajes (MSI).
Pueden ocurrir condiciones durante las entradas y salidas de una VM y otras situaciones que den lugar a un error. Todas las salidas de una VM cargan el estado del procesador desde el área de estado del host del VMCS. La consistencia de este estado es comprobada antes de que se cargue; normalmente estas comprobaciones son correctas porque el estado del host es comprobado en la entrada al VM. Sólo es posible el fallo si el software del host es incorrecto o si los datos VMCS en la región VMCS en memoria fueron escritos por el software guest desde la última entrada a la VM. Las salidas VM pueden fracasar por estas razones:
- Hubo un fallo almacenando los MSRs guest.
- Hubo un fallo al cargar un PDPTR.
- El VMCS de control fue corrompido y no se puede completar la salida de la VM.
- Hubo un fallo al cargar los MSRs del host.
- Hubo una comprobación de máquina.
Si se da uno de estos problemas en una salida de la VM, resulta en un aborto del VMX.
Un VMM puede poner un procesador lógico en estado de actividad 'wait-for-SIPI' si soporta cierto sistema operativo del guest usando el algoritmo de start-up multiprocesador. Un guest con acceso directo al APIC local físico y usando el algoritmo, manda una secuencia INIT-SIPI-SIPI IPI para comenzar el procesador de aplicaciones. A fin de trampear las SIPIs, el VMM tiene que encender el procesador lógico objetivo de los SIPIs en el modo 'wait-for-SIPI'
lunes, 19 de enero de 2009
Virtualización de los recursos del sistema
Cuando un VMM es host de múltiples entornos guest (VMs), tiene que monitorizar interacciones potenciales entre los componentes del software usando los mismos recursos del sistema. Estas interacciones pueden requerir la virtualización de los recursos; esto incluye facilidades de depuración, traducción de direcciones, memoria física, y facilidades de actualización del microcódigo.
Las facilidades de depuración en IA-32 y Intel 64 proporcionan instrucciones de breakpoint, condiciones de excepciones, banderas en registros, registros de depuración, registros de control y buffers de almacenamiento para funciones relacionadas con la depuración del sistema y de software dentro de las VMs si el VMM virtualiza correctamente las facilidades de depuración. Las características relevantes para virtualizar las facilidades son:
- El VMM puede programar el bitmap de excepción para asegurar que controla las funciones de depuración.
- El VMM puede utilizar las facilidades de inyección de eventos en entradas VM para inyectar excepciones de depuración o de breakpoint en el guest.
- El bit de control de salida MOV-DR en el campo de control de ejecución de la VM se puede activar por el VMM para provocar una salida VM en un acceso del guest explícito de varios registros de depuración del procesador. Desde que todos los cambios de tarea guest provocan una salida VM, un VMM puede controlar cualquier acceso guest indirecto o la modificación de los registros de depuración durante el cambio de tarea del guest.
- Los accesos software del guest para depurar registros relacionados específicos de cada modelo se pueden trampear por el VMM a través de las características de control de acceso MSR.
- Los registros de depuración como el DR7 pueden ser explícitamente modificados por el guest o modificados implícitamente por el procesador como parte de generar excepciones de depuración.
- El DR7 y el MSR IA32-DEBUGCTL se cargan con valores en el área de estado del guest del VMCS en cada entrada a la VM. Esto permite que el VMM virtualice correctamente los registros de depuración cuando se inyectan excepciones de depuración en el guest.
Las VMMs tienen que controlar la memoria física para asegurar el aislamiento de la VM y para remapear las direcciones físicas del guest en el espacio de direcciones físicas del host para la virtualización. La virtualización de la memoria es requerido para soportar la ejecución del guest en varios modos de operación del procesador. Esto incluye el modo protegido con paginación, el modo protegido sin paginación, el real-mode y cualquier otro modo de ejecución.
Las facilidades de actualización del microcódigo se pueden invocar en varios puntos durante la operación de una plataforma. Típicamente, la BIOS invoca estas facilidades en todos los procesadores durante el proceso de carga de la BIOS. Esto es suficiente para cargar la BIOS y el sistema operativo. Como una actualización del microcódigo puede ser mas reciente que el sistema BIOS, el software del sistema tiene que proporcionar otro mecanismo para invocar las facilidades de actualización.
Estas facilidades se pueden invocar anticipadamente en el VMM o en el proceso de carga del OS en el guest. Esto puede provocar la oportunidad para corregir errores que afecten el proceso de carga pero esta técnica generalmente requiere un reinicio del software.
Las facilidades de actualización también se pueden cargar durante la operación del sistema normal. Esto permite al software activar las actualizaciones del microcódigo al mismo tiempo sin requerir un reinicio del software; sin embargo no permite la corrección de errores que afectan al proceso de carga del procesador. Si la actualización la está ejecutando el guest, el VMM se tiene que asegurar de que el buffer de memoria del guest no causará un fallo de paginación cuando sea accedido. En general, cargar la actualización del microcódigo durante el proceso normal limitará la visibilidad del software del guest de cara a características que pueden mejorar la actualización.
Las facilidades de depuración en IA-32 y Intel 64 proporcionan instrucciones de breakpoint, condiciones de excepciones, banderas en registros, registros de depuración, registros de control y buffers de almacenamiento para funciones relacionadas con la depuración del sistema y de software dentro de las VMs si el VMM virtualiza correctamente las facilidades de depuración. Las características relevantes para virtualizar las facilidades son:
- El VMM puede programar el bitmap de excepción para asegurar que controla las funciones de depuración.
- El VMM puede utilizar las facilidades de inyección de eventos en entradas VM para inyectar excepciones de depuración o de breakpoint en el guest.
- El bit de control de salida MOV-DR en el campo de control de ejecución de la VM se puede activar por el VMM para provocar una salida VM en un acceso del guest explícito de varios registros de depuración del procesador. Desde que todos los cambios de tarea guest provocan una salida VM, un VMM puede controlar cualquier acceso guest indirecto o la modificación de los registros de depuración durante el cambio de tarea del guest.
- Los accesos software del guest para depurar registros relacionados específicos de cada modelo se pueden trampear por el VMM a través de las características de control de acceso MSR.
- Los registros de depuración como el DR7 pueden ser explícitamente modificados por el guest o modificados implícitamente por el procesador como parte de generar excepciones de depuración.
- El DR7 y el MSR IA32-DEBUGCTL se cargan con valores en el área de estado del guest del VMCS en cada entrada a la VM. Esto permite que el VMM virtualice correctamente los registros de depuración cuando se inyectan excepciones de depuración en el guest.
Las VMMs tienen que controlar la memoria física para asegurar el aislamiento de la VM y para remapear las direcciones físicas del guest en el espacio de direcciones físicas del host para la virtualización. La virtualización de la memoria es requerido para soportar la ejecución del guest en varios modos de operación del procesador. Esto incluye el modo protegido con paginación, el modo protegido sin paginación, el real-mode y cualquier otro modo de ejecución.
Las facilidades de actualización del microcódigo se pueden invocar en varios puntos durante la operación de una plataforma. Típicamente, la BIOS invoca estas facilidades en todos los procesadores durante el proceso de carga de la BIOS. Esto es suficiente para cargar la BIOS y el sistema operativo. Como una actualización del microcódigo puede ser mas reciente que el sistema BIOS, el software del sistema tiene que proporcionar otro mecanismo para invocar las facilidades de actualización.
Estas facilidades se pueden invocar anticipadamente en el VMM o en el proceso de carga del OS en el guest. Esto puede provocar la oportunidad para corregir errores que afecten el proceso de carga pero esta técnica generalmente requiere un reinicio del software.
Las facilidades de actualización también se pueden cargar durante la operación del sistema normal. Esto permite al software activar las actualizaciones del microcódigo al mismo tiempo sin requerir un reinicio del software; sin embargo no permite la corrección de errores que afectan al proceso de carga del procesador. Si la actualización la está ejecutando el guest, el VMM se tiene que asegurar de que el buffer de memoria del guest no causará un fallo de paginación cuando sea accedido. En general, cargar la actualización del microcódigo durante el proceso normal limitará la visibilidad del software del guest de cara a características que pueden mejorar la actualización.
domingo, 18 de enero de 2009
Consideraciones en la programación de un monitor de una máquina virtual
El monitor de máquina virtual (VMM) es una clase de software usado para administrar máquinas virtuales (VM). Cada VM se comporta como una máquina física completa y puede cargar sistemas operativos y aplicaciones. El software VMM funciona con el nivel máximo de privilegios y es propietario del hardware del sistema que controle. El VMM controla la creación de una VM, las transferencias de control a una VM, y situaciones de administración que pueden causar transiciones entre las VMs guest y los host VMM. El VMM también permite a las VMs compartir el hardware que controla y proporciona aislamiento entre VMs. El guest software que se ejecuta en una VM no es consciente de las transiciones que pueden ocurrir entre el VM y su host.
Las instrucciones VMX están solamente disponibles en operaciones raíz VMX. Un intento de ejecutar una instrucción VMX en operaciones no raíz VMX causa una salida de la VM. El procesador hace varias comprobaciones mientras se ejecuta cualquier instrucción VMX. Es necesario software para comprobar RFLAGS.CF y RFLAGS.ZF para determinar el éxito o fracaso de las ejecuciones de instrucciones VMX. Después de una instrucción de entrada VM, completa correctamente la comprobación general y se comprueban los controles VMX y el área de estado del host, cualquier error encontrado mientras se carga el estado del guest causa que el procesador cargue el estado desde el área de estado del host del VMCS como si hubiera ocurrido una salida de la VM. Este fallo de comportamiento se diferencia de una salida de la VM en que no se guarda ningún estado del guest en el área de estado de guest.
Los VMMs necesitan asegurarse de que el procesador está en modo protegido con paginación antes de entrar en operación VMX.
Los diseños VMM mas comunes serán VMM simétricos. Este tipo de VMM ejecuta los mismos binarios VMM en todos los procesadores lógicos. Como un sistema operativo simétrico, el VMM simétrico es escrito para asegurar que todos los datos críticos están actualizados por solo un procesador en un tiempo, que a los dispositivos de E/S se accede de forma secuencial, y así en adelante. Sin embargo, también es posible un diseño VMM asimétrico, pero es mucho más fácil depurar un VMM asumiendo simetría de las capacidades hardware. Otra ventaja puede ser que una instalación de software de salida puede continuar funcionando sin tener que actualizar la VMM, cuando la instalación de software se actualiza para funcionar en hardware con mayores capacidades VMX en el procesador.
Antes de activar VMX, un MP-aware tiene que comprobar para asegurarse de que todos los procesadores del sistema son compatibles y soportan las características requeridas. Esto se puede hacer en 3 pasos:
- Comprobar el CPUID en cada procesador lógico para asegurarse de que está soportado VMX y que es compatible con el conjunto de características.
- Comprobar los identificadores de revisión VMCS en cada procesador lógico.
- Comprobar cada campo 'allowed-1' o 'allowed-0' de las MSRs en cada procesador.
Los campos de los registros de control (CR0, CR4) controlan varios aspectos de operación del procesador. El VMM tiene que impedir modificaciones de los guest en los bits de CR0 o CR4 que estén reservados en el tiempo en el que se escribe la VMM.
La VMX proporciona características hardware que se pueden usar para mejorar el rendimiento de la virtualización en un procesador. Las VMMs tienen que estar diseñadas para usar este soporte correctamente. La idea básica de estas optimizaciones es reducir el número de salidas VM mientras se ejecuta un guest VM:
- Acceso de lectura en los registros de control; las lecturas de CR0 o CR4 no provocan salidas de VM
- Acceso de escritura en los registros de control; la mayoría de los diseños VMM requieren la protección de solo ciertos bits de los registros de control. El acceso de escritura a los otros no es problema; esto se consigue con una máscara. La escritura en los bits no protegidos de esos registros no provocarán la salida de la VM.
- Derechos de acceso basados en la protección de la tabla de paginación
- Administración de falta de paginación
Las instrucciones VMX están solamente disponibles en operaciones raíz VMX. Un intento de ejecutar una instrucción VMX en operaciones no raíz VMX causa una salida de la VM. El procesador hace varias comprobaciones mientras se ejecuta cualquier instrucción VMX. Es necesario software para comprobar RFLAGS.CF y RFLAGS.ZF para determinar el éxito o fracaso de las ejecuciones de instrucciones VMX. Después de una instrucción de entrada VM, completa correctamente la comprobación general y se comprueban los controles VMX y el área de estado del host, cualquier error encontrado mientras se carga el estado del guest causa que el procesador cargue el estado desde el área de estado del host del VMCS como si hubiera ocurrido una salida de la VM. Este fallo de comportamiento se diferencia de una salida de la VM en que no se guarda ningún estado del guest en el área de estado de guest.
Los VMMs necesitan asegurarse de que el procesador está en modo protegido con paginación antes de entrar en operación VMX.
Los diseños VMM mas comunes serán VMM simétricos. Este tipo de VMM ejecuta los mismos binarios VMM en todos los procesadores lógicos. Como un sistema operativo simétrico, el VMM simétrico es escrito para asegurar que todos los datos críticos están actualizados por solo un procesador en un tiempo, que a los dispositivos de E/S se accede de forma secuencial, y así en adelante. Sin embargo, también es posible un diseño VMM asimétrico, pero es mucho más fácil depurar un VMM asumiendo simetría de las capacidades hardware. Otra ventaja puede ser que una instalación de software de salida puede continuar funcionando sin tener que actualizar la VMM, cuando la instalación de software se actualiza para funcionar en hardware con mayores capacidades VMX en el procesador.
Antes de activar VMX, un MP-aware tiene que comprobar para asegurarse de que todos los procesadores del sistema son compatibles y soportan las características requeridas. Esto se puede hacer en 3 pasos:
- Comprobar el CPUID en cada procesador lógico para asegurarse de que está soportado VMX y que es compatible con el conjunto de características.
- Comprobar los identificadores de revisión VMCS en cada procesador lógico.
- Comprobar cada campo 'allowed-1' o 'allowed-0' de las MSRs en cada procesador.
Los campos de los registros de control (CR0, CR4) controlan varios aspectos de operación del procesador. El VMM tiene que impedir modificaciones de los guest en los bits de CR0 o CR4 que estén reservados en el tiempo en el que se escribe la VMM.
La VMX proporciona características hardware que se pueden usar para mejorar el rendimiento de la virtualización en un procesador. Las VMMs tienen que estar diseñadas para usar este soporte correctamente. La idea básica de estas optimizaciones es reducir el número de salidas VM mientras se ejecuta un guest VM:
- Acceso de lectura en los registros de control; las lecturas de CR0 o CR4 no provocan salidas de VM
- Acceso de escritura en los registros de control; la mayoría de los diseños VMM requieren la protección de solo ciertos bits de los registros de control. El acceso de escritura a los otros no es problema; esto se consigue con una máscara. La escritura en los bits no protegidos de esos registros no provocarán la salida de la VM.
- Derechos de acceso basados en la protección de la tabla de paginación
- Administración de falta de paginación
Administración del sistema
El modo de administración de sistema (SMM) proporciona un entorno operativo alternativo que se usa para administrar y monitorizar varios sistemas para que usen la energía de modo mas eficiente, para controlar el hardware del sistema, y/o para ejecutar código propietario. Se introdujo con la arquitectura IA-32 en el procesador Intel386 SL, y está disponible en los procesadores Pentium M, Pentium 4, Intel Xeon, en la familia P6, y en los procesadores Pentium y Intel 486.
SMM es un modo de operación de propósito especial proporcionado para administrar funciones grandes del sistema como la administración de energía, o el control del hardware. Se creó con la intención de ser usado sólo por el firmware del sistema, no por las aplicaciones o por el software de propósito general. El beneficio principal de SMM es que ofrece un entorno del procesador completa y fácilmente aislado que opera transparentemente en el sistema operativo y en el software. Cuando se invoca el SMM a través de una interrupción de administración del sistema (SMI), el procesador guarda el estado del procesador, y cambia a un entorno operativo diferente contenido en la RAM de administración del sistema (SMRAM). Mientras en SMM, el procesador ejecuta el código de administración SMI para responder a operaciones como apagar unidades de discos o monitores que no se usan, ejecutar código propietario, etc. Cuando el administrador de SMI se completa, se ejecuta la instrucción de recuperación (RSM). Esto provoca que el procesador restaure el contexto guardado del procesador, vuelva a cambiar al modo protegido o real-mode, y retome la ejecución de la aplicación interrumpida.
La única manera de entrar en SMM es señalando un SMI a través del pin SMI# en el procesador o a través de un mensaje SMI recibido a través del bus APIC. El SMI es una interrupción externa no enmascarable que opera independientemente desde el mecanismo de interrupciones y excepciones del procesador y del APIC local. El SMI tiene preferencia ante una interrupción enmascarada y ante una NMI.
La única opción para salir de la SMM es ejecutando una instrucción RSM. Esto hará que se siga con el transcurso de la ejecución; durante la ejecución del SMM se desactivan todas las interrupciones hardware.
Si el procesador está en estado HALT cuando recibe una SMI, guarda el hecho en la bandera de auto HALT restart en el estado guardado del procesador. La instrucción HLT no se debe ejecutar durante el SMM, excepto si las interrupciones se activaron poniendo a uno la bandera IF en el registro EFLAGS. Si el procesador se para en SMM, el único evento que puede 'despertarlo' de este estado es una interrupción hardware enmascarada o un reset de hardware.
Si la bandera de restart de instrucción E/S en el campo de identificador de revisión de SMM está activa, el mecanismo de restart de instrucción E/S estará presente en el procesador. Este mecanismo permite que una instrucción de E/S interrumpida se pueda reejecutar cuando se regrese del modo SMM.
Lo siguiente se debe tener en cuenta cuando se diseñan sistemas de procesadores múltiples:
- Cualquier procesador en un sistema multiprocesador puede responder a una SMM
- Cada procesador necesita su propio espacio SMRAM. Este espacio puede estar en la memoria del sistema o en una RAM separada.
- Las SMRAMs para diferentes procesadores se pueden solapar en el mismo espacio de memoria. El código y datos estáticos se pueden compartir entre procesadores.
- El administrador SMI necesitará inicializar el SMBASE para cada procesador.
- Los procesadores pueden responder a SMIs locales a través de sus pines SMI# o SMIs recibidos a través de la interfaz APIC. Esta interfaz puede distribuir SMIs a diferentes procesadores.
- Dos o mas procesadores pueden ejecutarse en SMM al mismo tiempo.
- Cuando se opera con procesadores Pentium en modo de procesamiento dual (DP), el pin SMIACT# se controla sólo por el procesador MRM.
En procesadores que soportan estados extendidos del procesador usando XSAVE/XRSTOR, el procesador no guarda todos los estados relacionados XSAVE/XRSTOR en un SMI. Es responsabilidad del código del administrador SMM preservar el estado de la información.
SMM es un modo de operación de propósito especial proporcionado para administrar funciones grandes del sistema como la administración de energía, o el control del hardware. Se creó con la intención de ser usado sólo por el firmware del sistema, no por las aplicaciones o por el software de propósito general. El beneficio principal de SMM es que ofrece un entorno del procesador completa y fácilmente aislado que opera transparentemente en el sistema operativo y en el software. Cuando se invoca el SMM a través de una interrupción de administración del sistema (SMI), el procesador guarda el estado del procesador, y cambia a un entorno operativo diferente contenido en la RAM de administración del sistema (SMRAM). Mientras en SMM, el procesador ejecuta el código de administración SMI para responder a operaciones como apagar unidades de discos o monitores que no se usan, ejecutar código propietario, etc. Cuando el administrador de SMI se completa, se ejecuta la instrucción de recuperación (RSM). Esto provoca que el procesador restaure el contexto guardado del procesador, vuelva a cambiar al modo protegido o real-mode, y retome la ejecución de la aplicación interrumpida.
La única manera de entrar en SMM es señalando un SMI a través del pin SMI# en el procesador o a través de un mensaje SMI recibido a través del bus APIC. El SMI es una interrupción externa no enmascarable que opera independientemente desde el mecanismo de interrupciones y excepciones del procesador y del APIC local. El SMI tiene preferencia ante una interrupción enmascarada y ante una NMI.
La única opción para salir de la SMM es ejecutando una instrucción RSM. Esto hará que se siga con el transcurso de la ejecución; durante la ejecución del SMM se desactivan todas las interrupciones hardware.
Si el procesador está en estado HALT cuando recibe una SMI, guarda el hecho en la bandera de auto HALT restart en el estado guardado del procesador. La instrucción HLT no se debe ejecutar durante el SMM, excepto si las interrupciones se activaron poniendo a uno la bandera IF en el registro EFLAGS. Si el procesador se para en SMM, el único evento que puede 'despertarlo' de este estado es una interrupción hardware enmascarada o un reset de hardware.
Si la bandera de restart de instrucción E/S en el campo de identificador de revisión de SMM está activa, el mecanismo de restart de instrucción E/S estará presente en el procesador. Este mecanismo permite que una instrucción de E/S interrumpida se pueda reejecutar cuando se regrese del modo SMM.
Lo siguiente se debe tener en cuenta cuando se diseñan sistemas de procesadores múltiples:
- Cualquier procesador en un sistema multiprocesador puede responder a una SMM
- Cada procesador necesita su propio espacio SMRAM. Este espacio puede estar en la memoria del sistema o en una RAM separada.
- Las SMRAMs para diferentes procesadores se pueden solapar en el mismo espacio de memoria. El código y datos estáticos se pueden compartir entre procesadores.
- El administrador SMI necesitará inicializar el SMBASE para cada procesador.
- Los procesadores pueden responder a SMIs locales a través de sus pines SMI# o SMIs recibidos a través de la interfaz APIC. Esta interfaz puede distribuir SMIs a diferentes procesadores.
- Dos o mas procesadores pueden ejecutarse en SMM al mismo tiempo.
- Cuando se opera con procesadores Pentium en modo de procesamiento dual (DP), el pin SMIACT# se controla sólo por el procesador MRM.
En procesadores que soportan estados extendidos del procesador usando XSAVE/XRSTOR, el procesador no guarda todos los estados relacionados XSAVE/XRSTOR en un SMI. Es responsabilidad del código del administrador SMM preservar el estado de la información.
sábado, 17 de enero de 2009
Soporte para la traducción de direcciones
La arquitectura para operaciones VMX incluye dos características que soportan traducción de direcciones: los identificadores de procesadores virtuales (VPIDs) y las tablas de paginación extendidas (EPT). Los VPIDs es un mecanismo de administración de traducción de direcciones lineales. Las EPT definen una capa de traducción de direcciones que aumenta la traducción de direcciones lineales.
La arquitectura original de operaciones VMX requería transiciones VMX para alinear los TLBS y las caches de estructuras de paginación. Esto aseguraba que las traducciones cacheadas en el antiguo espacio de direcciones lineales no se usarían después de la traducción. Los identificadores de procesadores virtuales (VPIDs) introducen a las operaciones VMX una facilidad con la cual un procesador lógico puede cachear la información de múltiples espacios de direcciones lineales. Cuando se usan los VPIDs, las transiciones VMX pueden retener información cacheada y el procesador lógico cambia a un espacio de direcciones lineales diferente.
El mecanismo de extensión de la tabla de paginación (EPT) es una característica que se puede usar para soportar la virtualización de la memoria física. Cuando se usa la EPT, ciertas direcciones que normalmente son tratadas como direcciones físicas, se tratan como direcciones físicas guest. Estas se traducen atravesando un conjunto de estructuras de paginación EPT para producir direcciones físicas que se usan para acceder a la memoria. La EPT se activa cuando la activación del EPT en el control de ejecución de la VM está a 1. Traduce las direcciones físicas guest usadas en operaciones no raíz VMX y estas usadas en las entradas de la VM para inyecciones eventuales. Cada estructura de paginación EPT ocupa 4 KBytes y alberga 512 entradas de 8 bytes cada una; especifica el formato de las entradas.
La efectividad del tipo de memoria de un acceso a memoria usando una dirección física guest (un acceso traducido usando EPT) es el tipo de memoria que se usa para acceder a ella. La efectividad del tipo de memoria está basada en el valor del bit 30 (CD, cache disable) en el registro CR0; la última entrada en la estructura de paginación EPT usada para traducir la dirección física guest; y el tipo de memoria PAT (es el tipo de memoria seleccionada desde el MSR IA32_PAT).
Los procesadores que soportan IA-32 y Intel 64 pueden acelerar el proceso de traducción de las direcciones cacheando los datos del procesador desde las estructuras en memoria que controlan este proceso. Las características VPID y EPT de la arquitectura para operaciones VMX aumentan el rendimiento, y controlan las formas mediante las cuales un procesador lógico puede crear y usar información cacheada desde estructuras de paginación.
La arquitectura original de operaciones VMX requería transiciones VMX para alinear los TLBS y las caches de estructuras de paginación. Esto aseguraba que las traducciones cacheadas en el antiguo espacio de direcciones lineales no se usarían después de la traducción. Los identificadores de procesadores virtuales (VPIDs) introducen a las operaciones VMX una facilidad con la cual un procesador lógico puede cachear la información de múltiples espacios de direcciones lineales. Cuando se usan los VPIDs, las transiciones VMX pueden retener información cacheada y el procesador lógico cambia a un espacio de direcciones lineales diferente.
El mecanismo de extensión de la tabla de paginación (EPT) es una característica que se puede usar para soportar la virtualización de la memoria física. Cuando se usa la EPT, ciertas direcciones que normalmente son tratadas como direcciones físicas, se tratan como direcciones físicas guest. Estas se traducen atravesando un conjunto de estructuras de paginación EPT para producir direcciones físicas que se usan para acceder a la memoria. La EPT se activa cuando la activación del EPT en el control de ejecución de la VM está a 1. Traduce las direcciones físicas guest usadas en operaciones no raíz VMX y estas usadas en las entradas de la VM para inyecciones eventuales. Cada estructura de paginación EPT ocupa 4 KBytes y alberga 512 entradas de 8 bytes cada una; especifica el formato de las entradas.
La efectividad del tipo de memoria de un acceso a memoria usando una dirección física guest (un acceso traducido usando EPT) es el tipo de memoria que se usa para acceder a ella. La efectividad del tipo de memoria está basada en el valor del bit 30 (CD, cache disable) en el registro CR0; la última entrada en la estructura de paginación EPT usada para traducir la dirección física guest; y el tipo de memoria PAT (es el tipo de memoria seleccionada desde el MSR IA32_PAT).
Los procesadores que soportan IA-32 y Intel 64 pueden acelerar el proceso de traducción de las direcciones cacheando los datos del procesador desde las estructuras en memoria que controlan este proceso. Las características VPID y EPT de la arquitectura para operaciones VMX aumentan el rendimiento, y controlan las formas mediante las cuales un procesador lógico puede crear y usar información cacheada desde estructuras de paginación.
viernes, 16 de enero de 2009
Estructuras de control de la máquina virtual
La estructura de datos de control de la máquina virtual (VMCS) se define en las operaciones VMX. Una VMCS administra transiciones dentro y fuera de operaciones no raíz VMX. Esta estructura está manipulada por las nuevas instrucciones VMCLEAR, VMPTRLD, VMREAD, y VMWRITE. Una VMM puede usar un VMCS diferente por cada máquina virtual que soporte. Para una máquina virtual con varios procesadores lógicos (procesadores virtuales), el VMM puede usar un VMCS diferente para cada procesador virtual (en memoria, cada procesador lógico está asociado a su VMCS en la región VMCS). El software activa un VMCS ejecutando VMPTRLD con la dirección del VMCS, y lo desactiva ejecutando VMCLEAR con la dirección del VMCS. El procesador optimizará la operación VMX manteniendo el estado de una VMCS activa en memoria, en el procesador, o en ambos. No se debe activar varias VMCS en un único procesador lógico.
Los datos VMCS se organizan en seis grupos lógicos:
- Área guest-state: el estado del procesador se guarda en este área en las salidas de la VM y se carga desde aquí en las entradas.
- Área host-state: el estado del procesador se carga desde aquí en las salidas VM.
- Campos de control de ejecución VM: Estos campos controlan el comportamiento del procesador en operación no raíz VMX. Esto determina en parte la causa de las salidas VM.
- Campos de control de salidas VM: Campos que controlan la salida de la VM.
- Campos de control de entradas VM
- Campos de información de salidas VM: Estos campos reciben información de las salidas VM y describen su causa y su naturaleza. Son de sólo lectura.
Estos son los campos de control que gobiernan la ejecución VM:
- Controles de ejecución de la VM basados en pines (NMIs virtuales, salida de interrupciones externas...)
- Controles de ejecución de la VM basados en el procesador (salidas de almacenamiento o de carga CR3, salidas RDPMC...)
- Excepción Bitmap; es un campo de 32 bits que contiene un bit por cada excepción. Si la excepción causa una salida de la VM, el bit correspondiente se pone a uno.
- Direcciones Bitmap de E/S: Los campos de control de ejecución de la VM incluyen direcciones físicas de 64 bits de bitmaps de E/S A y B (que ocupa cada uno 4 KBytes)
- Offset contador de time-stamp: Este campo controla las ejecuciones de las instrucciones RDTSC y RDTSCP.
- Máscaras guest/host y read shadows de CR0 y CR4: Controlan las ejecuciones de instrucciones que acceden a esos registros. Son de 64 bits en procesadores Intel 64 y de 32 bits en procesadores IA-32.
- Controles CR3-target: dependiendo de este campo se producirá o no una salida VM.
- Controles para accesos APIC
- Dirección MSR-bitmap: En los procesadores que soportan el 1-setting de los controles de ejecución de la VM 'use MSR bitmaps', los campos de control incluyen una dirección física de 64 bits un 4 bitmaps MSR contiguos, cada cual ocupa 1 KByte. Este campo no existe en procesadores que no soportan el 1-setting de ese control.
- Puntero de ejecución VMCS: Es un puntero de 64 bits usado en el tratamiento dual-monitor de interrupciones de administración de sistema (SMIs) y en el modo de administración del sistema (SMM).
- Puntero a la tabla de paginación extendida (EPTP): Contiene la dirección de la base de la tabla EPML4, y también la información de configuración EPT.
- Identificador del procesador virtual (VPID): Es un campo de 16 bits y existe sólo en procesadores que soportan 1-setting en el control de ejecución de 'enable VPID'.
Para asegurar un comportamiento bueno del procesador, el software debe seguir unas ciertas pautas a la hora de acceder a un VMCS activo. El software nunca debe acceder o modificar los datos VMCS de una VMCS activa usando operaciones de memoria ordinarias, en parte porque el formato usado para guardar los datos VMCS es específico de cada implementación y no está definido en la arquitectura. Estos problemas se pueden solucionar borrando todos los mapeos de direcciones lineales a una región VMCS antes de ejecutar una VMPTRLD para esa región y no remapeándolo hasta después de ejecutar VMCLEAR. Para acceder a los campos se deben utilizar las instrucciones VMREAD y VMWRITE.
Un procesador puede usar porciones de datos VMCS de una región para mantener la implementación específica de la información sobre la VMCS. Cuando el software primero localiza una región de memoria para usar como región VMCS, los datos en esa región se pueden interpretar de manera específica. Además de otras funciones, la instrucción VMCLEAR inicia cualquier información de implementación específica en una región VMCS referenciada por su operando. Antes de activar un VMCS con VMPTRLD, el software siempre debe ejecutar un VMCLEAR sobre la región VMCS. Un procesador lógico usa la región VMCS para mantener el estado de carga de las correspondientes VMCS. Este estado puede ser borrado o cargado (con VMCLEAR se borra, y con VMLAUNCH se carga). Cuando se carga con VMLAUNCH se requiere también una instrucción VMRESUME. No hay mas formas que ésta para modificar el estado de carga de una VMCS (no se puede modificar con VMWRITE) y no hay forma directa de leerlo (no se puede leer con VMREAD). Si se el software no aconsejado puede dar lugar valores de estado no definidos. El uso del software tiene tres limitaciones:
- VMCLEAR se tiene que ejecutar para un VMCS antes de se use para la entrada VM.
- VMLAUNCH se tiene que usar para la primera entrada a la VM usando un VMCS después de que se haya ejecutado el VMCLEAR.
- VMRESUME se debe usar para cualquier subsecuencia de entrada a la VM usando un VMCS.
Como cabe esperar, en general, VMRESUME tendrá mas latencia que VMLAUNCH.
Los datos VMCS se organizan en seis grupos lógicos:
- Área guest-state: el estado del procesador se guarda en este área en las salidas de la VM y se carga desde aquí en las entradas.
- Área host-state: el estado del procesador se carga desde aquí en las salidas VM.
- Campos de control de ejecución VM: Estos campos controlan el comportamiento del procesador en operación no raíz VMX. Esto determina en parte la causa de las salidas VM.
- Campos de control de salidas VM: Campos que controlan la salida de la VM.
- Campos de control de entradas VM
- Campos de información de salidas VM: Estos campos reciben información de las salidas VM y describen su causa y su naturaleza. Son de sólo lectura.
Estos son los campos de control que gobiernan la ejecución VM:
- Controles de ejecución de la VM basados en pines (NMIs virtuales, salida de interrupciones externas...)
- Controles de ejecución de la VM basados en el procesador (salidas de almacenamiento o de carga CR3, salidas RDPMC...)
- Excepción Bitmap; es un campo de 32 bits que contiene un bit por cada excepción. Si la excepción causa una salida de la VM, el bit correspondiente se pone a uno.
- Direcciones Bitmap de E/S: Los campos de control de ejecución de la VM incluyen direcciones físicas de 64 bits de bitmaps de E/S A y B (que ocupa cada uno 4 KBytes)
- Offset contador de time-stamp: Este campo controla las ejecuciones de las instrucciones RDTSC y RDTSCP.
- Máscaras guest/host y read shadows de CR0 y CR4: Controlan las ejecuciones de instrucciones que acceden a esos registros. Son de 64 bits en procesadores Intel 64 y de 32 bits en procesadores IA-32.
- Controles CR3-target: dependiendo de este campo se producirá o no una salida VM.
- Controles para accesos APIC
- Dirección MSR-bitmap: En los procesadores que soportan el 1-setting de los controles de ejecución de la VM 'use MSR bitmaps', los campos de control incluyen una dirección física de 64 bits un 4 bitmaps MSR contiguos, cada cual ocupa 1 KByte. Este campo no existe en procesadores que no soportan el 1-setting de ese control.
- Puntero de ejecución VMCS: Es un puntero de 64 bits usado en el tratamiento dual-monitor de interrupciones de administración de sistema (SMIs) y en el modo de administración del sistema (SMM).
- Puntero a la tabla de paginación extendida (EPTP): Contiene la dirección de la base de la tabla EPML4, y también la información de configuración EPT.
- Identificador del procesador virtual (VPID): Es un campo de 16 bits y existe sólo en procesadores que soportan 1-setting en el control de ejecución de 'enable VPID'.
Para asegurar un comportamiento bueno del procesador, el software debe seguir unas ciertas pautas a la hora de acceder a un VMCS activo. El software nunca debe acceder o modificar los datos VMCS de una VMCS activa usando operaciones de memoria ordinarias, en parte porque el formato usado para guardar los datos VMCS es específico de cada implementación y no está definido en la arquitectura. Estos problemas se pueden solucionar borrando todos los mapeos de direcciones lineales a una región VMCS antes de ejecutar una VMPTRLD para esa región y no remapeándolo hasta después de ejecutar VMCLEAR. Para acceder a los campos se deben utilizar las instrucciones VMREAD y VMWRITE.
Un procesador puede usar porciones de datos VMCS de una región para mantener la implementación específica de la información sobre la VMCS. Cuando el software primero localiza una región de memoria para usar como región VMCS, los datos en esa región se pueden interpretar de manera específica. Además de otras funciones, la instrucción VMCLEAR inicia cualquier información de implementación específica en una región VMCS referenciada por su operando. Antes de activar un VMCS con VMPTRLD, el software siempre debe ejecutar un VMCLEAR sobre la región VMCS. Un procesador lógico usa la región VMCS para mantener el estado de carga de las correspondientes VMCS. Este estado puede ser borrado o cargado (con VMCLEAR se borra, y con VMLAUNCH se carga). Cuando se carga con VMLAUNCH se requiere también una instrucción VMRESUME. No hay mas formas que ésta para modificar el estado de carga de una VMCS (no se puede modificar con VMWRITE) y no hay forma directa de leerlo (no se puede leer con VMREAD). Si se el software no aconsejado puede dar lugar valores de estado no definidos. El uso del software tiene tres limitaciones:
- VMCLEAR se tiene que ejecutar para un VMCS antes de se use para la entrada VM.
- VMLAUNCH se tiene que usar para la primera entrada a la VM usando un VMCS después de que se haya ejecutado el VMCLEAR.
- VMRESUME se debe usar para cualquier subsecuencia de entrada a la VM usando un VMCS.
Como cabe esperar, en general, VMRESUME tendrá mas latencia que VMLAUNCH.
jueves, 15 de enero de 2009
Introducción a las extensiones de la máquina virtual
Las extensiones de la máquina virtual definen un soporte de niveles del procesador para las máquinas virtuales en procesadores IA-32. Están soportadas dos clases principales de software: Monitores de máquinas virtuales (VMM), que actúan cono un host y tiene pleno control sobre el procesador/procesadores y otras plataformas hardware; y software guest (cliente, invitado), cada máquina virtual (VM) es un entorno de software guest que soporta una pila que consta de sistema operativo y aplicaciones software. Opera independientemente de otras máquinas virtuales y usa en el mismo interfaz al procesador/procesadores, memoria, almacenamiento, gráficos, y E/S proporcionada por la plataforma física. La pila software actúa como si funcionara en una plataforma real. El software ejecutado en una máquina virtual debe operar con privilegios reducidos para que el VMM pueda retener el control de las fuentes.
El procesador que soporta virtualización proporciona una forma de operación llamada operación VMX. Hay 2 tipos de operación VMX: operaciones raíz VMX y operaciones no raíz VMX. En general, una VMM funcionará en operación raíz VMX y el software guest funcionará en operación no raíz VMX. Las transiciones entre VMX raíz y no raíz se llaman transiciones VMX. Hay 2 tipos de transiciones; hacia raíz (salidas VMX), o hacia no raíz (entradas VMX). El comportamiento del procesador en operaciones raíz VMX es casi total; en operaciones no raíz VMX es restringido y modificado para facilitar la virtualización.
Las operaciones no raíz VMX y las transiciones VMX son controladas por una estructura de datos llamada estructura de control de máquina virtual (VMCS). El acceso a esto está administrado a través de un componente de estado del procesador llamado puntero VMCS (uno por procesador lógico). El valor del puntero es la dirección de 64 bits del VMCS; en este puntero se lee y se escribe con las instrucciones VMREAD, VMWRITE y VMCLEAR.
Antes de que el software del sistema entre en operaciones VMX debe descubrir su presencia y si el procesador lo soporta. Esto se puede determinar usando la instrucción CPUID, y si está soportado se debe activar en el registro CR4.
Hay algunas restricciones en las operaciones VMX:
- El procesador puede fijar ciertos bits en CR0 y CR4 a valores específicos y no soportar otros valores.
- VMXON cae si un procesador lógico está en modo A20M. Una vez el procesador está en operación VMX, las interrupciones A20M se bloquean; por eso es imposible estar en modo A20M en operación VMX.
- La señal INIT se bloquea cada vez que un procesador lógico está en operación raíz VMX (si está en operación no raíz VMX no pasa nada); por lo tanto, los INITs causan salidas de la VM.
El procesador que soporta virtualización proporciona una forma de operación llamada operación VMX. Hay 2 tipos de operación VMX: operaciones raíz VMX y operaciones no raíz VMX. En general, una VMM funcionará en operación raíz VMX y el software guest funcionará en operación no raíz VMX. Las transiciones entre VMX raíz y no raíz se llaman transiciones VMX. Hay 2 tipos de transiciones; hacia raíz (salidas VMX), o hacia no raíz (entradas VMX). El comportamiento del procesador en operaciones raíz VMX es casi total; en operaciones no raíz VMX es restringido y modificado para facilitar la virtualización.
Las operaciones no raíz VMX y las transiciones VMX son controladas por una estructura de datos llamada estructura de control de máquina virtual (VMCS). El acceso a esto está administrado a través de un componente de estado del procesador llamado puntero VMCS (uno por procesador lógico). El valor del puntero es la dirección de 64 bits del VMCS; en este puntero se lee y se escribe con las instrucciones VMREAD, VMWRITE y VMCLEAR.
Antes de que el software del sistema entre en operaciones VMX debe descubrir su presencia y si el procesador lo soporta. Esto se puede determinar usando la instrucción CPUID, y si está soportado se debe activar en el registro CR4.
Hay algunas restricciones en las operaciones VMX:
- El procesador puede fijar ciertos bits en CR0 y CR4 a valores específicos y no soportar otros valores.
- VMXON cae si un procesador lógico está en modo A20M. Una vez el procesador está en operación VMX, las interrupciones A20M se bloquean; por eso es imposible estar en modo A20M en operación VMX.
- La señal INIT se bloquea cada vez que un procesador lógico está en operación raíz VMX (si está en operación no raíz VMX no pasa nada); por lo tanto, los INITs causan salidas de la VM.
Suscribirse a:
Entradas (Atom)