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.
Monitoreo de rendimiento y depuración
Las arquitecturas IA-32 y Intel 64 proporcionan facilidades de depuración para usarlos en código de depuración y monitorización de rendimiento. Estas facilidades son importantes para depurar aplicaciones, software del sistema, y sistemas operativos multitarea. Al soporte de depuración se accede usando registros de depuración (DB0 a DB7) y registros específicos de cada modelo (MSRs). Los primeros contienen las direcciones de memoria y localizaciones de E/S llamadas breakpoints (son localizaciones user-selected en un programa, un área de almacenamiento de datos en memoria, o puertos de E/S específicos).
Estas son las facilidades de depuración y de monitorización de rendimiento:
- Excepción de depuración (#DB); transfiere el control del programa a un procedimiento de depuración cuando ocurre un evento de depuración.
- Excepción Breakpoint (#BP)
- Registro de direcciones breakpoint (DR0 a DR3); especifican las direcciones de 4 breakpoints.
- Registro de estado de depuración (DR6); Devuelve las condiciones efectivas cuando se generó la excepción de depuración o de breakpoint.
- Registro de control de depuración (DR7); Especifica la forma de acceso a memoria o de E/S que causó que se generara el breakpoint.
- bandera T (trap), TSS; genera una excepción de depuración cuando se intenta cambiar de tarea con la bandera T activa en su TSS.
- bandera RF (resume), registro EFLAGS; suprime múltiples excepciones a la misma instrucción.
- bandera TF (trap), registro EFLAGS; genera una excepción de depuración después de cada ejecución de una instrucción.
- Instrucción breakpoint (INT3); genera una excepción de breakpoint que transfiere el control del programa al procedimiento de depuración. Es especialmente útil cuando se quieren mas de 4 breakpoints o cuando se ponen en el código fuente.
- facilidades de grabación del último banco; El banco de reserva guarda en la pila de 'last branch record' (o LBR) los MSRs para los últimos bancos recibidos, interrupciones, y/o excepciones en MSRs.
El monitoreo del rendimiento se introdujo en el procesador Pentium con un conjunto de contadores de monitoreo de rendimiento específicos. Estos contadores permiten seleccionar los parámetros de rendimiento del procesador para que sean monitorizados. La información de los contadores se puede usar para poner a punto el sistema y el rendimiento del compilador. En la familia P6 este mecanismo se mejoró permitiendo una selección mayor de eventos a monitorizar y permite un mayor control para monitorizar mas eventos. Mas tarde, los Pentium 4 y Xeon lo mejoraron aun mas y incluyeron un nuevo conjunto de eventos de rendimiento. Estos mecanismos de monitorización del rendimiento y los eventos del rendimiento no son arquitectónicos; son específicos de cada modelo (diferentes y no compatibles entre familias).
Los eventos de monitorización de rendimiento son arquitectónicos cuando tienen consistencia entre microarquitecturas. Intel Core Solo y Intel Core Duo introducen el monitoreo del rendimiento de la arquitectura. Esta característica proporciona un mecanismo al software para enumerar eventos de rendimiento y proporciona facilidades de configuración y contadores para eventos.
El contaje de los ciclos (clockticks), forma una base para medir cuanto tiempo le lleva ejecutarse a un programa. Este contaje también se usa como parte de ratios eficientes, como los ciclos por instrucción (CPI). Los relojes pueden dejar de marcar si el procesador se para cuando no hay nada que hacer en la CPU, o cuando el procesador está 'dormido' como resultado de ser parado o por algún tema de administración energética.
La capacidad de monitoreo del rendimiento en procesadores de doble núcleo duplica las fuentes de la microarquitectura de un procesador mononúcleo. Cada núcleo tiene sus propias fuentes de monitoreo de rendimiento dedicadas.
Los procesadores de la familia P6 proporcionan dos contadores de rendimiento de 40 bits, permitiendo monitorizar dos tipos de eventos a la vez. Pueden o contar eventos o medir su duración. Cuando los cuentan, un contador se incrementa cada vez que se da uno o varios eventos específicos. La acción de estos contadores engloba todos los niveles de privilegios.
El procesador Pentium también proporciona dos contadores de 40 bits, que se pueden usar para contar eventos o medir su duración. Los contadores están soportados por tres MSRs: el MSR selector de control y eventos (CESR) y los MSRs contadores de rendimiento (CTR0 y CTR1). En estos se puede escribir y leer utilizando las instrucciones RDMSR y WRMSR, teniendo privilegios de nivel 0 (los máximos). Cada contador está asociado a un pin externo el cual puede ser usado para indicar el estado del contador al hardware externo.
Estas son las facilidades de depuración y de monitorización de rendimiento:
- Excepción de depuración (#DB); transfiere el control del programa a un procedimiento de depuración cuando ocurre un evento de depuración.
- Excepción Breakpoint (#BP)
- Registro de direcciones breakpoint (DR0 a DR3); especifican las direcciones de 4 breakpoints.
- Registro de estado de depuración (DR6); Devuelve las condiciones efectivas cuando se generó la excepción de depuración o de breakpoint.
- Registro de control de depuración (DR7); Especifica la forma de acceso a memoria o de E/S que causó que se generara el breakpoint.
- bandera T (trap), TSS; genera una excepción de depuración cuando se intenta cambiar de tarea con la bandera T activa en su TSS.
- bandera RF (resume), registro EFLAGS; suprime múltiples excepciones a la misma instrucción.
- bandera TF (trap), registro EFLAGS; genera una excepción de depuración después de cada ejecución de una instrucción.
- Instrucción breakpoint (INT3); genera una excepción de breakpoint que transfiere el control del programa al procedimiento de depuración. Es especialmente útil cuando se quieren mas de 4 breakpoints o cuando se ponen en el código fuente.
- facilidades de grabación del último banco; El banco de reserva guarda en la pila de 'last branch record' (o LBR) los MSRs para los últimos bancos recibidos, interrupciones, y/o excepciones en MSRs.
El monitoreo del rendimiento se introdujo en el procesador Pentium con un conjunto de contadores de monitoreo de rendimiento específicos. Estos contadores permiten seleccionar los parámetros de rendimiento del procesador para que sean monitorizados. La información de los contadores se puede usar para poner a punto el sistema y el rendimiento del compilador. En la familia P6 este mecanismo se mejoró permitiendo una selección mayor de eventos a monitorizar y permite un mayor control para monitorizar mas eventos. Mas tarde, los Pentium 4 y Xeon lo mejoraron aun mas y incluyeron un nuevo conjunto de eventos de rendimiento. Estos mecanismos de monitorización del rendimiento y los eventos del rendimiento no son arquitectónicos; son específicos de cada modelo (diferentes y no compatibles entre familias).
Los eventos de monitorización de rendimiento son arquitectónicos cuando tienen consistencia entre microarquitecturas. Intel Core Solo y Intel Core Duo introducen el monitoreo del rendimiento de la arquitectura. Esta característica proporciona un mecanismo al software para enumerar eventos de rendimiento y proporciona facilidades de configuración y contadores para eventos.
El contaje de los ciclos (clockticks), forma una base para medir cuanto tiempo le lleva ejecutarse a un programa. Este contaje también se usa como parte de ratios eficientes, como los ciclos por instrucción (CPI). Los relojes pueden dejar de marcar si el procesador se para cuando no hay nada que hacer en la CPU, o cuando el procesador está 'dormido' como resultado de ser parado o por algún tema de administración energética.
La capacidad de monitoreo del rendimiento en procesadores de doble núcleo duplica las fuentes de la microarquitectura de un procesador mononúcleo. Cada núcleo tiene sus propias fuentes de monitoreo de rendimiento dedicadas.
Los procesadores de la familia P6 proporcionan dos contadores de rendimiento de 40 bits, permitiendo monitorizar dos tipos de eventos a la vez. Pueden o contar eventos o medir su duración. Cuando los cuentan, un contador se incrementa cada vez que se da uno o varios eventos específicos. La acción de estos contadores engloba todos los niveles de privilegios.
El procesador Pentium también proporciona dos contadores de 40 bits, que se pueden usar para contar eventos o medir su duración. Los contadores están soportados por tres MSRs: el MSR selector de control y eventos (CESR) y los MSRs contadores de rendimiento (CTR0 y CTR1). En estos se puede escribir y leer utilizando las instrucciones RDMSR y WRMSR, teniendo privilegios de nivel 0 (los máximos). Cada contador está asociado a un pin externo el cual puede ser usado para indicar el estado del contador al hardware externo.
lunes, 12 de enero de 2009
Compatibilidad
Los procesadores IA-32 y Intel 64 son binarios compatibles. Como compatibilidad se entiende que, dentro de una limitación, los programas que se ejecutan en generaciones anteriores de los procesadores producirán resultados idénticos cuando se ejecutan en posteriores. Cada nuevo procesador aumenta la arquitectura visible del software desde la de procesadores IA-32 y Intel 64 'menos nuevos'. Estos aumentos tienen en cuenta la compatibilidad con anteriores y futuras versiones de procesadores.
A lo largo de este manual, ciertos bits fueron marcados como de reserva en muchos registros. Cuando los bits son marcados como indefinidos o reservados, es esencial para la compatibilidad con los procesadores futuros que el software trate de que esos bits tengan futuro, a través de efectos desconocidos. El software no debe depender del estado de ninguno de esos bits cuando se testean los valores de los registros o las localizaciones de memoria, del estado de esos bits cuando se guardan en memoria o en un registro, ni de la capacidad de retener información escrita en bits reservados. Cuando se carga un registro siempre se debe hacer con los valores de los bits reservados indicados en la documentación.
La mayoría de las nuevas funciones de control definidas para la familia P6 y Pentium están disponibles en nuevos modos de banderas en registros de control. Este registro no está definido para procesadores anteriores a los Pentium. El software puede comprobar la presencia de nuevas características arquitectónicas y extensiones comprobando la presencia de características o extensiones sirviéndose de los registros EFLAGS y los de control, o ejecutando la instrucción CPUID.
A lo largo de este manual, ciertos bits fueron marcados como de reserva en muchos registros. Cuando los bits son marcados como indefinidos o reservados, es esencial para la compatibilidad con los procesadores futuros que el software trate de que esos bits tengan futuro, a través de efectos desconocidos. El software no debe depender del estado de ninguno de esos bits cuando se testean los valores de los registros o las localizaciones de memoria, del estado de esos bits cuando se guardan en memoria o en un registro, ni de la capacidad de retener información escrita en bits reservados. Cuando se carga un registro siempre se debe hacer con los valores de los bits reservados indicados en la documentación.
La mayoría de las nuevas funciones de control definidas para la familia P6 y Pentium están disponibles en nuevos modos de banderas en registros de control. Este registro no está definido para procesadores anteriores a los Pentium. El software puede comprobar la presencia de nuevas características arquitectónicas y extensiones comprobando la presencia de características o extensiones sirviéndose de los registros EFLAGS y los de control, o ejecutando la instrucción CPUID.
Mezclando códigos de 16 y de 32 bits
Los módulos de un programa escritos para funcionar en procesadores IA-32 pueden ser de 16 o de 32 bits, aunque funcionan de forma mas eficiente cuando ejecutan programas de 32 bits. Pueden ejecutar módulos de programas de 16 bits en el modo real-address, en el modo virtual-8086, en el modo de administración del sistema (SMM), como una tarea en modo protegido (si el código, los datos y los segmentos de pila para esa tarea están configurados como segmentos de 16 bits), integrando segmentos de 16 y de 32 bits en una tarea única en modo protegido, y por último integrando operaciones de 16 bits en segmentos de código de 32. Los modos real-address, virtual-8086 y SMM son nativamente modos de 16 bits. Lo siguiente son los mecanismos usados para distinguir y para dar soporte a segmentos y operaciones de 16 y 32 bits:
- La bandera D en los descriptores de segmentos de código.
- La bandera B en los descriptores de segmentos de pila.
- Las puertas de llamada de 16 y 32 bits, de interrupción, y de trampa.
- Los prefijos de instrucciones de tamaño de operando y de tamaño de dirección.
- Los registros de propósito general de 16 y de 32 bits.
La bandera D determina el tamaño de operando y de dirección por defecto para las instrucciones de un segmento de código. La bandera B especifica el tamaño del puntero de la pila usado por el procesador para referencias implícitas en la pila.
Los siguientes dos prefijos de instrucción permiten mezclar operaciones de 32 y de 16 bits dentro de un segmento: El prefijo de tamaño de operando (66H) y el prefijo de tamaño de dirección (67H). Siempre que sea posible se debe usar segmentos de código de 32 bits, ya que funcionan mucho mas rápido. Si un sistema operativo está diseñado en 16 bits, probablemente no funcionen los módulos en 32. Si un código se diseña para funcionar en el modo real-address, en el modo virtual-8086, o en el modo SMM, tiene que ser de 16 bits.
A los segmentos de datos se puede acceder desde segmentos de 16 y de 32 bits. Cuando un segmento de datos es mas largo que 64 KBytes se comparte a lo largo de segmentos de código de 16 o de 32 bits, los datos a los que se debe acceder desde el segmento de 16 bits tiene que ser localizado dentro de los primeros 64 KBytes del segmento de datos. Esto se debe a que los punteros de 16 bits pueden apuntar como máximo a los 64 KBytes del segmento. Una pila que ocupa menos de 64 KBytes puede ser compartida por segmentos de código de 16 y de 32 bits.
Hay 3 formas de que un procedimiento en un segmento de 16 bits llame de forma segura a un código de 32 bits:
- Hacer la llamada a través de una puerta de llamada de 32 bits.
- Hacer una llamada de 16 bits a un procedimiento de interface de 32 bits. Después el procedimiento de interface hace una llamada de 32 bits al destino deseado.
- Modificar el procedimiento de 16 bits insertando un prefijo de tamaño de operando antes de la llamada, para cambiarla por una llamada de 32 bits.
Hay otras tres formas de hacer una llamada de forma segura desde un segmento de código de 32 bits a uno de 16:
- Hacer la llamada a través de una puerta de llamada de 16 bits (el valor EIP de la instrucción CALL no puede exceder de FFFFH)
- Hacer una llamada de 32 bits a un procedimiento de interfaz de 16, y que éste haga otra al destino deseado.
- Modificar el procedimiento de 32 bits insertando un prefijo de tamaño de operando antes de la llamada. Hay que asegurarse de que el offset de retorno no exceda FFFFH.
- La bandera D en los descriptores de segmentos de código.
- La bandera B en los descriptores de segmentos de pila.
- Las puertas de llamada de 16 y 32 bits, de interrupción, y de trampa.
- Los prefijos de instrucciones de tamaño de operando y de tamaño de dirección.
- Los registros de propósito general de 16 y de 32 bits.
La bandera D determina el tamaño de operando y de dirección por defecto para las instrucciones de un segmento de código. La bandera B especifica el tamaño del puntero de la pila usado por el procesador para referencias implícitas en la pila.
Los siguientes dos prefijos de instrucción permiten mezclar operaciones de 32 y de 16 bits dentro de un segmento: El prefijo de tamaño de operando (66H) y el prefijo de tamaño de dirección (67H). Siempre que sea posible se debe usar segmentos de código de 32 bits, ya que funcionan mucho mas rápido. Si un sistema operativo está diseñado en 16 bits, probablemente no funcionen los módulos en 32. Si un código se diseña para funcionar en el modo real-address, en el modo virtual-8086, o en el modo SMM, tiene que ser de 16 bits.
A los segmentos de datos se puede acceder desde segmentos de 16 y de 32 bits. Cuando un segmento de datos es mas largo que 64 KBytes se comparte a lo largo de segmentos de código de 16 o de 32 bits, los datos a los que se debe acceder desde el segmento de 16 bits tiene que ser localizado dentro de los primeros 64 KBytes del segmento de datos. Esto se debe a que los punteros de 16 bits pueden apuntar como máximo a los 64 KBytes del segmento. Una pila que ocupa menos de 64 KBytes puede ser compartida por segmentos de código de 16 y de 32 bits.
Hay 3 formas de que un procedimiento en un segmento de 16 bits llame de forma segura a un código de 32 bits:
- Hacer la llamada a través de una puerta de llamada de 32 bits.
- Hacer una llamada de 16 bits a un procedimiento de interface de 32 bits. Después el procedimiento de interface hace una llamada de 32 bits al destino deseado.
- Modificar el procedimiento de 16 bits insertando un prefijo de tamaño de operando antes de la llamada, para cambiarla por una llamada de 32 bits.
Hay otras tres formas de hacer una llamada de forma segura desde un segmento de código de 32 bits a uno de 16:
- Hacer la llamada a través de una puerta de llamada de 16 bits (el valor EIP de la instrucción CALL no puede exceder de FFFFH)
- Hacer una llamada de 32 bits a un procedimiento de interfaz de 16, y que éste haga otra al destino deseado.
- Modificar el procedimiento de 32 bits insertando un prefijo de tamaño de operando antes de la llamada. Hay que asegurarse de que el offset de retorno no exceda FFFFH.
Emulación 8086
Los procesadores IA-32 proporcionan dos maneras de ejecutar programas nuevos o heredados que están ensamblados y/o compilados para funcionar en un procesador Intel 8086: El modo real-address, y el modo virtual-8086. Cuando el procesador se enciende o se resetea, comienza en el modo real-address. Este modo de operación casi duplica exactamente el entorno de ejecución del procesador Intel 8086, con algunas extensiones. Virtualmente cualquier programa ensamblado y/o compilado para funcionar en Intel 8086 puede hacerlo en un procesador IA-32 en este modo. Cuando se funciona en modo protegido, el procesador puede cambiar al modo virtual-8086 para ejecutar programas 8086. Este modo duplica el entorno de ejecución del procesador Intel 8086, con extensiones. En el modo virtual-8086, un programa 8086 funciona como una tarea en modo protegido separada. Los programas 8086 heredados son capaces de funcionar bajo un sistema operativo que toma ventaja del modo protegido y de usar facilidades de este modo. La multitarea en el modo protegido permite tareas múltiples en el modo virtual-8086.
En el modo real-address, el procesador no interpreta los selectores de segmentos como indexados en una tabla de descriptores; en cambio, los usa directamente a direcciones lineales, como lo hace el procesador 8086. Cuando se usa la traducción de direcciones del estilo 8086, es posible especificar direcciones más largas que 1 MByte. El conjunto de registros disponible en el modo real-address incluye todos los registros definidos para el procesador 8086 y los nuevos registros introducidos mas tarde en los procesadores IA-32, como los registros de segmento FS y GS, los de depuración, etc. Cuando se opera en el modo real-address, el software tiene que proporcionar facilidades de administración de excepciones y interrupciones que estén separados desde los proporcionados en el modo protegido. Los procesadores IA-32 administran interrupciones y excepciones en el modo real-address de modo similar a como las administran en modo protegido. Cuando un procesador recibe una interrupción o genera una excepción, usa el número de vector de la interrupción o de la excepción como índex en la tabla de interrupciones. La entrada en la tabla de vectores de interrupción proporciona un puntero a un procedimiento de administración de interrupciones o de excepciones.
El modo virtual-8086 es actualmente un tipo especial de tarea que funciona en modo protegido. Cuando el sistema operativo cambia a una tarea en modo virtual-8086, el procesador emula un procesador Intel 8086. La mayor diferencia entre este modo y el real-address es que en el modo virtual-8086 la emulación 8086 usa algunos servicios del modo protegido. Como en el modo real-address, cualquier programa nuevo o heredado que ha sido ensamblado o compilado para funcionar en el procesador Intel 8086 funcionará en una tarea en modo virtual-8086. El procesador se pone en modo virtual-8086 cuando se activa la bandera VM (virtual machine) en el registro EFLAGS. Esta bandera sólo se puede activar cuando el procesador cambia a una tarea nueva en modo protegido o retoma el modo virtual-8086 vía una instrucción IRET. El software del sistema no puede cambiar el estado de la bandera VM directamente en el registro EFLAGS. El procesador puede desactivar el modo virtual-8086 sólo a través de una interrupción o excepción. Las siguientes son situaciones que fuerzan al procesador a salir de ese modo:
- El procesador sirve una interrupción por hardware generada para señalar la suspensión de la ejecución de la aplicación virtual-8086.
- El procesador sirve una excepción o una interrupción causada por la ejecución de código de la tarea virtual-8086 o sirve una interrupción hardware que pertenece a una tarea virtual-8086.
- Un reset de hardware iniciado por los pines RESET o INIT es un tipo especial de interrupción. Entonces el procesador abandona el modo virtual-8086 y entra en el modo real-address.
- La ejecución de una instrucción HLT en el modo virtual-8086 causa una falta de protección general, que el administrador del modo protegido genera y manda al monitor virtual-8086.
Cuando el procesador recibe una interrupción o detecta una excepción mientras está en modo virtual-8086, invoca a un administrador de interrupciones o de excepciones, al igual que lo hace estando en el modo real-address. Este administrador y el mecanismo usado para invocarlo dependen de la clase de interrupción o de excepción detectada, del estado de varias banderas del sistema y de varios campos.
Los IA-32 soportan banderas VIF (virtual interrupt flag) y VIP (virtual interrupt pending) en el registro EFLAGS en modo protegido activando la bandera PVI en el registro CR4. Esto permite a las aplicaciones que funcionen en el nivel 3 de privilegios, ejecutar las instrucciones CLI y STI sin que se genere una excepción de protección general o sin que afecte a las interrupciones por hardware.
En el modo real-address, el procesador no interpreta los selectores de segmentos como indexados en una tabla de descriptores; en cambio, los usa directamente a direcciones lineales, como lo hace el procesador 8086. Cuando se usa la traducción de direcciones del estilo 8086, es posible especificar direcciones más largas que 1 MByte. El conjunto de registros disponible en el modo real-address incluye todos los registros definidos para el procesador 8086 y los nuevos registros introducidos mas tarde en los procesadores IA-32, como los registros de segmento FS y GS, los de depuración, etc. Cuando se opera en el modo real-address, el software tiene que proporcionar facilidades de administración de excepciones y interrupciones que estén separados desde los proporcionados en el modo protegido. Los procesadores IA-32 administran interrupciones y excepciones en el modo real-address de modo similar a como las administran en modo protegido. Cuando un procesador recibe una interrupción o genera una excepción, usa el número de vector de la interrupción o de la excepción como índex en la tabla de interrupciones. La entrada en la tabla de vectores de interrupción proporciona un puntero a un procedimiento de administración de interrupciones o de excepciones.
El modo virtual-8086 es actualmente un tipo especial de tarea que funciona en modo protegido. Cuando el sistema operativo cambia a una tarea en modo virtual-8086, el procesador emula un procesador Intel 8086. La mayor diferencia entre este modo y el real-address es que en el modo virtual-8086 la emulación 8086 usa algunos servicios del modo protegido. Como en el modo real-address, cualquier programa nuevo o heredado que ha sido ensamblado o compilado para funcionar en el procesador Intel 8086 funcionará en una tarea en modo virtual-8086. El procesador se pone en modo virtual-8086 cuando se activa la bandera VM (virtual machine) en el registro EFLAGS. Esta bandera sólo se puede activar cuando el procesador cambia a una tarea nueva en modo protegido o retoma el modo virtual-8086 vía una instrucción IRET. El software del sistema no puede cambiar el estado de la bandera VM directamente en el registro EFLAGS. El procesador puede desactivar el modo virtual-8086 sólo a través de una interrupción o excepción. Las siguientes son situaciones que fuerzan al procesador a salir de ese modo:
- El procesador sirve una interrupción por hardware generada para señalar la suspensión de la ejecución de la aplicación virtual-8086.
- El procesador sirve una excepción o una interrupción causada por la ejecución de código de la tarea virtual-8086 o sirve una interrupción hardware que pertenece a una tarea virtual-8086.
- Un reset de hardware iniciado por los pines RESET o INIT es un tipo especial de interrupción. Entonces el procesador abandona el modo virtual-8086 y entra en el modo real-address.
- La ejecución de una instrucción HLT en el modo virtual-8086 causa una falta de protección general, que el administrador del modo protegido genera y manda al monitor virtual-8086.
Cuando el procesador recibe una interrupción o detecta una excepción mientras está en modo virtual-8086, invoca a un administrador de interrupciones o de excepciones, al igual que lo hace estando en el modo real-address. Este administrador y el mecanismo usado para invocarlo dependen de la clase de interrupción o de excepción detectada, del estado de varias banderas del sistema y de varios campos.
Los IA-32 soportan banderas VIF (virtual interrupt flag) y VIP (virtual interrupt pending) en el registro EFLAGS en modo protegido activando la bandera PVI en el registro CR4. Esto permite a las aplicaciones que funcionen en el nivel 3 de privilegios, ejecutar las instrucciones CLI y STI sin que se genere una excepción de protección general o sin que afecte a las interrupciones por hardware.
viernes, 9 de enero de 2009
Arquitectura de comprobación de máquina
Los Pentium 4, Intel Xeon, y la familia P6 implementan una arquitectura de máquina que proporciona un mecanismo para detectar y reportar errores de hardware, como errores en los buses del sistema, errores en caches...Consiste en un conjunto de registros específicos de modelo (MSRs) que se usan para montar comprobaciones de máquina y bancos adicionales de MSRs usados para guardar errores detectados. El procesador señala la detección de un error de comprobación de máquina mal corregido generando una excepción de comprobación de máquina. La implementación de esta arquitectura no permite que el procesador se reinicie después de generar una excepción de comprobación de máquina. Sin embargo, el administrador de excepciones de comprobación de máquina puede recoger información sobre el error desde los MSRs de comprobación de máquina.
Los MSRs de comprobaciones de máquina en los Pentium 4, Intel Xeon, y en la familia P6 consisten en un conjunto de registros de control y de estado globales y varios bancos de registros de reportado de errores. Cada banco está asociado con una unidad hardware específica en el procesador. Para leer y escribir en estos registros se usan las instrucciones RDMSR y WRMSR. Cada banco de registros de reporte de errores puede contener los MSRs IA32_MCi_CTL, IA32_MCi_STATUS, IA32_MCi_ADDR, y IA32_MCi_MISC. El número de bancos de reporte se indica por los bits [7:0] del MSR IA32_MCG_CAP. El primer registro de reporte de errores empieza siempre en la dirección 400H.
Empezando con los Intel Core Duo, el reporte de errores de la cache fue mejorado. En procesadores anteriores, el estado de la cache estaba basada en el número de correcciones que ocurrían eventualmente. Ahora, el estado de la cache está basada en el número de líneas en una cache que sufren repetidas correcciones. Un procesador que soporta reporte de errores de cache mejorado contiene hardware que rastrea el estado operativo de ciertos caches y proporciona un indicador de su 'salud'. El hardware reporta un estado 'verde' cuando el número de lineas que sufre repetidas correcciones está por debajo de un umbral, y se reporta un estado 'amarillo' cuando ese umbral se irrumpe. En este caso la cache que lo reporta opera correctamente, pero se debe programar el sistema para que sirva dentro de un par de semanas. Intel recomienda contar con este mecanismo para estructuras soportadas por el reporte de errores basado en umbral.
La interrupción de error de comprobación de máquina (CMCI) en una mejora arquitectónica que proporciona capacidades más allá de las de reporte de errores basadas en umbral. Con esta última, el software está limitado a usar periodic polling para preguntar el estado de errores MC corregido por hardware. CMCI (que está desactivado por defecto) proporciona un mecanismo de señalización para repartir una interrupción local basada en los valores de umbral que puede programar el software usando los MSRs IA32_MCi_CTL2. Para detectar la existencia de umbrales para un banco determinado, el software escribe solo los bits 14:0 con el valor del umbral. Si los bits persisten, entonces los umbrales están disponibles (y CMCI también). Si los bits son todos ceros, entonces no existen.
Cuando el procesador detecta una condición de error de comprobación de máquina, escribe un código de error de 16 bits en el campo de códigos de error del MCA de uno de los registros IA32_MCi_STATUS y activa la bandera VAL (válido) en el registro. Los códigos de error MCA están arquitectónicamente definidos para los procesadores IA-32 y Intel 64. Para determinar la causa de la excepción, el administrador de excepciones de comprobación de máquina tiene que leer la bandera VAL para cada registro IA32_MCi_STATUS. Si la bandera está activa, el administrador debe leer el campo de código de error MCA del registro. Es la codificación del campo la que determina el tipo de error que se reporta y no el banco de registros reportado. Hay 2 tipos de código: códigos de errores simples, y códigos de errores compuestos.
La arquitectura para comprobaciones de máquina y logging de errores se pueden usar de dos formas distintas:
- Para detectar errores de máquina durante una ejecución normal de instrucciones
- Para comprobar periódicamente y loggear los errores de máquina.
Para usar la excepción de comprobación de máquina, el sistema operativo debe proporcionar un administrador de excepciones de comprobación de la máquina. Este administrador puede necesitar ser diseñado específicamente para cada familia de procesadores. Se requiere un programa o una utilidad especial para loggear errores de máquina.
Los MSRs de comprobaciones de máquina en los Pentium 4, Intel Xeon, y en la familia P6 consisten en un conjunto de registros de control y de estado globales y varios bancos de registros de reportado de errores. Cada banco está asociado con una unidad hardware específica en el procesador. Para leer y escribir en estos registros se usan las instrucciones RDMSR y WRMSR. Cada banco de registros de reporte de errores puede contener los MSRs IA32_MCi_CTL, IA32_MCi_STATUS, IA32_MCi_ADDR, y IA32_MCi_MISC. El número de bancos de reporte se indica por los bits [7:0] del MSR IA32_MCG_CAP. El primer registro de reporte de errores empieza siempre en la dirección 400H.
Empezando con los Intel Core Duo, el reporte de errores de la cache fue mejorado. En procesadores anteriores, el estado de la cache estaba basada en el número de correcciones que ocurrían eventualmente. Ahora, el estado de la cache está basada en el número de líneas en una cache que sufren repetidas correcciones. Un procesador que soporta reporte de errores de cache mejorado contiene hardware que rastrea el estado operativo de ciertos caches y proporciona un indicador de su 'salud'. El hardware reporta un estado 'verde' cuando el número de lineas que sufre repetidas correcciones está por debajo de un umbral, y se reporta un estado 'amarillo' cuando ese umbral se irrumpe. En este caso la cache que lo reporta opera correctamente, pero se debe programar el sistema para que sirva dentro de un par de semanas. Intel recomienda contar con este mecanismo para estructuras soportadas por el reporte de errores basado en umbral.
La interrupción de error de comprobación de máquina (CMCI) en una mejora arquitectónica que proporciona capacidades más allá de las de reporte de errores basadas en umbral. Con esta última, el software está limitado a usar periodic polling para preguntar el estado de errores MC corregido por hardware. CMCI (que está desactivado por defecto) proporciona un mecanismo de señalización para repartir una interrupción local basada en los valores de umbral que puede programar el software usando los MSRs IA32_MCi_CTL2. Para detectar la existencia de umbrales para un banco determinado, el software escribe solo los bits 14:0 con el valor del umbral. Si los bits persisten, entonces los umbrales están disponibles (y CMCI también). Si los bits son todos ceros, entonces no existen.
Cuando el procesador detecta una condición de error de comprobación de máquina, escribe un código de error de 16 bits en el campo de códigos de error del MCA de uno de los registros IA32_MCi_STATUS y activa la bandera VAL (válido) en el registro. Los códigos de error MCA están arquitectónicamente definidos para los procesadores IA-32 y Intel 64. Para determinar la causa de la excepción, el administrador de excepciones de comprobación de máquina tiene que leer la bandera VAL para cada registro IA32_MCi_STATUS. Si la bandera está activa, el administrador debe leer el campo de código de error MCA del registro. Es la codificación del campo la que determina el tipo de error que se reporta y no el banco de registros reportado. Hay 2 tipos de código: códigos de errores simples, y códigos de errores compuestos.
La arquitectura para comprobaciones de máquina y logging de errores se pueden usar de dos formas distintas:
- Para detectar errores de máquina durante una ejecución normal de instrucciones
- Para comprobar periódicamente y loggear los errores de máquina.
Para usar la excepción de comprobación de máquina, el sistema operativo debe proporcionar un administrador de excepciones de comprobación de la máquina. Este administrador puede necesitar ser diseñado específicamente para cada familia de procesadores. Se requiere un programa o una utilidad especial para loggear errores de máquina.
jueves, 8 de enero de 2009
Administración de energía y calor
La tecnología Intel SpeedStep mejorada fue incluida en el Pentium M, y está disponible en la mayoría de los procesadores actuales. Esta tecnología administra el consumo de energía del procesador usando transiciones de estado del rendimiento. Estos estados están definidos como puntos de operaciones discretas asociados con frecuencias diferentes. Esta tecnología mejorada difiere de sus generaciones previas en dos sentidos:
- Centraliza el mecanismo de control y el interfaz del software en el procesador usando registros específicos de cada modelo.
- Reduciendo el overhead del hardware; permite transiciones de estado de rendimiento mas frecuentes.
La disponibilidad de esta tecnología se indica en el CPUID. La configuración avanzada y interfaz de energía (ACPI) define estados de rendimiento (P-state) que son usados para facilitar la capacidad del software del sistema para administrar el consumo de energía del procesador. P-states diferentes corresponden a diferentes niveles de rendimiento que se aplican mientras el procesador está ejecutando instrucciones. Con múltiples núcleos de procesador residiendo en la misma unidad física, las dependencias del hardware pueden existir para un subconjunto de procesadores lógicos en una plataforma. Estas dependencias pueden imponer requisitos que afecten a la coordinación de las transiciones P-state. Como resultado, los procesadores con núcleo múltiple pueden requerir un sistema operativo para proporcionar soporte de software adicional para coordinar transiciones P-state para este subconjunto de procesadores lógicos. La BIOS puede elegir exponer el P-state como dependiente y coordinado con el hardware a la política de administración de la energía (OSPM) del sistema operativo. Para soportar OSPMs, los procesadores multinúcleo tienen que tener soporte adicional para la coordinación de hardware P-state y retroalimentación.
La arquitectura IA-32 proporciona los siguientes mecanismos de monitorización de la temperatura y control de térmico de la energía:
- El detector de apagones catastróficos fuerza a parar la ejecución si la temperatura del núcleo del procesador tiene riesgo de sobrepasar un límite establecido.
- Los mecanismos de monitorización térmicos adaptativos y automáticos fuerzan al procesador a reducir su consumo de energía para operar dentro de los límites predefinidos.
- El mecanismo de modulación del reloj controlado por software permite al sistema operativo implementar políticas de administración de energía que reducen el consumo de energía.
- Los mecanismos de interrupciones y sensores térmicos digitales 'on-die' permiten al sistema operativo administrar nativamente condiciones térmicas sin depender de la BIOS o otros componentes del sistema.
El primer mecanismo no es visible al software; los demás si.
- Centraliza el mecanismo de control y el interfaz del software en el procesador usando registros específicos de cada modelo.
- Reduciendo el overhead del hardware; permite transiciones de estado de rendimiento mas frecuentes.
La disponibilidad de esta tecnología se indica en el CPUID. La configuración avanzada y interfaz de energía (ACPI) define estados de rendimiento (P-state) que son usados para facilitar la capacidad del software del sistema para administrar el consumo de energía del procesador. P-states diferentes corresponden a diferentes niveles de rendimiento que se aplican mientras el procesador está ejecutando instrucciones. Con múltiples núcleos de procesador residiendo en la misma unidad física, las dependencias del hardware pueden existir para un subconjunto de procesadores lógicos en una plataforma. Estas dependencias pueden imponer requisitos que afecten a la coordinación de las transiciones P-state. Como resultado, los procesadores con núcleo múltiple pueden requerir un sistema operativo para proporcionar soporte de software adicional para coordinar transiciones P-state para este subconjunto de procesadores lógicos. La BIOS puede elegir exponer el P-state como dependiente y coordinado con el hardware a la política de administración de la energía (OSPM) del sistema operativo. Para soportar OSPMs, los procesadores multinúcleo tienen que tener soporte adicional para la coordinación de hardware P-state y retroalimentación.
La arquitectura IA-32 proporciona los siguientes mecanismos de monitorización de la temperatura y control de térmico de la energía:
- El detector de apagones catastróficos fuerza a parar la ejecución si la temperatura del núcleo del procesador tiene riesgo de sobrepasar un límite establecido.
- Los mecanismos de monitorización térmicos adaptativos y automáticos fuerzan al procesador a reducir su consumo de energía para operar dentro de los límites predefinidos.
- El mecanismo de modulación del reloj controlado por software permite al sistema operativo implementar políticas de administración de energía que reducen el consumo de energía.
- Los mecanismos de interrupciones y sensores térmicos digitales 'on-die' permiten al sistema operativo administrar nativamente condiciones térmicas sin depender de la BIOS o otros componentes del sistema.
El primer mecanismo no es visible al software; los demás si.
Programación del sistema para extensiones del conjunto de instrucciones y del procesador
Para usar las extensiones SSE/SSE2/SSE3/SSSE3/SSE4, el sistema operativo tiene que proporcionar un soporte de inicialización del procesador para usarlas, para administrar las instrucciones de guardar estado FXSAVE y FXRSTOR, y para administrar las excepciones en punto flotante SIMD.
Para soportar las extensiones el sistema operativo debe realizar estas operaciones:
- Comprobar que el procesador las soporta (con CPUID).
- Comprobar que el procesador soporta las instrucciones FXSAVE y FXRSTOR (con CPUID).
- Proporcionar una inicialización para los estados de las extensiones.
- Proporcionar el soporte para las instrucciones FXSAVE y FXRSTOR.
- Proporcionar soporte, si es necesario, en administradores de excepciones no numéricas para las generadas por las instrucciones de las extensiones.
- Proporcionar un administrador de excepciones para la excepción SIMD en punto flotante.
Las arquitecturas IA-32 y Intel 64 no soportan la emulación de las instrucciones SSE/SSE2/SSE3/SSSE3/SSE4, como soportan a las instrucciones de FPU x87. La bandera EM del registro de control CR0 no se puede usar para invocar la emulación de las instrucciones de las extensiones. Si una instrucción de las extensiones se ejecuta cuando CR0.EM=1, se produce una excepción de opcode inválido.
Los estados de las extensiones consisten en el estado de los registros XMM y MXCSR. El método recomendado para guardar y recuperar estos estados es el siguiente:
- Ejecutar una instrucción FXSAVE para guardar el estado de los registros XMM y MXCSR en memoria.
- Ejecutar una instrucción FXRSTOR para recuperar el estado de los registros desde la imagen guardada en memoria por la instrucción FXSAVE.
Las características asociadas al manejo de estados de extensiones del procesador incluyen:
- Una distribución de datos extensible para las extensiones del estado del procesador existentes y futuras. La distribución del área XSAVE/XRSTOR se extiende desde el byte 512 para provocar compatibilidad y recorrido de migración desde el área FXSAVE/FXRSTOR.
- Una mejora del CPUID.
- Una mejora en el registro de control y en los registros dedicados para activar cada estado de extensión de cada procesador.
- Instrucciones para administrar el registro XFEATURE_ENABLED_MASK (XCR0) y el área de XSAVE/XRSTOR.
Para soportar las extensiones el sistema operativo debe realizar estas operaciones:
- Comprobar que el procesador las soporta (con CPUID).
- Comprobar que el procesador soporta las instrucciones FXSAVE y FXRSTOR (con CPUID).
- Proporcionar una inicialización para los estados de las extensiones.
- Proporcionar el soporte para las instrucciones FXSAVE y FXRSTOR.
- Proporcionar soporte, si es necesario, en administradores de excepciones no numéricas para las generadas por las instrucciones de las extensiones.
- Proporcionar un administrador de excepciones para la excepción SIMD en punto flotante.
Las arquitecturas IA-32 y Intel 64 no soportan la emulación de las instrucciones SSE/SSE2/SSE3/SSSE3/SSE4, como soportan a las instrucciones de FPU x87. La bandera EM del registro de control CR0 no se puede usar para invocar la emulación de las instrucciones de las extensiones. Si una instrucción de las extensiones se ejecuta cuando CR0.EM=1, se produce una excepción de opcode inválido.
Los estados de las extensiones consisten en el estado de los registros XMM y MXCSR. El método recomendado para guardar y recuperar estos estados es el siguiente:
- Ejecutar una instrucción FXSAVE para guardar el estado de los registros XMM y MXCSR en memoria.
- Ejecutar una instrucción FXRSTOR para recuperar el estado de los registros desde la imagen guardada en memoria por la instrucción FXSAVE.
Las características asociadas al manejo de estados de extensiones del procesador incluyen:
- Una distribución de datos extensible para las extensiones del estado del procesador existentes y futuras. La distribución del área XSAVE/XRSTOR se extiende desde el byte 512 para provocar compatibilidad y recorrido de migración desde el área FXSAVE/FXRSTOR.
- Una mejora del CPUID.
- Una mejora en el registro de control y en los registros dedicados para activar cada estado de extensión de cada procesador.
- Instrucciones para administrar el registro XFEATURE_ENABLED_MASK (XCR0) y el área de XSAVE/XRSTOR.
Programando con la tecnología MMX de Intel
Las arquitecturas IA-32 y Intel 64 no soportan la emulación de instrucciones MMX, pero si las instrucciones x87 FPU. La bandera EM en el registro de control CR0 no puede ser usada para la emulación de instrucciones MMX. Si una instrucción MMX se ejecuta cuando está activada la bandera EM, se produce una excepción de opcode inválido.
El estado del MMX consiste en registros de 64 bits (desde MM0 hasta MM7). Estos son alias de los 64 bits más bajos de los registros en punto flotante R0 a R7. Los registros MMX están mapeados a las localizaciones físicas de los registros en punto flotante (R0 a R7), no a las relativas localizaciones de los registros en la pila de registros en punto flotante (ST0 a ST7). Como resultado, el mapeo de registros MMX es fijo y no le afecta el valor en el campo de la Top of Stack (TOS) en la palabra de estado de punto flotante (bits de 11 al 13). Cuando se escribe un valor en un registro MMX usando una instrucción MMX, el valor aparece en el registro de punto flotante correspondiente en los bits de 0 a 63. Asimismo, cuando un valor en punto flotante se escribe en un registro en punto flotante por la FPU x87, los 64 bits mas bajos del valor aparecen en el registro MMX correspondiente. La ejecución de este tipo de instrucciones tienen varios efectos en el estado de la FPU x87 contenido en los registros en punto flotante, en la palabra de la etiqueta de la FPU x87, y en la palabra de estado de la FPU x87. Los efectos son estos:
- Cuando una instrucción MMX escribe un valor en un registro MMX, al mismo tiempo, los bits 64 a 79 del registro correspondiente en punto flotante, se ponen a 1.
- Cuando una instrucción MMX se ejecuta, cada campo de etiquetas en la palabra de etiquetas de la FPU x87 se pone a 00B (válido).
- Cuando se ejecuta la instrucción EMMS, cada campo de etiquetas en la palabra de etiquetas de la FPU x87 se pone a 11B (vacío).
- Cada vez que se ejecuta una instrucción MMX, el valor de la TOS se pone a 000B.
Como los registros MMX están 'aliased' a los registros de datos de la FPU x87, el estado MMX se puede guardar en la memoria y se puede recuperar de estas formas:
- Ejecutando una instrucción FSAVE, FNSAVE, o FXSAVE para guardar el estado MMX en memoria.
- Ejecutando una instrucción FRSTOR o FXRSTOR para recuperar el estado MMX desde la memoria.
Estos métodos son requeridos por los sistemas operativos; las aplicaciones, en algunos casos, pueden guardar y recuperar solo los registros MMX de estas 2 formas:
- Ejecutando 8 instrucciones MOVQ para guardar el contenido del MMX0 al MMX7 a memoria. Una instrucción EMMS se puede ejecutar para borrar el estado MMX de la FPU x87.
- Ejecutando 8 instrucciones MOVQ para leer el contenido guardado de los registros MMX desde memoria en los registros MMX0 a MMX7.
Cuando se cambia desde una tarea a otra, a veces es necesario guardar el estado del MMX. Como regla general, si el código de cambio de tarea en un sistema operativo incluye facilidades para guardar el estado de la FPU x87, estas facilidades pueden depender sobre guardar el estado MMX, sin reescribir el código de cambio de tarea. Esta dependencia es posible porque el estado MMX es 'aliased' al estado de la FPU x87.
Existen facilidades de depuración que operan de la misma manera cuando se ejecutan instrucciones MMX que cuando se ejecutan otras instrucciones de la IA-32 o de la Intel 64. Para interpretar bien el contenido de los registros MMX o FPU x87 desde la imagen FSAVE/FNSAVE o FXSAVE en memoria, un depurador necesita estar informado de las relaciones entre los registros de la FPU x87 de las localizaciones lógicas relativas a la TOS y a las localizaciones físicas de registros MMX.
El estado del MMX consiste en registros de 64 bits (desde MM0 hasta MM7). Estos son alias de los 64 bits más bajos de los registros en punto flotante R0 a R7. Los registros MMX están mapeados a las localizaciones físicas de los registros en punto flotante (R0 a R7), no a las relativas localizaciones de los registros en la pila de registros en punto flotante (ST0 a ST7). Como resultado, el mapeo de registros MMX es fijo y no le afecta el valor en el campo de la Top of Stack (TOS) en la palabra de estado de punto flotante (bits de 11 al 13). Cuando se escribe un valor en un registro MMX usando una instrucción MMX, el valor aparece en el registro de punto flotante correspondiente en los bits de 0 a 63. Asimismo, cuando un valor en punto flotante se escribe en un registro en punto flotante por la FPU x87, los 64 bits mas bajos del valor aparecen en el registro MMX correspondiente. La ejecución de este tipo de instrucciones tienen varios efectos en el estado de la FPU x87 contenido en los registros en punto flotante, en la palabra de la etiqueta de la FPU x87, y en la palabra de estado de la FPU x87. Los efectos son estos:
- Cuando una instrucción MMX escribe un valor en un registro MMX, al mismo tiempo, los bits 64 a 79 del registro correspondiente en punto flotante, se ponen a 1.
- Cuando una instrucción MMX se ejecuta, cada campo de etiquetas en la palabra de etiquetas de la FPU x87 se pone a 00B (válido).
- Cuando se ejecuta la instrucción EMMS, cada campo de etiquetas en la palabra de etiquetas de la FPU x87 se pone a 11B (vacío).
- Cada vez que se ejecuta una instrucción MMX, el valor de la TOS se pone a 000B.
Como los registros MMX están 'aliased' a los registros de datos de la FPU x87, el estado MMX se puede guardar en la memoria y se puede recuperar de estas formas:
- Ejecutando una instrucción FSAVE, FNSAVE, o FXSAVE para guardar el estado MMX en memoria.
- Ejecutando una instrucción FRSTOR o FXRSTOR para recuperar el estado MMX desde la memoria.
Estos métodos son requeridos por los sistemas operativos; las aplicaciones, en algunos casos, pueden guardar y recuperar solo los registros MMX de estas 2 formas:
- Ejecutando 8 instrucciones MOVQ para guardar el contenido del MMX0 al MMX7 a memoria. Una instrucción EMMS se puede ejecutar para borrar el estado MMX de la FPU x87.
- Ejecutando 8 instrucciones MOVQ para leer el contenido guardado de los registros MMX desde memoria en los registros MMX0 a MMX7.
Cuando se cambia desde una tarea a otra, a veces es necesario guardar el estado del MMX. Como regla general, si el código de cambio de tarea en un sistema operativo incluye facilidades para guardar el estado de la FPU x87, estas facilidades pueden depender sobre guardar el estado MMX, sin reescribir el código de cambio de tarea. Esta dependencia es posible porque el estado MMX es 'aliased' al estado de la FPU x87.
Existen facilidades de depuración que operan de la misma manera cuando se ejecutan instrucciones MMX que cuando se ejecutan otras instrucciones de la IA-32 o de la Intel 64. Para interpretar bien el contenido de los registros MMX o FPU x87 desde la imagen FSAVE/FNSAVE o FXSAVE en memoria, un depurador necesita estar informado de las relaciones entre los registros de la FPU x87 de las localizaciones lógicas relativas a la TOS y a las localizaciones físicas de registros MMX.
Suscribirse a:
Entradas (Atom)