SISTEMAS Y MÉTODOS PARA UTILIZAR INSTRUCCIONES SINTÉTICAS EN UNA MÁQUINA VIRTUAL
Campo de la Invención La presente invención se refiere generalmente al campo de sistemas operativos y, más específicamente al uso de instrucciones que pueden ser entendidas por una máquina virtual (o virtualización del procesador), pero que son definidas como "ilegales" por una arquitectura previamente definida del procesador (por ejemplo, la arquitectura x86), de modo que, cuando son ejecutadas dentro de un entorno de máquina virtual, la presente invención utiliza estas instrucciones para realizar acciones legales bien definidas. En un sentido, la invención agrega instrucciones "sintéticas" a un conjunto de instrucciones previamente existentes. Antecedentes de la Invención Máquinas Virtuales Las computadoras incluyen unidades de procesamiento central de uso general (CPUs) que están diseñadas para ejecutar un conjunto específico de instrucciones del sistema. Un grupo de procesadores que tiene una arquitectura o pueden ser consideradas especificaciones de diseños similares como miembros de alguna familia de procesadores. Los ejemplos de las familias actuales de procesadores incluyen la familia del procesador Motorola 680X0 fabricado por Motorola, Inc. de Phoenix, Arizona; la familia del procesador Intel 80X86, fabricada por Intel Corporation of Sunnyvale, California; y la familia del procesador PowerPC, la cual es fabricada por Motorola, Inc. y utilizada en computadoras fabricadas por Apple Computer, Inc. de Cupertino, California. Aunque un grupo de procesadores puede estar en la misma familia debido a sus arquitecturas y consideraciones de diseño similares, los procesadores pueden variar ampliamente dentro de una sola familia, de acuerdo con su velocidad del reloj y otros parámetros de funcionamiento. Cada una de las familias de microprocesadores ejecuta instrucciones que son únicas para la familia del microprocesador. El conjunto colectivo de instrucciones que ejecuta un procesador o una familia de procesadores es conocido como el conjunto de instrucciones del procesador. Como ejemplo, el conjunto de instrucciones utilizado por la familia del procesador Intel 80X86, no es compatible con el conjunto de instrucciones utilizado por la familia del procesador PowerPC. El conjunto de instrucciones Intel 80X86 está basado en un formato de computadora de Conjuntos de Instrucciones Completas (CISC). El conjunto de instrucciones PowerPC de Motorola, está basado en un formato de computadora del Conjunto de Instrucciones Reducidas (RISC). Los procesadores CISC utilizan un número grande de instrucciones y algunas de ellas pueden realizar funciones más bien complicadas, pero que requieren generalmente muchos ciclos del reloj para ejecutarlas. Los procesadores RISC utilizan un número más pequeño de instrucciones disponibles para realizar un conjunto de funciones más simples que son ejecutadas en un índice mucho más alto. La exclusividad de la familia del procesador entre los sistemas de cómputo, también da como resultado generalmente una incompatibilidad entre los otros elementos de la arquitectura del equipo (hardware) de los sistemas de cómputo. Un sistema de cómputo fabricado con un procesador de la familia de procesadores Intel 80X86 tendrá una arquitectura de hardware que es diferente a la arquitectura del hardware de un sistema de cómputo fabricado con un procesador de la familia de procesadores PowerPC. Debido a la exclusividad del conjunto de instrucciones del procesador y a una arquitectura del hardware del sistema de cómputo, los programa del software de aplicación generalmente son escritos para operar en un sistema de cómputo particular que opera en un sistema operativo particular. Un fabricante de computadoras querrá maximizar su participación en el mercado teniendo más que algunas pocas aplicaciones que operan en la familia de microprocesadores asociado con la línea del producto del fabricante de computadoras. Para expandir el número de sistemas operativos y programas de aplicación que pueden operar en un sistema de computadora, se ha desarrollado un campo de tecnología en la cual una computadora determinada que tiene un tipo de CPU, denominada una computadora central, incluirá un programa emulador que permite que la computadora central emule las instrucciones de un tipo no relacionado de CPU, denominado un invitado. Por lo tanto, la computadora central ejecutará una aplicación que ocasionará que una o más instrucciones de la computadora central sean invocadas en respuesta a una instrucción determinada del invitado. Por lo tanto, la computadora central puede operar tanto el diseño de software para su propia arquitectura de hardware, como un software escrito para computadoras que tienen una arquitectura de hardware que no está relacionada. Como un ejemplo más específico, un sistema de computadora fabricado por Apple Computer, por ejemplo, puede operar los sistemas operativos y los programas escritos para los sistemas de computadoras basados en PC. También puede ser posible utilizar un programa emulador para operar simultáneamente sistemas operativos incompatibles múltiples en un solo CPU. En esta adaptación, aunque cada sistema operativo es incompatible con el otro, un programa emulador puede albergar uno de los dos sistemas operativos, permitiendo, por lo tanto, que los sistemas operativos incompatibles operen simultáneamente en la misma computadora. Cuando un sistema de computadora invitada es emulada en un sistema de computadora central, el sistema de computadora invitada se dice que es una máquina virtual, ya que el sistema de computadora invitada existe solamente como una representación del software de la operación de la arquitectura del hardware del sistema de computadora invitada. Los términos emulador y máquina virtual algunas veces son utilizados de manera intercambiable para indicar la capacidad para imitar o emular la arquitectura del hardware de un sistema de cómputo completo. Como un ejemplo, el software de la Virtual PC creado por Connectix Corporation de San Mateo, California, emula una computadora completa que incluye un procesador Pentium Intel 80X86 y varios componentes de la tarjeta madre y las tarjetas. La operación de estos componentes es emulada en la máquina virtual que está siendo operada en la máquina central. Un programa emulador que se ejecuta en el sistema operativo de la arquitectura del software y el hardware de la computadora central, tal como un sistema de computadora que tiene un procesador PowerPC, imita la operación del sistema completo de la computadora invitada. El programa emulador actúa como el intercambio entre la arquitectura del hardware de la máquina central y las instrucciones transmitidas por e! software que opera dentro del entorno emulado. Las Arquitecturas x86 "x86" es el nombre genérico de la serie de todas las familias de microprocesadores que utilizan la arquitectura del conjunto de instrucciones x86 (ISA). IA32 son arquitecturas del procesador específicas desarrolladas por Intel que utilizan el x86 ISA. El x86 comenzó con el microprocesador Intel 8086. Los procesadores x86 incluyen pero no están limitados a las familias de procesadores Intel 8086, 286, 386, 486, Pentium, Pentium con MMX, Pentium PRO, Pentium II, Pentium III y Pentium 4 , así como Microaparatos Avanzados (AMD's) K5, K6, K6-2, K6-3, Athlon, el Athlon Mejorado (a.k.a. "thunderbird"), el Athlon 4, y el Athlon MP, Athlon 64, el Operon, entre otros. Un monitor de máquina virtual (VMM) es una capa del programa que opera directamente arriba del equipo, y el VMM virtualiza todos los recursos de la máquina exponiendo ¡nterfases que son la misma del hardware que está virtualizando el VMM (lo cual hace posible que el VMM opere sin ser notado por las capas del sistema operativo que operan arriba del mismo). Sin embargo, las arquitecturas x86, que incluyen la arquitectura IA32 y similares, contienen muchos agujeros de virtualización que presentan un número de desafíos para la implementación del VMM. Primero, la arquitectura x86 no divide todas la condiciones del operador en, ya sea una condición privilegiada o una condición del usuario, en donde, entre otras cosas, la condición privilegiada debe incluir cualquier control o campos de condición que indiquen el nivel de privilegio actual, así como otros recursos que necesitan estar bajo el control del sistema operativo subyacente (o "capa de supervisión), para implementar el control recursos y las barreras de protección entre los casos de aplicación del nivel del usuario. Segundo, la arquitectura x86 no ocasiona interrupciones internas del hardware en todos los casos cuando es intentado el acceso a una condición privilegiada en un nivel del usuario (ya sea leer o escribir). Tercero, la arquitectura x86 no tiene medios para ocasionar una interrupción interna del hardware cuando un código del nivel del usuario intenta tener acceso a una condición no privilegiada que debe ser virtualizada (por ejemplo, valores del cronómetro, contadores de funcionamiento, registradores de la característica del procesador). Cuarto, mientras todas las estructuras del procesador en la memoria deben de ser, ya sea almacenadas fuera del espacio de dirección actual o poderse proteger de accesos de memoria errante o maliciosa dentro del VM, la arquitectura x86 no permite esto. Quinto y último, las arquitecturas x86 no pueden restaurar toda la condición del procesador en el momento en que es manejada una interrupción o una interrupción interna del hardware a su condición previa a la interrupción interna del hardware después de la interrupción o que es procesada u na interrupción interna del hardware. Sumario de la Invención Muchas de estas desventajas y limitaciones de las arquitecturas x86 anteriormente mencionadas, son el resultado de instrucciones que fallan en ocasionar una interrupción interna del hardware cuando se desea. En otras palabras, sí estas instrucciones ocasionaran una interrupción interna del hardware, un monitor de máquina virtual (VMM) podría virtualizar correctamente estas instrucciones. La presente invención compensa las desventajas en las arquitecturas del procesador x86 introduciendo "instrucciones sintéticas" que ocasionan una interrupción interna del hardware y por lo tanto, proporcionan una oportunidad para que la máquina virtual (VM) procese las instrucciones de manera segura. Utilizando las instrucciones que son "ilegales" para la arquitectura x86, pero las cuales no obstante, pueden ser entendidas por la máquina virtual, el método actual utiliza instrucciones sintéticas para realizar acciones bien definidas en la máquina virtual que de otra manera serían problemáticas cuando son realizadas por las instrucciones tradicionales ejecutadas en un procesador x86 y de este modo proporciona una virtualización del procesador mejorada para los sistemas de procesador x86.
Breve Descripción de los Dibujos El resumen anterior, así como la siguiente descripción detallada de las modalidades preferidas, se entenderá mejor cuando son leídas en conjunto con los dibujos adjuntos. Para propósitos de ilustración de la invención, en los dibujos se muestran construcciones de ejemplo de la invención, sin embargo, la invención no está limitada a los métodos e instrumentaciones específicas descritas. En los dibujos: La figura 1 ilustra un sistema de cómputo virtualizado que comprende una capa de software del monitor de máquina virtual (VMM) que opera directamente arriba del hardware de la computadora y hace interfase con dos máquinas virtuales (VMs); La figura 2 ilustra el entorno del sistema de cómputo virtualizado de la Figura 1 pero comprende además un sistema operativo invitado (de origen) que hace interfase directamente con el hardware de la computadora; La figura 3 es un diagrama de la relación lógica de los elementos de un sistema de computadora emulado que opera en un sistema de computadora central; La figura 4 ilustra el registro EFLAGS de un procesador x86 (específicamente para la arquitectura IA32). La figura 5 ilustra las cuatro categorizaciones distintas de las modalidades del procesador reconocidas generalmente por un monitor de máquina virtual (VMM). La figura 6 es una tabla de las instrucciones x86 que exponen el hecho de lo que es impuesto como un código de anillo 0 que está operando de hecho en un anillo de nivel más alto, un problema con los métodos de vlrtualización del procesador x86 tradicionales. La figura 7 es una tabla de instrucciones que expone el hecho de que una máquina virtual está sombreando cierta información de registro x86 para el sistema operativo invitado. La figura 8 es una tabla de instrucciones que debe ocasionar una interrupción interna del hardware para propósitos de virtualización, pero en las arquitecturas x86, no lo hace. La figura 9 es una tabla de instrucciones problemáticas que pertenecen a los campos IF e IOPL en las arquitecturas x86. La figura 10 es una gráfica de flujo que ¡lustra una modalidad de un método para mejorar la virtualización en una arquitectura IA32, optimizando el código OS y utilizando "instrucciones sintéticas". Descripción Detallada de la Invención El asunto materia de la invención se describe con especificidad para cubrir los requerimientos de los estatutos. Sin embargo, la descripción misma no pretende limitar el alcance de esta patente. En vez de ello, el inventor ha contemplado que el asunto materia reclamado también podría ser incorporado de otras maneras, para que incluya pasos o combinaciones de pasos diferentes similares a aquellos descritos en este documento, en conjunto con otras tecnologías actuales o futuras. Además, aunque el término "paso" puede ser utilizado aquí para indicar elementos diferentes de métodos empleados, el término no debe de ser interpretado como que implica cualquier orden particular entre los diferentes pasos aquí descritos, a menos y excepto cuando el orden de pasos individuales está descrito de manera explícita. Finalmente, aunque la descripción siguiente puede enfocarse en algunos momentos hacia la arquitectura IA32 y/o la familia del procesador x86, no se pretende en parte alguna de la presente descripción estar limitado a estos subgrupos, y cualquiera de dichas explicaciones incluye expresamente todas las arquitecturas aplicables del procesador a las cuales pueden ser aplicadas y/o utilizadas las diferentes modalidades de la presente invención, incluyendo pero sin limitarse a, todas las arquitecturas de procesador x86 y sus equivalente, e incluyendo expresamente las arquitecturas IA32 e IA64 y sus equivalentes, extensiones y derivados. Microprocesadores de Computadora Un microprocesador es un procesador de computadora en un microchip. Está diseñado para realizar operaciones aritméticas y lógicas que utilizan áreas de detención de números pequeños denominadas registros. Las operaciones típicas del microprocesador incluyen la suma, resta, comparación de dos números, la recuperación de números de un área para otra área. Estas operaciones son el resultado de un conjunto de instrucciones que son parte del diseño del microprocesador. Una instrucción es una orden determinada para un procesador de computadora por un programa de computadora. En el nivel más bajo, cada instrucción es una secuencia de Os y 1s que describe una operación física que va a realizar la computadora (tal como "sumar"), y depende del tipo de instrucción particular, la especificación de las áreas de almacenamiento especiales denominadas registros que pueden contener los datos que van a ser utilizados para llevar a cabo la instrucción, o la localización en la memoria de datos de la computadora. Un registro es uno de un conjunto pequeño de lugares que guardan datos que son parte de un procesador de computadora. Un registro puede guardar una instrucción por computadora, una dirección de almacenamiento o cualquier tipo de datos (tal como una secuencia de bits o caracteres individuales). Algunas instrucciones especifican los registros como parte de la instrucción. Por ejemplo, una instrucción puede especificar el contenido de dos registros definidos sea agregado y luego colocado en un registro especificado. Un registro debe de ser lo suficientemente grande para guardar una instrucción (por ejemplo, en una computadora de instrucción de 32 bits, un registro debe de ser de una longitud de 32 bits. En algunos diseños de computadora, existen registros más pequeños - por ejemplo, medios registros - para instrucciones más cortas. Dependiendo del diseño del procesador y las reglas del lenguaje, los registros pueden ser numerados o tener nombres arbitrarios. Sin embargo, tal y como se usa en la presente descripción, los registros específicos, instrucciones específicas y otros elementos técnicos aquí descritos con especificidad, están basados en la arquitectura x86, y por lo tanto, como tales son ampliamente conocidos y bien entendidos para aquellos expertos en la técnica. Arquitectura de Máquina Virtual La figura 1 ilustra un sistema de cómputo virtualizado que comprende una capa de software del monitor de la máquina virtual (VMM) 104 que opera directamente arriba del hardware 102, y el VMM virtualiza todos los recursos de la máquina exponiendo las interfases que son iguales a las del equipo que el VMM está virtualizando (lo cual hace posible que el VMM opere sin ser notado por las capas del sistema operativo que operan arriba del mismo). Arriba del VMM 104 se encuentran dos implementaciones de la máquina virtual (VM) la VM A 108 la cual es un procesador Intel 386, virtualizado, y la VM B 110 la cual es una versión virtualizada de uno o más de la familia de procesadores Motorola 680X0.
Arriba de cada VM 108 y 110 se encuentran los sistemas operativos invitados A 112 y B 114, respectivamente. Arriba del invitado OS A 112 están operando dos aplicaciones, la aplicación A1 116 y la aplicación A2 118 y arriba del invitado OS B 114 se encuentra la aplicación B1 120. La figura 2 ilustra una similitud de entorno del sistema de cómputo virtualizado, pero que tiene un sistema operativo central (de origen) X 122 que hace interfase con el hardware de la computadora 102, y arriba del OS X 122 de origen está operando la aplicación X 124. La figura 3 es un diagrama de las capas lógicas del hardware de la arquitectura del hardware y el software para un entorno operativo emulado de un sistema de computadora 310. Un programa de emulación 314 opera en un sistema operativo invitado y/o una arquitectura de hardware 312. El programa de emulación 314 emula una arquitectura de hardware invitado 316, y un sistema operativo invitado 318. Algunas aplicaciones del software 320 operan a la vez en el sistema operativo invitado 319. En el entorno operativo emulado de la figura 3A, debido a la operación del programa de emulación 315, la aplicación del software 320 puede operar con el sistema de computadora 310 aunque la aplicación de software 320 está diseñada para operar en un sistema operativo que generalmente es incompatible con el sistema operativo invitado y la arquitectura del hardware 312. Virtualización del Procesador Existen dos métodos para proporcionar la virtualización del procesador en una máquina virtual (VM): la emulación y la ejecución directa. Las máquinas virtuales pueden utilizar cualquier método o ambos (uno "híbrido") para proporcionar la virtualización del procesador. La emulación comprende el uso de cualquiera de un interpretador o un mecanismo de traducción binaria y también es la única elección factible, cuando se implementa un VM en un sistema en donde los procesadores invitado y central son significantemente diferentes. Por ejemplo, el Microsoft Virtual PC para Macintosh implementa un VM basado en x86 (que emula una arquitectura de procesador x86) en un sistema Macintosh basado en PowerPC. La emulación también es necesaria para situaciones en donde los procesadores invitado y central son el mismo, pero en donde el procesador proporciona un soporte de virtualización inadecuado. Ciertos modos de operación de la arquitectura x86 se encuentran dentro de esta categoría. Sin embargo, aunque la emulación es el mecanismo de virtualización más flexible y compatible, generalmente no es el más rápido. La emulación por cualquier interpretación o traducción binaria impone un costo de tiempo de ejecución. En el caso de la interpretación, la cual es relativamente fácil de implementar, el costo con frecuencia es del orden de 90-95% (es decir, el funcionamiento resultante solamente será del 5 al 10% del funcionamiento "de origen"). Por otra parte, un mecanismo de traducción binaria es más completo que un interpretador, por lo tanto, más difícil de implementar, pero dicho mecanismo sufre menos pérdidas de funcionamiento y puede requerir un costo de solamente del 25 al 80% (es decir el funcionamiento resultante es del 20 al 75% del funcionamiento "de origen"). En general, la ejecución directa es más rápida y más eficiente que la emulación utilizando cualquier método. Se puede lograr una buena implementación de ejecución directa, dentro de solamente unos cuantos puntos porcentuales de diferencia, un funcionamiento que es equivalente al funcionamiento de origen. Sin embargo, tal y como es conocido y apreciado por aquellos expertos en la técnica, la ejecución directa generalmente depende de las facilidades de protección del procesador para evitar que el código virtualizado se "encargue" del sistema. Más específicamente, la ejecución directa depende del procesador para diferenciar entre el nivel del usuario y las operaciones del nivel privilegiado (es decir, el software que tiene acceso a los recursos del procesador del nivel privilegiado contra los recursos del nivel del usuario). El software que opera en la modalidad privilegiada, (es decir, el software de confianza) tiene la capacidad de acceder a los recursos privilegiados del procesador incluyendo registros, modalidades, ajustes, estructuras de datos en la memoria, y así sucesivamente. En contraste, la modalidad del usuario se pretende para un software que no es de confianza que realiza la mayor parte del trabajo de computación en un sistema moderno. Muchos procesadores (pero no todos) hacen una distinción estricta entre la condición del nivel del usuario y la condición del nivel privilegiado (correspondiendo a cada modalidad) y el acceso a la condición del nivel privilegiado no es permitido cuando el procesador está operando en la modalidad del usuario. Esta distinción permite que el sistema operativo invitado (o su equivalente) proteja los recursos clave y evite que una pieza errónea o maliciosa del software del nivel del usuario produzca una anomalía funcional en el sistema completo. Para la ejecución directa del código del nivel del usuario, cualesquiera violaciones del privilegio son atrapadas por el VMM y pasadas a los procesadores de gestión de excepción del invitado. No obstante, la ejecución directa del código del nivel privilegiado comprende la operación del código del nivel privilegiado en el nivel del usuario a pesar del hecho de que el código del nivel privilegiado está escrito bajo el supuesto de que tendrá un acceso directo a todos los elementos de condición privilegiada del procesador. Para conciliar esta inconsistencia, el VM depende del procesador para generar una interrupción interna del hardware para todas las instrucciones privilegiadas (es decir, instrucciones que tienen acceso directo o indirecto a la condición privilegiada). La interrupción interna del hardware a la violación del privilegio invoca un procesador de gestión de interrupción interno del hardware dentro del monitor de la máquina virtual (VMM). Entonces el procesador de gestión de la interrupción interna del hardware de los VMM, emula los cambios de condición implicados de la instrucción privilegiada y regresan al control de soporte para una instrucción posterior. Esta emulación de una instrucción privilegiada, con frecuencia comprende el uso de una condición de sombra que es privada para un caso particular de VM. Por ejemplo, si una arquitectura del procesador incluye un registro de modalidad privilegiada (PRM), al cual solamente se puede tener acceso en la modalidad privilegiada, cualquier intento para leer o escribir en el PRM desde el código del nivel del usuario ocasionaría una interrupción interna del hardware. El procesador de gestión de la interrupción interna del hardware de los VMM's determinaría la causa de la interrupción interna del hardware y se referiría a un valor de sombra PRM que es privado para el caso del VM asociado. (Este valor PRM puede ser diferente al valor que se mantiene actualmente en el PRM del procesador central). Dependiendo de la frecuencia de las instrucciones de elaboración de interrupción interna del hardware y el costo de los procesos de gestión de una interrupción interna del hardware, esta técnica puede imponer una penalidad de funcionamiento relativamente pequeño pero notable. Por ejemplo, algunos VMM's es desarrollado por IBM y Amdahl funcionaron de un 80 a 98% de la velocidad de origen, teniendo de este modo, una pérdida neta de funcionamiento del 2 al 15% de vida al costo de la elaboración de la interrupción interna del hardware. Limitaciones del x86/IA32 Un procesador idealizado pretendido para la virtualización se dice que puede ser estrictamente virtualizable- es decir, un procesador estrictamente virtualizable permite la implementacion de un mecanismo de virtualización de ejecución directa que cubre con los siguientes requerimientos: (a) El VMM debe de poder permanecer "en control" sobre los recursos del procesador y sistema. (b) El software que opera dentro del VM (ya sea al nivel del usuario o privilegiado) no debe de poder decir que está operando dentro de una máquina virtual. Para cumplir estos requerimientos, un procesador que se puede virtualizar estrictamente exhibe las siguientes Incorpora una unidad de administración de memoria (M U), o un mecanismo de traducción de dirección similar. Proporciona dos o más niveles de privilegio. Divide todas las condiciones del procesador, ya sea en condición privilegiada, condición del usuario y la condición privilegiada debe de incluir cualesquiera campos de control o condición que indiquen el nivel de privilegio actual. Ocasiona una interrupción interna del hardware cuando se intenta en el nivel del usuario cualquier acceso a la condición privilegiada (ya sea lectura o escritura). Tiene los medios para originar opcionalmente una interrupción interna del hardware, cuando un código de niveles del usuario intenta tener acceso a la condición no privilegiada que debe de ser virtualizada (es decir, los valores de cronómetro, contadores de funcionamiento y registros de características del procesador). Todas las estructuras del procesador en la memoria son, ya sea almacenadas fuera del espacio de dirección actual o poderse proteger de accesos erróneos o maliciosos a la memoria dentro del VM.
• Cualquier condición del procesador en el momento de una interrupción o interrupción interna del hardware puede ser restaurada a su condición previa la interrupción interna del hardware después de que es manejada la interrupción o interrupción interna del hardware. Varios procesadores modernos - incluyendo los procesadores PowerPC y DEC Alpha, para nombrar unos cuantos - cumplen con estos requerimientos. Sin embargo, el IA32 no lo hace - solamente cumple con los primeros dos requerimientos. Por lo tanto, la arquitectura IA32 contiene muchos agujeros de virtualización que presentan un número de desafíos para una implementación de VMM. Primero, la arquitectura IA32 viola el requerimiento de la separación de la condición del usuario/privilegiada en varios casos, el más importante de ellos incluye el registro EFLAGS que contiene, tanto la condición del usuario como la privilegiada, tal como se ilustra en la figura 4. Los siguientes campos EFLAGS deben de ser considerados privilegiados: VIP, VIF, VM, IOPL y IF. (todos los otros campos representan la condición del usuario y no necesitan ser privilegiados). Sin embargo, para el IA32, las instrucciones que leen y escriben los campos privilegiados del registro EFLAGS (incluyendo los campos PUSHF/PUSHFD, POPF/POPFD y IRET) no ocasionan interrupciones internas del hardware cuando son ejecutados desde la modalidad del usuario, y no tienen medios en el IA32 para forzar que estas instrucciones ocasionen la interrupción interna del hardware. Además, en el IA32, las instrucciones PUSHF y POPF con frecuencia son utilizadas dentro de un código de Kernel invitado (anillo 0), para guardar y restaurar la condición para el IF (señalización que hace posible la interrupción). Dentro de una máquina virtual, este código Kernel es ejecutado en un nivel de anillo más alto (por ejemplo, en el anillo 1) y el IOPL es ajustado de modo que atrapa las instrucciones. Debido a que el sistema operativo (OS) que opera dentro del VM no se le debe permitir inhabilitar las interrupciones en el procesador invitado, el valor IF real es ajustado a 1 mientras que el código de la máquina virtual está operando, independientemente de la condición del IF virtual. Por consiguiente, la instrucción PUSHF siempre impulsa un valor EFLAGS con IF=1, y la instrucción POPF siempre ignora el campo IF del valor EFLAGS impulsado. Además, del registro EFLAGS, son mezcladas dos áreas de adicionales en donde las condiciones privilegiadas y del usuario están en los registros CS y SS. Los dos bits inferiores de estos registros contienen un nivel de privilegio actual (CPL) lo cual es una condición privilegiada, mientras que los catorce bits superiores de estos registros contienen un índice de segmento y un selector de la tabla del descriptor los cuales no son privilegiados. Las instrucciones que tienen acceso implícita y explícitamente en el selector CS o SS (incluyendo las instrucciones CALLF, MOV del SS y PUSH SS) no tienen interrupciones internas del hardware cuando son ejecutadas desde la modalidad del usuario. Observar que otras instrucciones ocasionan que el CS ó SS sean impulsados a la memoria de almacenamiento temporal (por ejemplo, INT, INTO, JMPF a través del regulador de llamada, CALLF, a través del regulador de llamada), pero estas instrucciones pueden ocasionar una interrupción interna del hardware, permitiendo que el VMM virtualice el valor CPL impulsado. Las faltas de adecuación adicionales del modelo de protección x86/IA32 que permiten el código de nivel del usuario tenga acceso directo a la condición privilegiada del procesador, incluyen las siguientes instrucciones: SGDT, SIDT, SLDT, SMSW y STR. Por una variedad de razones, el sombreado de GDT, LDT, IDT y TR es necesario para corregir la virtualización, lo cual significa que el TR, GDTR e IDTR señalarán a las tablas sombreadas de los VMM's, no a la tabla especificada por el sistema operativo invitado. Sin embargo, debido a que el código no privilegiado puede leer de estos registros, no es posible virtualizar correctamente su contenido. Además, varias instrucciones que tienen acceso a los descriptores dentro del GDT y el LDT, no ocasionan interrupciones internas del hardware cuando son ejecutadas desde la condición no privilegiada, incluyendo los LAR, LSL, VERR y VERW. Debido a que es necesario el sombreado GDT/LDT, estas cuatro instrucciones pueden ejecutarse incorrectamente dentro de un VM. Además, la instrucción CPUID no efectúa la interrupción interna del hardware. Con el objeto de simular nuevas características del procesador o deshabilitar las características del procesador dentro de la máquina virtual, es importante poder ocasionar interrupciones internas del hardware en el CPUID cuando es ejecutado desde la modalidad no privilegiada. Además, la conmutación de contexto en un entorno VM depende de la capacidad para guardar y restaurar la condición completa del procesador, pero la arquitectura IA32 no lo permite. Más específicamente, la condición del descriptor del segmento guardado en la memoria instantánea para cada uno de los seis segmentos (DS, ES, CS, SS, FS y GS) es almacenada internas al procesador al momento de que se vuelve a cargar el segmento, a esta información no se puede tener acceso a través de cualquier mecanismo definido de manera arquitectónica. Por consiguiente, este es un obstáculo importante para la virtualización correcta. Por ejemplo, si una pieza de código carga un segmento y luego modifica el descriptor en la memoria correspondiente a ese segmento, un cambio de contexto subsecuente no podrá restaurar correctamente el descriptor de la información del descriptor del segmento original. De un modo similar, si el procesador está operando en un modo real, entonces cambia a la modalidad protegida, los segmentos contendrán selectores que no corresponden a los descriptores dentro de la modalidad GDT/LDT protegida y un cambio de contexto en este punto, no podría restaurar correctamente los descriptores guardados en la memoria instantánea que fueron cargados originalmente dentro del modo real. De un modo similar, la instrucción PAUSE (una forma de prefijo de NOP) la cual fue agregada recientemente para proporcionar sugerencias a los procesadores hiper-roscados, acerca de la ejecución del cierre del ciclo), incurre en problemas de funcionamiento cuando es utilizado con cierres del ciclo en un procesador múltiple (MP) VM. Por ejemplo, un procesador virtual puede girar en un ciclo que es sostenido por un segundo procesador virtual y si el segundo procesador virtual está operando en un ciclo que no está ejecutando actualmente el primer procesador virtual, puede girar por un período de tiempo largo y desperdiciar así como resultado los ciclos del procesador. Esto sería útil sí el monitor de la máquina virtual pudiera ser notificado, si un VM está girando - con el objeto de permitir que el VMM programe otro VM para operar o señalizar un segundo ciclo del procesador virtual que va a ser programado -actualmente no está disponible dicho método de notificación. Ciertos entornos de VM utilizan varias técnicas diferentes para resolver estas desventajas y generalmente emplean, tanto la emulación como la ejecución directa de una manera híbrida. Dichas técnicas específicas son seleccionadas basadas en las modalidades del procesador y otra información derivada del OS mismo. Para dichos sistemas, generalmente existen cuatro categorizaciones de modalidades del procesador diferentes conocidas por el VMM, tal como se muestra en la figura 5. Es posible - y deseable -sobrecontrolar el comportamiento por omisión (default) en el caso de la modalidad del anillo 0 (la cual es utilizada para la mayor parte de los códigos del nivel de Kernel del OS moderno). Mucho de la descripción siguiente explica los requerimientos para ejecutar de una manera segura todos los códigos del anillo O, a través de un mecanismo de ejecución directo. Muchos entornos de VM utilizan una técnica denominada "compresión del anillo" (utilizada primero por los ingenieros de DEC para virtualizar la arquitectura VAX). La compresión del anillo comprende la ejecución del anillo 0 dentro de un anillo menos privilegiado (por ejemplo, el anillo 1) con el objeto de permitir que la VMM atrape ciertas instrucciones del nivel privilegiado que tienen acceso a los recursos virtualizados. Por ejemplo, el señalizador básico de la tabla de página IA32 es almacenado dentro del registro CR3. La instrucción que lee el CR3 solamente es ejecutable dentro del anillo 0. Cuando es ejecutada desde el anillo 1, esta instrucción ocasiona que el procesador genere una interrupción interna del hardware (específicamente, un tipo 8 de excepción de "operación ilegal"). Al momento en que se ha generado una interrupción interna del hardware, el VMM gana control y emula la instrucción, regresando el CR3 virtualizado (de los procesadores invitados) en vez del CR3 del VMM (del procesador central). Para la mayor parte, el VMM puede ocultar el hecho de que el código pretendido para ser operador en el anillo 0 está operando realmente dentro de un nivel de anillo diferente. En el ejemplo anterior, el código que tiene acceso al CR3 no estaba advertido del hecho de que había ocurrido una interrupción interna del hardware debido a que fueron emulados todos los cambios de condición importantes asociados con la instrucción. Sin embargo, estas desventajas de la virtualización del IA32 evitan que la compresión del anillo sea completamente opaca. Las instrucciones ilustradas en la figura 6 exponen el hecho de que el código del anillo 0 está operando en un nivel del anillo más alto y el código que utiliza estas instrucciones es problemático y generalmente inseguro para operar dentro de un entorno de ejecución directa.
Además, la arquitectura IA32 incluye tanto una tabla del descriptor global como local (GDT y LDT, respectivamente). Esta tabla incluye segmentos del código y datos, así como reguladores que controlan las transiciones entre los anillos. El OS invitado puede preparar su GDT ó LDT para permitir las transiciones entre el anillo 3 y el anillo 0. Sin embargo, el VMM puede permitir cualquier transición directamente al anillo 0, debido a que daría el control directo del OS invitado sobre el procesador central. En vez de ello, el VMM debe de estar comprendido en cualquier transición para el anillo 0 de modo de que pueda dirigir nuevamente de manera correcta la ejecución a un nivel de anillo privilegiado más bajo. Esto significa que el VMM no puede utilizar directamente el GDT y el LDT del invitado. En vez de ello, debe de sombrear el contenido del GDT y el LDT del invitado en las tablas privadas, haciendo los ajustes que sean necesarios para evitar cualesquiera transiciones directas al anillo 0. Estos ajustes están limitados al campo DPL (nivel de privilegio del descriptor) y el bit de código del campo del tipo de descriptor. Debido a estas modificaciones menores, las tablas del descriptor sombreadas pueden diferir ligeramente de las tablas del descriptor del invitado. En la mayoría de los casos, estas diferencias no son visibles para el software; sin embargo, existen varias instrucciones en la arquitectura IA32, ilustrada en la figura 7, que exponen esta diferencia. Por ejemplo, el VMM escribe páginas de protección que traslapan el GDT y el LDT invitado de modo que cualquier intento para modificar estas tablas dará como resultado una falla de protección en la escritura dentro del VMM. En respuesta, el VMM asegura que el cambio al GDT ó LDT invitado sea reflejado en sus tablas sombreadas internas. Sin embargo, cuando son modificadas las entradas al GDT ó LDT correspondientes a un selector cargado actualmente, no es reversible una modificación a los descriptores de memoria correspondientes debido a que la arquitectura IA32 no proporciona un medio para leer los descriptores del segmento cargados actualmente. En esta situación, el VMM debe de depender de la emulación antes de permitir que sea modificado el descriptor en la memoria. Un aspecto particularmente problemático de la virtualización del IA32 comprende el IF (señalización de ocultamiento de interrupción) en el registro EFLAGS debido a que, mientras esta condición debe de ser claramente privilegiada, se puede leer fácilmente por un código no privilegiado. Además, los intentos para modificar el IF desde dentro del código no privilegiado simplemente son ignorados en vez de generar una interrupción interna del hardware - en otras palabras, mientras es posible atrapar algunas instrucciones que manipulan el IF (incluyendo la STI y la CLI), otras instrucciones que tienen acceso al IF no se pueden atrapar. Otras instrucciones que tampoco se pueden atrapar (pero que deben de estar desde una perspectiva de la virtualización) están ilustradas en la figura 8. Desafortunadamente, aunque el código está ejecutando desde una máquina virtual, no es posible tener una imagen de espejo del IF real en un IF virtualizado, debido a que esto permitiría que el OS invitado desconectara las interrupciones indefinidamente, es decir, sería posible que un OS invitado erróneo se colgara del sistema central completo. Por esta razón, el IF invitado se deja deshabilitado en todo momento (por ejemplo, las interrupciones no son ocultadas), cuando el código invitado está siendo ejecutado, aún cuando está anulado el IF virtualizado (invitado). De un modo similar, para la interrupción interna del hardwaretrapar se requiere el ajuste de las instrucciones STI/CLI del campo IOPL de las EFLAGS, siendo el IOPL todavía otro ejemplo del campo privilegiado que es fácilmente expuesto a un código no privilegiado con desventajas similares a las asociadas con el IF. Las instrucciones problemáticas que pertenecen a los campos IF e IOPL se ilustran en la figura 9. La arquitectura IA32 también define ciertas estructuras de datos que son utilizadas por el procesador, incluyendo las estructuras TSS, GDT, LDT e IDT y estas estructuras de datos están localizadas dentro del espacio de dirección lógica definido por las tablas de página. Cuando un OS invitado está operando dentro de una máquina virtual, sus tablas de páginas definen cuales áreas del espacio de dirección son utilizadas para elaborar el mapa de la memoria, las memorias intermedias del cuadro, los registros trazados en mapas de la memoria, etc. Aunque invariablemente, se deja sin usar alguna porción del espacio de dirección. Aunque el OS invitado mantiene sus propias estructuras TSS, GDT, LDT e IDT, el VMM proporciona sus propias versiones privadas de estas estructuras de datos. Sin embargo, estas estructuras deben de ser trazadas en mapas en algún lugar dentro del espacio de dirección que es controlado por la OS invitada. Los códigos del VMM y las estructuras de datos internos también deben de ser elaborados en mapas dentro del mismo espacio de dirección. Por consiguiente, el VMM necesita encontrar alguna porción (relativamente pequeña) del espacio de dirección que no esté en uso actualmente por la OS invitada. A esta área nos referimos como el "área de ejecución del VMM". El VMM monitorea activamente las tablas de página del OS invitado para determinar si el OS invitado está intentando elaborar mapas de las páginas en el área ocupada actualmente por el área de ejecución del VMM. Si es así, el VMM encuentra otra porción sin usar del espacio de dirección y él mismo se vuelve a colocar. Esta técnica permite una compatibilidad amplia del OS invitado, pero es problemática cuando está siendo utilizado el espacio de dirección completo del invitado, lo cual puede ocurrir cuando están asignadas cantidades grandes de la memoria física a la máquina virtual. Por esta razón, el VMM proporciona un mecanismo por medio del cual el OS invitado puede reservar una porción de su espacio de dirección específicamente para el área de funcionamiento del VMM. Una vez que este espacio es especificado, el VMM se coloca de nuevo él mismo en este espacio y detiene los cambios que rastrean activamente las tablas de páginas (bajo el supuesto de que el OS invitado continúa cumpliendo su promesa de ya no utilizar el área reservada). Las instrucciones para las interrupciones interna del hardware son una ventaja mixta. Por una parte, si se atrapa una instrucción ésta puede ser virtualizada correctamente. Por la otra, la interrupción interna del hardware impone un costo del funcionamiento muy grande. Por ejemplo, una instrucción STI generalmente requiere un ciclo para ejecutarse, pero cuando un SPI es ejecutado dentro de un entorno VM, que ocasiona una interrupción interna del hardware que es procesada por el VMM, la cual en un procesador Pentium 4, con frecuencia requiere más de 500 ciclos para ejecutarse. Ciertos VMs han intentado mitigar este costo rastreando las instrucciones de interrupción interna del hardware de alta frecuencia y, donde es posible, conectándolas con códigos equivalentes que conservan la semántica de la instrucción original dentro del entorno virtualizado para que no se originen las interrupciones internas del hardware. Esto se hace a través del uso de una "memoria intermedia de conexión" que no se puede paginar asignada dentro del espacio kernel de la OS invitada. Sin embargo, durante la operación, la instrucción de interrupción interna del hardware que se puede conectar requiere por lo menos cinco bytes de longitud para permitir una instrucción JMP larga -- sin este requisito de cinco bytes, la VMM necesitaría sobre-escribir la instrucción o instrucciones que siguen la instrucción del tratamiento debido a que la instrucción que va a ser conectada puede tener una longitud menor de 5 bytes. Virtualización Mejorada (por ejemplo, IA32). Muchas de las desventajas y limitaciones anteriores de la arquitectura IA32 son el resultado de instrucciones que fallan para ocasionar una interrupción interna del hardware cuando se desea. En otras palabras, si estas instrucciones en vez de fallar, ocasionaran una interrupción interna del hardware, el VMM podría emular correctamente estas instrucciones. La presente invención proporciona varias modalidades para crear efectivamente las interrupciones internas del hardware para estas instrucciones problemáticas. Varias modalidades de la presente invención se relacionan con la mejora de la virtualización en una arquitectura IA32 optimizando el código OS y utilizando "instrucciones sintéticas" (que se explicarán detalladamente más adelante). Varias modalidades de la presente invención comprenden una serie de pasos, ilustrados en la figura 10, para optimizar un OS invitado de la manera siguiente: • En el OS invitado, encontrar y remover y/o reemplazar cualquier uso de las instrucciones PUSH CS, PUSH SS, MOV del SS ó CALLF dentro del código de anillo 0. Como se explicó anteriormente, estas instrucciones exponen el hecho de que el código de anillo 0 que opera dentro de la máquina virtual, realmente está operando en un nivel de anillo de privilegio más bajo. Sin embargo, estas instrucciones son muy raras en la mayoría de los sistemas operativos y generalmente pueden ser, ya sea eliminadas todas, o reemplazadas por otras instrucciones existentes o grupos de instrucciones existentes. • En la OS invitada, encontrar y utilizar las instrucciones VERR, VERW ó LAR y verificar que su uso no dependa del DPL o el bit de código del tipo del descriptor. Una vez más, estas instrucciones no son utilizadas en la mayor parte de los OSs. • En la OS invitada, encontrar cualquier uso de las instrucciones SGDT, SLDT, SIDT ó STR y eliminar estas instrucciones o reemplazarlas por las instrucciones VM sintéticas correspondientes. Para implementar este paso, se reemplaza una entrada a la tabla del descriptor por una instrucción sintética en el sistema operativo invitado (por ejemplo, VMWRDESC), que actualiza la entrada de la tabla del descriptor, evitando costos asociados con el mantenimiento de las tablas del descriptor sombreadas. En la OS invitada, encontrar y utilizar el campo CPUID -- es decir, cuando se tiene acceso en el OS por medio de una subrutina común que utilizan todas las porciones del sistema para acceder a la información del CPUID -- y modificar la subrutina común que lee el CPUID para utilizar una instrucción sintética para tener acceso a la información CPUID virtualizada, en vez de leer la CPUID directamente. Aunque la virtualización de la CPUID no es necesaria en la medida que la información específica de la CPUID regresada por el procesador central no esté en conflicto con las características del invitado, si fuera a implementar un nuevo procesador una característica que no proporciona soporte para el VMM, entonces un valor del CPUID virtualizado indicaría que la característica no estaba presente, aunque el valor CPUID no virtualizado indicaría que si estaba. En la OS invitada, localizar cualesquiera cierres del ciclo MP y modificarlos para utilizar una instrucción sintética VMSPLAF (falló la adquisición del cierre del ciclo). En la OS invitada, encontrar cualesquiera casos de PUSHF(D) y POPF (D) y, si el uso de estas instrucciones depende del valor del IF que está siendo empujado o rebotado, reemplazarlos por una instrucción sintética correspondiente. Este paso generalmente representa la mayor parte del trabajo comprendido para hacer un "VM limpio" de la OS. En la OS invitada, identificar las localizaciones en donde son modificadas las entradas al GDT o LTD y reducir a un mínimo el número de modificaciones y luego reemplazar las modificaciones restantes por una instrucción sintética VMWRDESC. (Se debe de ser especialmente cuidadoso para evitar una situación en donde es modificado el selector cargado actualmente). En la OS invitada, asegurarse de que todos los GDT y LTD estén localizados en las páginas que no contienen otras estructuras de datos, y si no es así, hacerlo de este modo. En la OS invitada, localizar los casos de las instrucciones STI y LTD dentro del código de anillo 0 y reemplazarlas por las instrucciones sintéticas correspondientes que son de una longitud de cinco bytes. Utilizando las formas sintéticas, el VMM podrá conectar mejor el código para reducir la necesidad de interrupciones internas del hardware, ya que se están conectando directamente las instrucciones STI y CLI, las cuales tienen cada una una longitud menor de cinco bytes y que requieren que el VMM sobre-escriba la instrucción o instrucciones que siguen las instrucciones para la interrupción interna del hardware debido al hecho de que una instrucción típica interrupción interna del hardware que se puede conectar requiere por lo menos una longitud de cinco bytes para permitir una instrucción JMP larga. Utilizar la instrucción sintética VMSETINFO tal y como se documenta más adelante. Las nueve instrucciones anteriores completaron la "limpieza del VM" de modo que esta instrucción sintética puede habilitar la ejecución directa dentro del anillo 0. Deshabilitar dinámicamente la ejecución directa, y volver a habilitarla después de cinco bloques grandes de códigos del anillo 0 que permanecen en "VM inseguro". Proporcionando una instrucción sintética para el sistema operativo invitado para deshabilitar dinámicamente (por ejemplo, V DXDSBL) y volver a habilitar la ejecución directa (VMDXENBL) — el sistema operativo invitado puede evitar varios códigos grandes de "VM inseguro" del código del anillo 0. Asegurarse de que el VMM puede utilizar una "memoria intermedia de parches" y de ser así, asignar una memoria intermedia de parches dentro del espacio kernel para el mejor funcionamiento. Esta memoria intermedia de parches no se debe de paginar, ni ser trazada en mapas en todos los contextos del espacio de dirección en donde es ejecutado el código del anillo 0 y debe de ser de un tamaño indicado por la instrucción sintética VMGETINFO. La localización y tamaño de la memoria intermedia de la conexión puede ser ajustado utilizando la instrucción VMSETINFO, tal y como se documentará más adelante. La memoria intermedia de parche debe de ser asignada una vez para el sistema completo, y no por cada procesador virtual. Determinar si la VMM requiere una "área de ejecución de la VMM", y de ser así, asignar y reservar el espacio de dirección del tamaño y alineación indicados dentro de la OS invitada.
Ajustar la base de esta área reservada a través del uso de la instrucción VMSETINFO, tal y como se explicará más adelante. Las "instrucciones sintéticas" VM son de otro modo instrucciones ilegales del procesador que tienen significados especiales para el VM. Como tales, cuando son ejecutadas las instrucciones sintéticas dentro de una VM que no soporta instrucciones sintéticas o en un entorno que no es de VM, ellas generan una excepción del tipo-6 (operación ilegal) y por lo tanto, es importante para la OS verificar el soporte de la instrucción sintética antes de utilizarla. Para verificar el soporte de instrucción sintética VM, la OS ejecuta una instrucción VMCPUID y si esta instrucción genera una falla de instrucción ilegal, la OS ha determinado que no son soportadas las instrucciones sintéticas. (Observar que la VMCPUID puede ser ejecutada desde todos los niveles de privilegio, de modo que sea segura para utilizarla en los códigos del nivel del usuario). Se puede utilizar la misma prueba para determinar si se está ejecutando dentro de un entorno VM, y de ser así, permitir posteriormente que la máquina virtual tenga acceso o modifique las características o comportamientos de la VMM subyacente. El siguiente es un código de ejemplo que utiliza un mecanismo de tratar/exceptuar y un proceso de excepción estructurado para realizar dicha prueba: BOOL SyntheticlnstructionsSupported() { Boolean synthlnstrSupported = TRUE; -try { _asm { _emit OxOF // Emit VMCPUID instruction _emit 0xC7 _emit 0xC8 _emit 0x01 _emit 0x00 } }_except(EXCEPTION_EXECUTE_HANDLER) { synthlnstrSupported = FALSE; } return synthlnstrSupported;
}
Usando las instrucciones sintéticas, una instrucción x86
ISA que afecta de manera adversa la virtualización en un procesador x86 puede ser reemplazada de este modo o suplementada por una instrucción sintética que ocasiona una excepción en el procesador x86 y luego es atrapada por una máquina virtual que opera en dicho procesador x86 para el procesamiento por parte de la máquina virtual. De un modo similar, para la virtualización recursiva, en donde una primera máquina virtual está operando en una segunda máquina virtual, una instrucción que es, ya sea reemplazada o suplementada por instrucciones sintéticas para ocasionar una excepción en el procesador x86 puede ser pasada a través de la segunda máquina virtual para ser atrapada por dicha primera máquina virtual para el procesamiento. Para varias modalidades de la presente invención, las instrucciones sintéticas todas son de una longitud de cinco bytes, permitiendo que sean conectadas con una instrucción JMP para reducir el costo de la interrupción interna del hardware. (En otras modalidades, las instrucciones sintéticas pueden ser de una longitud mayor o más cortas). La codificación hexadecimal para las instrucciones sintéticas utiliza el siguiente formato: 0F C7 C8 XX XX (en donde "XX" son variables hexadecimales de dos dígitos para identificar instrucciones sintéticas específicas). Esta instrucción descodifica una instrucción CMPXCHG8B pero se considera "ilegal" debido a que el operando en el destino especificado es un registro (y por lo tanto, da como resultado una interrupción interna del hardware). Sin embargo, en varias modalidades de la presente invención, las instrucciones sintéticas no soportan forma alguna de prefijos de instrucción (por ejemplo, LOCK, REP, sobrecontroles de los segmentos, sobrecontrol del tamaño del operando, sobrecontrol del tamaño de la dirección) e intentan utilizar prefijos en dichas modalidades que darán como resultado una instrucción de inspección ilegal (UD#). Instrucciones Sintéticas A continuación se describen con mayor detalle un subconjunto de instrucciones sintéticas para diferentes modalidades de la presente invención. Las instrucciones sintéticas adicionales que no se encuentran en esta lista, también han sido descritas anteriormente en el presente documento. También, las instrucciones sintéticas adicionales que no han sido descritas explícitamente en este documento de todas maneras han sido anticipadas por las diferentes modalidades de la presente invención, y nada de lo aquí descrito deberá ser tomado como que limita la invención a las instrucciones sintéticas específicas identificadas de manera explícita. VMGETINFO - Obtener Información del VM La instrucción VMGETINFO recupera una pieza específica de la información VM y la coloca dentro de la EDX.EAX. La información regresada depende del índice en el ECX. Si el índice especificado se refiere a una pieza de información que no es soportada por el procesador virtual, se genera un GP(0). Si el índice se refiere a una pieza de información soportada, el EDX:EAX es ajustado al valor de la información. (Observar que la convención de registro utilizada para esta instrucción es similar a la instrucción RDMSR). Esta instrucción difiere de la mayor parte de las instrucciones del procesador, debido a que afecta la condición del sistema completo. En sistemas con procesadores múltiples, una condición a la que se ha tenido acceso son con la instrucción VMGETINFO es considerada "global". Por ejemplo, el ajuste de la Base de Área de Ejecución del VMM, que utiliza la instrucción VMSETINFO en un procesador permite que el mismo valor se vuelva a leer entonces utilizando la instrucción VMGETINFO en un segundo procesador. VMSETINFO - Ajuste de la Información VM La instrucción VMSETINFO ajusta una pieza específica de información VM, tal y como es especificada en EDX:EAX. La información que va a ser ajustada depende del índice del ECX. Si el índice especificado se refiere a una pieza de información que no está soportada por el procesador virtual o que no se puede escribir, se genera un GP(0). (Observar que la convención de registro utilizada para está instrucción es similar a la instrucción WRMSR). Esta instrucción difiere de la mayor parte de las instrucciones del procesador, debido a que afecta la condición del sistema completo. En sistemas con procesadores múltiples, el ajuste de la condición con la instrucción VMSETINFO es considerada "global". Por ejemplo, el ajuste del Base de Área de Ejecución VMM utilizando la instrucción VMSETINFO en un procesador, hace posible que entonces se vuelvan a leer los datos utilizando la instrucción VMGETINFO en un segundo procesador. VMDXDSBL - Deshabilitar la Ejecución Directa. La instrucción VMDXDSBL deshabilita la ejecución directa hasta la siguiente vez en que la ejecución directa es habilitada a través del uso de la instrucción VMDXENBL. Esta instrucción solamente puede ser ejecutada desde el código del anillo 0 y solamente debe de ser ejecutada cuando las interrupciones (o cualquier forma de adquisición) es deshabilitada para evitar que la ejecución directa sea deshabilitada por períodos de tiempos largos. Puede ser utilizada para proteger bloques de códigos pequeños que no son "VM seguros" (por ejemplo, contiene un número de instrucciones o supuestos que no se pueden virtualizar que se interrumpen cuando se opera en la ejecución directa dentro de un entorno VM). Estas instrucciones solamente afectan al procesador en el cual son ejecutadas. No afecta otros procesadores virtuales de la máquina virtual. VMDXENBL - Habilitación de la Ejecución Directa La instrucción VMDXENBL habilita la ejecución directa en donde es posible. Esta instrucción solamente puede ser ejecutada desde dentro del código de anillo 0 y solamente debe de ser ejecutada cuando están deshabilitadas las interrupciones (o cualquier forma de adquisición). Puede ser utilizada en conjunto con la instrucción VMDXDSBL para proteger bloques pequeños de códigos que no son "VM seguros" (por ejemplo, que contienen un número de instrucciones o supuestos que no se pueden virtualizar que se interrumpen cuando se opera la ejecución directa dentro de un entorno VM). Esta instrucción solamente afecta al procesador en el cual es ejecutada. No afecta otros procesadores virtuales en la máquina virtual. Si ya ha sido habilitada una ejecución directa, esta instrucción no hace nada. VMCPUID - Información Virtualizada del CPU. La instrucción VMCPUID es similar a la instrucción CPUID real, excepto que regresa la información sombreada del CPU. VMHLT - Interrupción La instrucción VMHLT es similar a la instrucción HLT normal, excepto que puede ser ejecutada desde cualquier modo del procesador. Incluyendo el modo del anillo 3 y el v86. Puede ser insertada dentro de cualquier "circuito inactivo" para reducir la utilización del procesador dentro de la máquina virtual. En ciertas modalidades, esta instrucción sintética para detener el procesador (por ejemplo, VMHALT) puede ser ejecutada como un código invitado del nivel del usuario. VMSPLAF - Falla en la Adquisición del Cierre del Ciclo.
Los cierres del ciclo son utilizados con frecuencia dentro del sistema operativo para soportar el multiprocesamiento simétrico. Estos cierres generalmente protegen un recurso crítico que es compartido entre los procesadores. Dependen del hecho de que el cierre será sostenido por relativamente pocos ciclos por otro procesador. Dentro de un sistema VM de procesadores múltiples, el comportamiento típico del cierre del ciclo da como resultado un funcionamiento deficiente y una alta utilización del CPU, si el procesador virtual que sostiene el cierre del ciclo ha sido previamente vaciado temporalmente y no está operando mientras que otros procesadores virtuales esperan un recurso sostenido por el procesador suspendido. Para evitar esta situación, se puede utilizar la instrucción VMSPLAF para notificar al VMM que el OS está esperando un cierre del ciclo que se ha fallado en adquirir. En respuesta, el VMM ya sea que puede programar otro procesador virtual para operar o suspender el procesador virtual actual o programarlo para una ejecución posterior en un momento cuando el recurso haya sido liberado. VMPUSHFD - Registro de impulso de señalizaciones virtualizadas La instrucción VMPUSHFD es similar a la instrucción PUSHFD normal, excepto que es una "VM segura". Asume ambos un tamaño de 32 bits, y un señalizador de memoria de almacenamiento temporal de 32 bits. Si el CS y el SS no son actualmente de 32 bits, su comportamiento es indefinido. Tampoco está garantizado realizar el enlace de segmento o verificaciones de escritura del mismo de modo en que lo haría una instrucción PUSHFD real. El valor del registro EFLAGS impulsado en la memoria de almacenamiento temporal contendrá el valor IF sombreado. Sin embargo, el valor del campo IOPL puede no ser correcto. El código que requiere la lectura del IOPL debe de utilizar el valor del EFLAGS impulsado en la memoria de almacenamiento temporal en respuesta a una instrucción INT, una interrupción o excepción externa. Esta instrucción solamente puede ser utilizada dentro del código del anillo 0. VMPOPFD - Registro de señalizaciones emergentes virtualizadas La instrucción VMPOPFD es similar a la instrucción POPFD normal, excepto que es un "VM seguro". Asume tanto el tamaño del operando de 32 bits, como un señalizador de la memoria de almacenamiento temporal de 32 bits. Si el CS y el SS no son actualmente de 32 bits, su comportamiento es indefinido. Tampoco garantiza realizar los enlaces de segmento o las revisiones de escritura del mismo modo en que lo haría una instrucción PUSHFD real. El valor del campo IF dentro de las EFLAGS emergentes será cumplido. Sin embargo, el valor del campo IOPL puede ser ignorado. El código que requiere el ajuste del IOPL debe utilizar las instrucciones IRETD ó VMIRETD. Esta instrucción solo puede ser utilizada dentro del código del anillo 0. VMCLI - Anulación de la Señalización de Interrupción La instrucción VMCLI es similar a la instrucción CLI normal, excepto que tiene una longitud de cinco bytes y puede ser conectada para evitar ser atrapada dentro del VMM. Esta instrucción solamente puede ser utilizada dentro del código del anillo 0. VMSTI - Ajuste de la Señalización de Interrupción La instrucción VMSTI es similar a la instrucción STI normal, excepto que tiene una longitud de cinco bytes y puede ser conectada para evitar ser atrapada dentro del VMM. También difiere de la STI normal en que no evita que ocurra una interrupción antes de que sea completada la siguiente instrucción. La única excepción a esta regla, es que si es seguido el VMSTI por la instrucción SYSEXIT, entonces es ejecutada atómicamente junto con la VMSTI. Esta instrucción solamente puede ser utilizada dentro del código del anillo 0. VMIRETD - Regreso de la Interrupción La instrucción VMIRETD es similar a la instrucción IRETD normal, excepto que es una "VM segura". A diferencia de la instrucción IRETD normal, esta instrucción siempre asume un tamaño de operando de 32 bits, y un señalizador de la memoria de almacenamiento temporal de 32 bits. Su comportamiento es indefinido, si el tamaño actual del CS y el SS no es de 32 bits. Esta instrucción solamente puede ser utilizada dentro del código del anillo 0. Deberá ser utilizada siempre que la instrucción IRETD sea utilizada potencialmente para regresar a la modalidad v86. El uso de la instrucción VMIRETD evita un comportamiento desafortunado de un procesador IA32 cuando regresa de una CPL > 0a la modalidad v86. (Observar que la compresión del anillo da como resultado un código de anillo 0 que opera dentro del entorno VM en un nivel de anillo menos privilegiado). VMSGDT - Almacenamiento de la Tabla del Descriptor Global
La instrucción VMSGDT es similar a la instrucción SGDT real, excepto en que almacena la base y la longitud GDT sombreada. Asume que la modalidad de dirección para el operando de la memoria es DS:[EAX] y que el DS es un segmento amplio abierto que se puede escribir. Si el DS no es un segmento amplio abierto que se puede escribir, su comportamiento es indefinido. VMSIDT - Almacenamiento de la Tabla del Descriptor de I nterrupción La instrucción VMSIDT es similar a la instrucción SIDT real, excepto que almacena la base y la longitud IDT sombreadas. Asume que la modalidad de dirección para el operando de memoria es DS:[EAX] y que el DS es un segmento amplio abierto que se puede escribir. Si el DS no es un segmento amplio abierto que se puede escribir, su comportamiento es indefinido. VMSLDT - Almacenamiento de la Tabla del Descriptor Local La instrucción VMSLDT es similar a la instrucción SLDT real, excepto que almacena el selector LDT sombreado. Asume que el operando de destino es el registro EAX. VMSTR - Almacenamiento del Registro de Tarea La instrucción VMSTR es similar a la instrucción STR real, excepto en que almacena el selector LDT sombreado. Asume que el operando de destino es el registro EAX. VMSDTE - Almacenamiento en la Entrada de la Tabla del Descriptor La instrucción VMSDTE es utilizada para actualizar una entrada del descriptor dentro del GDT o el LDT. Para utilizarla, cargar el selector en el ECX. Se ignoran los 16 bits superiores y los dos bits inferiores (bits 0 y 1) del ECX. El bit 2 del ECX indica si el selector hace referencia a la tabla del descriptor global o local. La porción restante (bits del 3 al 15) codifican el selector - por ejemplo, la compensación en la tabla del descriptor. Debe de ser cargado EDX:EAX con el valor para escribir la entrada especificada de la tabla del descriptor. Esta instrucción solamente debe de ser usada en vez de la modificación directa de las tablas del descriptor, de modo que las tablas del descriptor de sombra del VMM puedan ser actualizadas al mismo tiempo. No modificar la entrada del descriptor correspondiente a un selector de segmento cargado actualmente. Esto daría como resultado un comportamiento indefinido. No utilizar esta instrucción, si no es recomendada por el VMM (tal y como es indicada por el bit 4 de Información VMM regresado por la instrucción VMGETINFO). El uso de esta instrucción cuando no es recomendada puede dar como resultado un funcionamiento deficiente cuando se opera en implementaciones futuras del VMM. Esta instrucción solamente puede ser utilizada desde el código de anillo 0. Conclusión Los diferentes sistemas, métodos y técnicas aquí descritos pueden ser implementados con el hardware o el software, o en donde sea apropiado, en una combinación de ambos. Por lo tanto, los métodos y aparatos de la presente invención, o ciertas porciones y aspectos de la misma, pueden tomar la forma de un código de programa (por ejemplo, instrucciones) incorporados en medios tangibles, tales como diskettes, CD-ROMs, discos duros o cualquier otro medio de almacenamiento legible por la máquina, en donde el código del programa es cargado dentro y ejecutado por una máquina, tal como una computadora, la máquina llega a ser un aparato para practicar la presente invención. En el caso de la ejecución del código del programa en computadoras que se pueden programar, la computadora generalmente incluirá un procesador, un medio de almacenamiento legible por el procesador (incluyendo memoria volátil y no volátil y/o elementos de almacenamiento), al menos un aparato de entrada y al menos un aparato de salida. De preferencia, se implementan uno o más programas en un lenguaje de programación orientado al objeto o al procedimiento de alto nivel para comunicarse con el sistema de cómputo. Sin embargo, si se desea, el(los) programa(s) puede ser implementado en el ensamble o lenguaje de la máquina. En cualquier caso, el lenguaje puede ser un lenguaje recopilado o interpretado, y combinado con las implementaciones del hardware. Los métodos y aparatos de la presente invención también pueden ser incorporados en la forma de códigos de programas que son transmitidos por algún medio de transmisión, tal como un cableado eléctrico, a través de fibras ópticas, o por medio de cualquier otra forma de transmisión, en donde, cuando el código de programa es recibido y cargado en y ejecutado por una máquina, tal como una EPROM, una matriz reguladora, un aparato lógico programable (PLD), una computadora del cliente, una grabadora de video similar, la máquina se convierte en un aparato para practicar la presente invención. Cuando es implementada en un procesador de uso general, el código del programa se combina con el procesador para producir un aparato único que opera para realizar la funcionalidad de indexación de la presente invención. Aunque la presente invención ha sido descrita en relación con las modalidades preferidas de las diferentes figuras, deberá quedar entendido que se pueden utilizar o hacer modificaciones o adiciones a otras modalidades similares a las modalidades descritas para realizar la misma función de la presente invención, sin desviarse de la misma. Por ejemplo, aunque las modalidades de ejemplo de la presente invención están descritas en el contexto de aparatos digitales que emulan la funcionalidad de computadoras personales, un experto en la técnica reconocerá que la presente invención no está limitada a dichos aparatos digitales, tal y como se describieron en la presente solicitud y que se pueden aplicar a cualquier número de aparatos o entornos de cómputo existentes o emergentes, tales como una consola de juegos, una computadora manual, una computadora portátil, etc, ya sea cableada o inalámbrica, o que pueden ser aplicados a cualquier número de dichos aparatos de cómputo conectados por medio de una red de comunicaciones y que interactúan en la red. Además, deberá de enfatizarse que una variedad de plataformas de computadora, incluyendo sistemas operativos de aparatos manuales u otros sistemas de interfase de hardware/software específicos de la aplicación, están contemplados en la presente descripción, especialmente conforme continúan proliferando el número de aparatos de red inalámbricos. Por lo tanto, la presente invención no debe de ser limitada a modalidad sola alguna, sino más bien interpretada en el alcance más amplio de acuerdo con las reivindicaciones adjuntas. Finalmente, las modalidades aquí descritas pueden ser adaptadas para utilizarlas en otras arquitecturas del procesador, sistemas basados en computadoras, o virtualizaciones del sistema y dichas modalidades son anticipadas expresamente por las descripciones aquí presentadas, y por lo tanto, la presente invención no debe de ser limitada a las modalidades específicas aquí descritas, sino que deben de ser interpretadas en la manera más amplia. De un modo similar, el uso de las instrucciones sintéticas para propósitos diferentes a la virtualización del procesador, también está anticipado por estas descripciones, y cualquiera de dichas utilizaciones de instrucciones sintéticas en los contextos diferentes a la virtualización del procesador, deben de ser leídas en su forma más amplia dentro de las descripciones aquí presentadas.