DE10197121B4

DE10197121B4 - Neuer Prozessormodus zum Begrenzen des Betriebes von auf einer virtuellen Maschine laufender Gast-Software mit Unterstützung eines Virtuelle-Maschine-Monitors

Info

Publication number: DE10197121B4
Application number: DE10197121T
Authority: DE
Inventors: Stephan Chou; Gilbert Portland Neiger; Erik Portland Cota-Robles; Stalinselvaraj Portland Jeyasingh; Richard Hillsoboro Uhlig; Michael Beaverton Kozuch; Alain Portland Kagi
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2000-12-27
Filing date: 2001-11-27
Publication date: 2009-10-01
Anticipated expiration: 2021-11-28
Also published as: WO2002052404A3; HK1058255A1; GB2386230A; BR0116599A; CN1561485A; RU2265880C2; WO2002052404A2; KR20040028704A; TW594493B; GB2386230B; KR100602157B1; AU2002217992A1; US7818808B1; RU2003123118A; DE10197121T1; GB0314030D0; CN1295604C

Abstract

Verfahren zur Unterstützung eines Virtuelle-Maschine-Monitors (310) durch einen Prozessor, wobei
a) der Prozessor einen ersten und einen zweiten (V32) Prozessormodus unterstützt,
b) der Prozessor den Virtuelle-Maschine-Monitor (310) in dem ersten Prozessormodus ausführt,
c) der Prozessor eine Gast-Software (306, 308) in dem zweiten Prozessormodus und auf ihrem jeweils vorgesehenen, von ihr gewünschten Hardware-Privileg-Level ausführt (404), wobei die Gast-Software (306, 308) ursprünglich vorgesehen ist, um durch einen Prozessor eines Typs (IA-32-ISA), der den zweiten Prozessormodus nicht unterstützt, auf dem jeweils von ihr gewünschten Hardware-Privileg-Level ausgeführt zu werden,
d) der Prozessor in dem zweiten Prozessormodus die Ausführung einer Operation bei einem ersten und einem zweiten Hardware-Privileg-Level unterstützt, wobei die Ausführung der Operation in dem Prozessor des Typs, der den zweiten Prozessormodus nicht unterstützt, bei dem ersten Hardware-Privileg-Level zu einem Zugriff auf bestimmte privilegierte Hardwareressourcen führen würde und bei dem zweiten Hardware-Privileg-Level nicht zum Zugriff auf die bestimmten Hardwareressourcen...

Description

Die Erfindung betrifft ein Verfahren zur Unterstützung eines Virtuelle-Maschine-Monitors durch einen Prozessor, der einen ersten und einen zweiten Prozessormodus unterstützt, den Virtuelle-Maschine-Monitor in dem ersten Prozessormodus ausführt und eine Gast-Software in dem zweiten Prozessormodus und auf ihrem jeweils vorgesehenen, von ihr gewünschten Hardware-Privileg-Level ausführt. Ferner betrifft die Erfindung einen Prozessor zum Ausführen eines solchen Verfahrens.
Ein Verfahren bzw. ein Prozessor der eingangs genannten Art sind aus der US-Patentschrift US 5,522,075 A bekannt. Bei diesem bekanntem Prozessor wird ein VM-Bit zum Anzeigen des ersten oder zweiten Prozessormodus verwendet. Es werden sogenannte ”sensitive” Befehle definiert, bei deren Ausführung der sich in einem VM-Modus befindende Prozessor einen Trap erzeugt und in einen VMM-Modus wechselt. Dies wird unabhängig davon ausgeführt, ob dieser sensitive Befehl bei seiner fortgesetzten Ausführung in dem VM-Modus zu einer Schutzrechtsverletzung geführt hätte und somit letztendlich nicht ausgeführt worden wäre.
Ein Virtuelle-Maschine-Monitor (VMM) läuft üblicherweise auf einen Computer und stellt für andere Software die Abstraktion von einer oder mehreren virtuellen Maschinen dar. Jede virtuelle Maschine kann als eine unabhängige Plattform funktionieren, die ihr eigenes ”Gast-Betriebssystem” ausführt (zum Beispiel ein von dem VMM verwaltetes (hosted by) Betriebssystem). Das Gast-Betriebssystem erwartet so zu arbeiten, als würde es auf einem speziellen Computer statt auf einer virtuellen Maschine laufen. Das heißt das Gast-Betriebssystem erwartet, verschiedene Computeroperationen zu steuern und während dieser Operationen Zugriff auf Hardwareressourcen zu haben. Die Hardwareressourcen können prozessorresidente Ressourcen (beispielsweise Steuerregister) und Ressourcen umfassen, die sich im Speicher befinden (beispielsweise Deskriptortabellen). In einer Virtuelle-Maschine-Umgebung jedoch sollte der VMM in der Lage sein, die endgültige Kontrolle über diese Ressourcen zu haben, um einen ordnungsgemäßen Betrieb der virtuellen Maschinen und Schutz vor und zwischen virtuellen Maschinen bereitzustellen. Um dies zu erreichen, fängt der VMM üblicherweise alle Zugriffe von dem Gast-Betriebssystem auf die Hardwareressourcen ab und vermittelt diese.
Aktuelle Implementierungen von VMM's können auf Software-Techniken zum Steuern des Zugriffs von dem Gast-Betriebssystem auf Hardwareressourcen basieren. Jedoch kann es diesen Software-Techniken an der Fähigkeit mangeln, Gast-Software am Zugriff auf einige Felder in den Steuerregistern und dem Speicher des Prozessors zu hindern. Beispielsweise kann das Gast-Betriebssystem nicht vom Zugriff auf ein Requestor Privileg Level(RPL)-Feld in dem Codesegmentregister von IA-32-Mikropozessoren abgehalten werden. Darüber hinaus weisen bestehende Software-Techniken üblicherweise Leistungsprobleme auf. Somit wird ein alternativer Mechanismus zum Unterstützen des Betriebes des VMM's benötigt.
Ausgehend von dem eingangs genannten Stand der Technik des US-Patents Nr. US 5,522,075 A ist es eine Aufgabe der Erfindung, die Prozessorleistung durch Vermeidung unnötigen Mehraufwands zu verbessern.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit den Merkmalen des Anspruchs 1 bzw. einen Prozessor mit den Merkmalen des Anspruchs 8 gelöst. Grundgedanke der erfindungsgemäßen Weiterbildung ist es, den mit einem Wechsel in den ersten Prozessormodus des Virtuelle-Maschine-Monitors verbundenen Mehraufwand dann zu vermeiden, wenn dieser eigentlich nicht erforderlich ist, weil der betroffene kritische Befehl auch ohne den Wechsel nicht ausgeführt würde.
Vorteilhafte und/oder bevorzugte Weiterbildungen der Erfindung sind in den Unteransprüchen gekennzeichnet.
Die vorliegende Erfindung wird anhand der Figuren der beigefügten Zeichnungen exemplarisch und nicht zur Beschränkung dargestellt und in diesen beziehen sich gleiche Bezugszeichen auf ähnliche Elemente und:
1 zeigt ein Ausführungsbeispiel einer Virtuelle-Maschine-Umgebung;
2 zeigt den Betrieb eines Virtuelle-Maschine-Monitors basierend auf einer Gast-Deprivilegierung;
3 zeigt eine Blockdarstellung eines Systems zum Bereitstellen einer Prozessorunterstützung für einen Virtuelle-Maschine-Monitor gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
4 zeigt ein Ablaufdiagramm eines Verfahrens zum Bereitstellen einer Prozessorunterstützung für einen Virtuelle-Maschine-Monitor gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
5 zeigt ein Ablaufdiagramm eines Verfahrens zum Durchführen eines Übergangs aus dem V32-Modus gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
6 zeigt ein Ablaufdiagramm eines Verfahrens zum Erzeugen von Virtualisierungs-Traps gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
7 zeigt ein Ablaufdiagramm eines Verfahrens zum Aufrechterhalten einer Umleit-Abbildung (redirection map) gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
8 zeigt ein Ablaufdiagramm eines Verfahrens zum Steuern des Maskierens von Interrupts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung; und
9 zeigt eine Blockdarstellung eines Ausführungsbeispiels eines Verarbeitungssystems.
Beschreibung von Ausführungsbeispielen
Es wird ein Verfahren und eine Einrichtung zum Bereitstellen einer Prozessorunterstützung für einen Virtuelle-Maschine-Monitor beschrieben. In der folgenden Beschreibung werden zur Erläuterung zahlreiche spezielle Details angegeben, um ein vollständiges Verständnis der vorliegenden Erfindung zu ermöglichen. Für den Fachmann ist jedoch ersichtlich, daß die vorliegende Erfindung ohne diesen speziellen Details ausgeführt werden kann.
Einige Abschnitte der folgenden detaillierten Beschreibung werden anhand von Algorithmen und symbolischen Darstellungen von Operationen an Datenbits in einem Computerspeicher dargestellt. Diese algorithmischen Beschreibungen und Darstellungen sind die von Fachleuten auf dem Gebiet der Datenverarbeitung verwendeten Mittel, um anderen Fachleuten den Gehalt ihrer Arbeit am effektivsten mitzuteilen. Ein Algorithmus wird hier und im allgemeinen als eine selbstkonsistente Abfolge von zu einem gewünschten Ergebnis führenden Schritten verstanden. Diese Schritte erfordern physikalische Behandlungen von physikalischen Größen. Üblicher- aber nicht notwendigerweise liegen diese Größen in Form von elektrischen oder magnetischen Signalen vor, die gespeichert, übertragen, kombiniert, verglichen oder auf andere Weise bearbeitet manipuliert werden können. Hauptsächlich aus Gründen der üblichen Verwendung hat es sich zeitweise als günstig erwiesen, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder ähnliches zu bezeichnen.
Es sollte jedoch bedacht werden, daß all diese und ähnliche Begriffe den entsprechenden physikalischen Größen zuzuordnen sind und lediglich geeignete Kennzeichen für diese Größen darstellen. Sofern es nicht explizit anders angegeben ist wie aus den folgenden Beschreibungen ersichtlich, ist klar, daß überall in der vorliegenden Erfindung Beschreibungen, die Begriffe wie beispielsweise ”Verarbeiten” oder ”Berechnen” oder ”Kalkulieren” oder ”Bestimmen” oder ”Anzeigen” oder dgl. verwenden auf die Aktion und Prozesse eines Computersystems oder einer ähnlichen elektronischen Recheneinrichtung hinweisen können, die Daten, die als physikalische (elektronische) Größen in den Registern und Speichern des Computersystems dargestellt sind bearbeitet und in andere Daten umwandelt, die auf ähnliche Weise als physikalische Größen in den Speichern oder Registern des Computersystems oder anderen derartigen Informationsspeichern, Übertragungs- oder Anzeigeeinrichtungen dargestellt sind.
Die vorliegende Erfindung betrifft ferner eine Einrichtung zum Durchführen der hier beschriebenen Operationen. Diese Einrichtung kann für die gewünschten Zwecke speziell konstruiert sein oder sie kann einen Mehrzweckcomputer aufweisen, der selektiv von einem in dem Computer gespeicherten Computerprogramm aktiviert oder rekonfiguriert wird. Ein derartiges Computerprogramm kann in einem computerlesbaren Speichermedium wie beispielsweise einer beliebigen Art von Platte einschließlich Floppy-Disks, optischen Platten, CD-ROMs und magnetisch-optische Platten, Nur-Lese-Speichern (ROMs), Speichern mit wahlfreiem Zugriff (RAMs), EPROMs, EEPROMs, magnetischen oder optischen Karten oder einer beliebigen Art von zum Speichern von elektronischen Befehlen geeigneten Medien gespeichert sein, ist hierauf jedoch nicht beschränkt, und jedes Speichermedium ist mit einem Computersystembus gekoppelt. Befehle sind unter Verwendung von einer oder mehreren Verarbeitungseinrichtungen (beispielsweise Prozessoren, zentrale Verarbeitungseinheiten etc.) ausführbar.
Die hier dargestellten Algorithmen und Anzeigen sind nicht per se für einen bestimmten Computer oder eine andere Einrichtung bestimmt. Verschiedene Mehrzweckmaschinen können mit Programmen gemäß den hier beschriebenen Lehren verwendet werden oder es kann sich als günstig erweisen, spezialisiertere Einrichtungen zum Ausführen der erforderlichen Verfahrensschritte herzustellen. Die für eine Vielzahl dieser Maschinen erforderliche Struktur wird aus der folgenden Beschreibung ersichtlich. Darüber hinaus ist die vorliegende Erfindung nicht unter Bezugnahme auf eine bestimmte Programmiersprache beschrieben. Es ist klar, daß eine Vielzahl von Programmiersprachen verwendet werden können, um die hier beschriebenen Lehren der Erfindung zu implementieren.
In der folgenden detaillierten Beschreibung der Ausführungsbeispiele wird Bezug genommen auf die beigefügten Zeichnungen, die zur Veranschaulichung spezielle Ausführungsbeispiele zeigen, in denen die Erfindung ausgeführt werden kann. Bei den Zeichnungen beschreiben gleiche Bezugszeichen bei den verschiedenen Darstellungen im wesentlichen ähnliche Komponenten. Diese Ausführungsbeispiele weder detailliert genug beschrieben, um es Fachleuten zu ermöglichen, die Erfindung auszuführen. Es können andere Ausführungsbeispiele verwendet werden und strukturelle, logische und elektrische Änderungen können vollzogen werden, ohne von dem Schutzbereich der vorliegenden Erfindung abzuweichen. Darüber hinaus ist zu beachten, daß sich die verschiedenen Ausführungsbeispiele der Erfindung nicht gegenseitig ausschließen, auch wenn sie unterschiedlich sind. Zum Beispiel kann ein bestimmtes, bei einem Ausführungsbeispiel beschriebenes Merkmal, eine bestimmte Struktur oder ein bestimmtes Charakteristikum in anderen Ausführungsbeispielen enthalten sein. Die folgende detaillierte Beschreibung soll daher nicht in einem beschränkenden Sinne aufgefaßt werden und der Schutzbereich der vorliegenden Erfindung wird nur durch die beigefügten Ansprüche zusammen mit dem von diesen Ansprüchen umfaßten gesamten Äquivalenzbereich definiert.
Das Verfahren und die Einrichtung der vorliegenden Erfindung stellen eine Prozessorunterstützung für einen Virtuelle-Maschine-Monitor (VMM) bereit. 1 zeigt ein Ausführungsbeispiel einer Virtuelle-Maschine-Umgebung 100, in welcher die vorliegende Erfindung ausgeführt werden kann. Bei diesem Ausführungsbeispiel weist eine bloße Plattform-Hardware 116 eine Rechenplattform auf, die beispielsweise zum Ausführen eines Standardbetriebssystems (OS) oder eines Virtuelle-Maschine-Monitors (VMM) wie beispielsweise eines VMM 112 geeignet sein kann. Obwohl ein VMM üblicherweise in einer Software implementiert ist, könnte er lediglich eine Maschinenschnittstelle wie beispielsweise eine Emulation an eine Software einer höheren Ebene exportieren. Eine derartige Software einer höheren Ebene kann ein Standard- oder ein Echtzeit-OS aufweisen, obgleich der Schutzbereich der Erfindung in dieser Hinsicht nicht beschränkt ist, und alternativ kann ein VMM beispielsweise in oder auf einem anderen VMM laufen. VMMs und ihre üblichen Merkmale und Funktionalitäten sind Fachleuten bekannt und können beispielsweise in Software, Firmware oder im Zusammenhang mit verschiedenen Techniken implementiert sein.
Wie weiter oben beschrieben, liefert ein VMM anderer Software (das heißt ”Gast”-Software) die Abstraktion von einer oder mehreren virtuellen Maschinen (VMs). 1 zeigt zwei VMs 102 und 114. Die Gast-Software jeder VM umfaßt ein Gast-OS wie beispielsweise ein Gast-OS 104 oder 106 und verschiedene Gast-Softwareanwendungen 108–110. Jedes Gast-OS 104 und 106 erwartet, den Zugriff auf physikalische Ressourcen (beispielsweise Prozessorregister, Speicher und speicherzugeordnete-I/O-Einrichtungen) in der Hardwareplattform zu steuern, auf der das Gast-OS 104 oder 106 läuft, und an dere Funktionen auszuführen. In einer Virtuelle-Maschine-Umgebung sollte der VMM 112 jedoch die endgültige Kontrolle über die physikalischen Ressourcen haben, um einen ordnungsgemäßen Betrieb der VMs 102 und 112 und einen Schutz vor und zwischen den VMs 102 und 114 bereit zu stellen. Der VMM 112 erreicht dies, indem alle Zugriffe der Gast-OS 104 und 106 auf die physikalischen Ressourcen des Computers abgefangen werden. Es können verschiedene Techniken verwendet werden, um es dem VMM 112 zu ermöglichen, die oben genannten Zugriffe abzufangen. Eine dieser Techniken ist eine Gast-Deprivilegierungstechnik, die die gesamte Gast-Software zwingt, auf einem Hardware-Privileg-Level zu laufen, daß der Software den Zugriff auf bestimmte Hardwareressourcen verbietet. Wann immer das Gast-OS 104 oder 106 versucht, auf eine dieser Hardwareressourcen zuzugreifen, wird es demzufolge von dem VMM 112 ”abgefangen” (traps to the VMM), das heißt der VMM 112 erlangt die Kontrolle über eine von dem Gast-OS initiierte Operation, wenn diese Operation einen Zugriff auf derartige Hardwareressourcen umfaßt.
2 zeigt ein bekanntes Ausführungsbeispiel für den Betrieb eines VMMs, der eine Gast-Deprivilegierung unterstützt. Wie zuvor beschrieben, zwingt die Gast-Deprivilegierung ein Gast-OS dazu, in einem weniger privilegierten Ausführungsmodus abzulaufen. Bei IA-32-Mikroprozessoren gestaltet sich die Art des seitenbasierten Schutzes derart, daß die gesamte Gast-Software auf dem am geringsten privilegierten Level (das heißt Ring 3) läuft. Das heißt, ein Gast-OS 206 und Gast-Anwendungen 204 laufen auf dem gleichen Privileg-Level. Demzufolge könnte das Gast-OS 206 nicht in der Lage sein, sich selbst vor den Gast-Anwendungen 206 zu schützen, wodurch möglicherweise die Integrität des Gast-OS 206 gefährdet ist. Dieses Problem ist als Ringkompression (ring compression) bekannt.
Die Gast-Deprivilegierung kann ferner ein Adreßraum-Kommpressionsproblem verursachen. Wie zuvor beschrieben, führen bestimmte Versuche der Gast-Software, auf Hardwareressourcen zuzugreifen, zu Traps, die die Kontrolle auf den VMM 220 übertragen. Um diese Übertragung der Steuerung zu ermöglichen, kann es für einen Abschnitt des VMM-Codes und/oder der Datenstrukturen architektonisch erforderlich sein, sich in dem gleichen virtuellen Adreßraum zu befinden wie das Gast-OS 206. Beispielsweise kann die IA-32-Befehlssatzarchitektur (ISA) erfordern, daß sich eine Interrupt-Deskriptor-Tabelle (IDT) 212 eine Global-Dekriptor-Tabelle (GDT) 210 und Trap-Behandlungsroutinen in dem gleichen virtuellen Raum wie das Gast-OS 206 befinden. Der in dem virtuellen Raum 202 befindliche VMM-Code und die Datenstrukturen 220 müssen vor Zugriffen durch die Gast-Software (beispielsweise durch ein Laufen bei Ring 0) geschützt werden. Demgemäß steuert das Gast-OS 206 nicht den gesamten Adreßraum 202 wie es das Gast-OS 206 erwartet. Dies verursacht ein Adreßraum-Kompressionsproblem.
Eine weitere Beschränkung von Gast-Deprivilegierung verwendenden VMMs betrifft einige Fälle, bei denen es dem Prozessoren mißlingt, die Gast-Software davon abzuhalten, privilegierte Hardwareressourcen zu lesen. Beispielsweise erlauben es die IA-32-Mikroprozessoren dem Gast-OS 206, PUSHCS-Befehle auszuführen, mit denen ein Codesegmentregister im Speicher gespeichert wird. Eines dieser Registerfelder speichert Informationen über das gegenwärtige Privileg-Level. Demgemäß kann das Gast-OS 206 erkennen, daß sein Privileg-Level 3 beträgt und nicht 0, wie es das Gast-OS 206 erwartet, indem es den Wert des aktuellen Privileg-Levels aus dem Speicher ließt. Demzufolge kann das Gast-OS 206 die Tatsache zur Kenntnis nehmen, daß es auf einer virtuellen Maschine läuft, und die Integrität des Gast-OS 206 kann gefährdet sein.
Ebenso fangen die Prozessoren in einigen Fällen einen Versuch der Gast-Software, privilegierte Softwareressourcen zu ändern, nicht ab. Beispielsweise erlauben es die IA-32- Prozessoren dem Gast-OS 206, POPF-Befehle auszugeben, die EFLAGS zu laden versuchen, und anstatt ein Trap zu erzeugen, ignorieren sie alle oder Teile derartige Versuche des Gast-OS 206, da das Gast-OS 206 diese Befehle mit einem nicht ausreichenden Privileg ausführt. Demzufolge glaubt das Gast-OS 206, daß ein entsprechendes EFLAGS-Feld modifiziert worden ist, aber dem VMM 220 ist dies nicht bekannt und es kann diese Modifikation nicht ordnungsgemäß emulieren. Demgemäß kann das Gast-OS 206 die Tatsache aufdecken, daß es auf einer virtuellen Maschine läuft, und die Integrität des Gast-OS 206 kann gefährdet sein.
Noch eine weitere Beschränkung von Gast-Deprivilegierung verwendenden VM-Monitoren wird durch exzessives Trapping bzw. Abfangen verursacht. Da die Anzahl der Hardwareressource-Elemente, die vor Zugriffen durch Gast-Software geschützt werden müssen, signifikant ist und derartige Zugriffe häufig auftreten können, können Traps häufig auftreten. Beispielsweise unterstützen die IA-32-Mikroprozessoren CLI-Befehle. Die CLI-Befehle werden ausgegeben, um ein Interrupt-Flag zu ändern, das ein Element der privilegierten Hardwareressourcen ist und auf das somit von nicht privilegierter Software nicht zugegriffen werden darf. Das Gast-OS 206 gibt diese Befehle üblicherweise während seines Betriebes aus, wodurch häufig Traps zu dem VMM 220 verursacht werden. Häufiges Trapping bzw. Abfangen beeinflußt die Systemleistung negativ und vermindert die Verwendbarkeit des VMM 220.
Die vorliegende Erfindung befaßt sich mit den oben genannten Problemen und verschiedene andere Beschränkungen, indem eine Prozessorunterstützung für einen VMM bereitgestellt wird. 3 zeigt eine Blockdarstellung eines Systems zum Bereitstellen einer Prozessorunterstützung für einen Virtuelle-Maschine-Monitor gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
Es wird Bezug genommen auf 3. Die gesamte Gast-Software läuft in einem hier als virtueller 32-Bit-Modus (V32-Modus) bezeichneten Prozessormodus. Der V32-Modus erlaubt es der Gast-Software, auf ihrem vorgesehenen Privileg-Level zu laufen. Für die IA-32-ISA beispielsweise läuft das Gast-OS 308 auf dem am höchsten privilegierten Level (das heißt Ring 0) und Gast-Anwendungen 306 laufen auf dem am geringsten privilegierten Level (das heißt Ring 3). Der V32-Modus begrenzt den Betrieb der Gast-Software, indem die Gast-Software daran gehindert wird, Operationen auszuführen, die zu einem Zugriff auf bestimmte privilegierte Hardwareressourcen führen können. Der V32-Modus wird verlassen, wenn die Gast-Software versucht, eine derartige Operation auszuführen.
Der VMM 320 läuft außerhalb des V32-Modus. Wenn ein Übergang aus dem V32-Modus heraus auftritt, erhält der VMM 320 die Kontrolle über die von dem Gast-OS 308 oder der Gast-Anwendung 306 initiierte Operation. Der VMM 320 führt diese Operation dann aus und überträgt die Kontrolle zurück auf die Gast-Software, indem in den V32-Modus eingetreten wird, wodurch die von der Gast-Software gewünschte Funktionalität emuliert wird.
Bei einem Ausführungsbeispiel wird der V32-Modus implementiert, indem ein Flag in einem der Steuerregister des Prozessors (beispielsweise CR0) aufrecht erhalten wird, um anzuzeigen, ob sich der Prozessor in dem V32-Modus befindet oder nicht. Bei einem weiteren Ausführungsbeispiel wird dieses Flag (das hier als EFLAGS.V32 bezeichnet wird) in einem der reservierten Bits in der oberen Hälfte des EFLAGS gehalten. Das EFLAGS.V32-Flag wird entweder durch einen Übergang aus dem V32-Modus heraus oder einen Übergang in den V32-Modus modifiziert.
Bei einem Ausführungsbeispiel wird die Fähigkeit des Prozessors, den V32-Modus zu unterstützen, unter Verwendung eines der reservierten Feature- bzw. Merkmal-Bits beschrie ben, die in EDX zurückgegeben werden, wenn der CPUID-Befehl mit dem Wert 1 in EAX ausgeführt wird. Es sei angemerkt, daß eine Vielzahl anderer Mechanismen verwendet werden können, um den V32-Modus zu implementieren und die Fähigkeit des Prozessors darzulegen, den V32-Modus ohne einen Verlust von Universalität zu unterstützen.
Bei einem Ausführungsbeispiel verursachen bestimmte Ausnahmen und Interrupts einen Übergang aus dem V32-Modus. Diese Ausnahmen und Interrupts umfassen ”Virtualisierungs-Traps”. Ein Virtualisierungs-Trag wird erzeugt, wenn in dem V32-Modus laufende Gast-Software versucht, eine Operation auszuführen, die zu einem Zugriff auf bestimmte privilegierte Hardwareressourcen führen kann. Bei einem Ausführungsbeispiel wird der Gast-Adreßraum 304 automatisch in den VMM-Adreßraum 302 geändert, wenn ein Übergang aus dem V32-Modus stattfindet. Darüber hinaus wird der Prozessorzustand, der von der Gast-Software verwendet wurde, gesichert und in temporären Registern gespeichert, und der von dem VMM 320 benötigte Prozessorzustand wird geladen.
Bei einem Ausführungsbeispiel wird der bei dem Übergang aus dem V32-Modus (d. h. zu dem VMM 320) gesicherte Prozessorzustand automatisch wieder hergestellt, der VMM-Adreßraum 302 in den Gast-Adreßraum 304 geändert und die Steuerung an das Gast-OS 308 zurückgegeben, wenn ein Übergang in den V32-Modus stattfindet.
Bei einem Ausführungsbeispiel werden Software-Interrupts (beispielsweise durch eine Ausführung von BOUND-, INT- oder INTO-Befehlen verursachte Interrupts) von dem Gast-OS 308 unter Verwendung der Gast-IDT (das heißt der in dem Gast-Adreßraum 304 befindlichen IDT) verarbeitet, wenn die Gast-Software im V32-Modus läuft. Alle anderen Interrupts und Ausnahmen einschließlich Virtualisierungs-Traps verursachen einen Übergang aus dem V32-Modus, der zu einer Änderung des Gast-Adreßraumes 304 in den VMM-Adreßraum 302 führt. Die IDT 316 wird dann verwendet, um auf einen Code zu zeigen, der eine entsprechende Ausnahme oder einen entsprechenden Interrupt verarbeitet.
Bei einem Ausführungsbeispiel wird ein neues Interrupt-Flag (das heißt ein Virtuelle-Maschine-Interrupt-Flag) für Zugriffe durch eine Gast-Software aufrecht erhalten. Wann immer die Gast-Software versucht, auf das Interrupt-Flag (IF) zuzugreifen, greift sie stattdessen auf das Virtuelle-Maschine-Interrupt-Flag (VMIF) zu. Bei einem Ausführungsbeispiel verursacht ein Versuch der Gast-Software, auf das VMIF (beispielsweise unter Verwendung des CLI-Befehls) zuzugreifen, keinen Übergang aus dem V32-Modus heraus, ausgenommen dann, wenn das Gast-OS 308 VMIF gerade auf 1 gesetzt hat (beispielsweise durch den STI-Befehl) und der VMM 320 einen anhängigen Interrupt an das Gast-OS 308 übergeben möchte. Derartige anhängige Interrupts werden hier als ”virtuelle anhängige Interrupts” bezeichnet und erzeugen Virtualisierungs-Traps, die es dem VMM 320 ermöglichen, einen anhängigen Interrupt an die Gast-Software zu übergeben, wenn das Gast-OS 308 signalisiert, daß es bereit ist, einen derartigen Interrupt zu verarbeiten. Bei einem Ausführungsbeispiel wird eines der reservierten Bits der oberen Hälfte des EFLAGS-Registers verwendet, um ein Flag aufrecht zu erhalten, das anzeigt, ob die Gast-Software einen anhängigen virtuellen Interrupt aufweist.
Die Implementierung des V32-Modus erlaubt es, sämtliche der von der weiter oben beschriebenen Gast-Deprivilegierung verursachten Probleme zu lösen. Insbesondere wird das Problem der Ringkompression gelöst, da die Gast-Software im V32-Modus in ihrem vorgegebenen Privileg-Level läuft. Darüber hinaus ist die Adreßraum-Kompression nicht länger ein Problem, da ein Virtualisierungs-Trag automatisch einen Wechsel in den VMM-Adreßraum 302 bewirkt und sich daher weder die derartige Übergänge steuernden Tabellen noch der ein entsprechendes Virtualisierungs-Trag verarbeitende Code in dem Gast-Adreßraum 304 zu befinden.
Darüber hinaus umfassen die Hardwareressourcen, die geschützt werden müssen, nicht länger diejenigen Elemente der Hardwareressourcen, die das Privileg-Level steuern, da es der V32-Modus der Gast-Software ermöglicht, daß sie auf ihrem vorgesehenen Privileg-Level läuft. Beispielsweise kann der weiter oben beschriebene Push-CS-Befehl dem Gast-OS 308 nicht länger aufzeigen, daß es auf einer virtuellen Maschine läuft, da das Feld des Codesegmentregisters, das Informationen über ein aktuelles Privileg-Level speichert, nun das für das Gast-OS 308 vorgesehene Privileg-Level speichert. In ähnlicher Weise werden POPF-Befehle, die versuchen EFLAGS zu laden, nicht länger ignoriert, wenn sie von dem Gast-OS 308 ausgeführt werden, da das Gast-OS 206 diese Befehle mit einem ausreichenden Privileg ausführt.
Demgemäß wird die Anzahl der Elemente der Hardwareressourcen, die geschützt werden müssen, reduziert. Wenn eines von diesen Lese- oder Schreibzugriffe ohne Trapping der Gast-Software erlaubt, werden sie speziell ausgebildet, um Traps zu verursachen, wenn sie in dem V32-Modus ausgeführt werden. Somit werden die von Lese- und Schreibzugriffen ohne Trapping verursachten Probleme gelöst. Da die Implementierung des V32-Modus die Anzahl der Elemente der Hardwareressourcen vermindert, die geschützt werden müssen, ist darüber hinaus ist auch die Anzahl der Traps geringer, die auftreten, wenn die Gast-Software versucht, auf diese Elemente zuzugreifen. Die Häufigkeit der Traps wird darüber hinaus durch das Bereitstellen eines Mechanismus zum Eliminieren der von den am häufigsten verwendeten Befehlen verursachten Traps reduziert. Beispielsweise verursachen STI-Befehle keine Traps mehr, es sei denn die Gast-Software weist einen anhängigen virtuellen Interrupt auf.
4 zeigt ein Ablaufdiagramm eines Verfahrens 400 zum Bereitstellen einer Prozessorunterstützung für einen Virtuelle-Maschine-Monitor gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Beim Verarbeitungsblock 404 wird eine Gast-Software in einem Prozessormodus (das heißt V32-Modus) ausgeführt, der es der Gast-Software erlaubt, auf einem von der Gast-Software gewünschten Privileg-Level zu arbeiten. Das heißt, ein Gast-OS kann auf einem Supervisor-Privileg-Level arbeiten und Gast-Anwendungen können auf einem Benutzer-Privileg-Level arbeiten.
Bei Verarbeitungsblock 406 wird ein Versuch der Gast-Software identifiziert, eine von dem V32-Modus beschränkte Operation auszuführen. Als Antwort auf diesen Versuch wird der V32-Modus verlassen, um die Kontrolle über die von der Gast-Software initiierten Operation an den VMM zu übertragen, der außerhalb des V32-Modus läuft (Prozessorblock 408). Bei einem Ausführungsbeispiel konfiguriert der VMM, welche Operationen einen Übergang aus dem V32-Modus verursachen sollen, wie es detaillierter weiter unten im Zusammenhang mit der 7 beschrieben wird. Bei einem Ausführungsbeispiel erzeugen derartige Operationen Virtualisierungs-Traps, die einen Übergang aus dem V32-Modus bewirken. Alternativ kann jeder andere bekannte Mechanismus verwendet werden, um einen Übergang aus dem V32-Modus zu bewirken. Ein Ausführungsbeispiel zum Ausführen eines Übergangs aus dem V32-Modus wird detaillierter weiter unten in Zusammenhang mit der 5 beschrieben.
Der VMM antwortet ferner auf die von der Gast-Software beabsichtigte Operation (Verarbeitungsblock 410). Anschließend wird in den V32-Modus zurückgekehrt, um die Kontrolle über diese Operation an die Gast-Software zurück zu geben (Verarbeitungsblock 412), und das Verfahren 400 kehrt zu dem Verarbeitungsblock 404 zurück. Bei einem Ausführungsbeispiel wird der von der Gast-Software erwartete Prozessorzustand automatisch wieder hergestellt und der VMM-Adreßraum in den Gast-Adreßraum geändert, wenn ein Übergang in den V32-Modus auftritt.
5 zeigt ein Ablaufdiagramm eines Verfahrens 500 zum Ausführen eines Übergangs aus dem V32-Modus gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Das Verfahren 500 beginnt mit dem Sichern des von der Gast-Software verwendeten Prozessorzustandes (Verarbeitungsblock 504). Bei einem Ausführungsbeispiel wird der gesicherte Prozessorzustand in den temporären Registern des Prozessors gespeichert. Bei Verarbeitungsblock 506 wird der von dem VMM benötigte Prozessorzustand in die Prozessorregister geladen. Bei einem Ausführungsbeispiel bewirkt das Laden des Prozessorzustandes einen Wechsel des Gast-Adreßraumes in den VMM-Adreßraum (beispielsweise wird der Prozessorzustand geladen, indem das Steuerregister CR3 geladen wird). Bei einem alternativen Ausführungsbeispiel bewirkt ein Laden des Prozessorzustandes keine Änderung des Adreßraumes. Bei einem solchen Ausführungsbeispiel wird bei Verarbeitungsblock 508 eine Adreßraumumschaltung ausgeführt, um von dem Gast-Adreßraum in den VMM-Adreßraum zu wechseln. Wenn demgemäß ein den Übergang bewirkende(r) Interrupt oder eine entsprechende Ausnahme auftritt, wird die in dem VMM-Adreßraum befindliche IDT automatisch verwendet, um auf den VMM-residenten Code zum Behandeln dieses Interrupts oder dieser Ausnahme zu zeigen.
6 zeigt ein Ablaufdiagramm eines Verfahrens 600 zum Erzeugen von Virtualisierungs-Traps gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Das Verfahren 600 beginnt mit einem Identifizieren eines Versuches der Gast-Software, eine Operation auszuführen, die von dem V32-Modus beschränkt sein kann (Verarbeitungsblock 604). Bei einem Entscheidungskasten 606 wird bestimmt, ob der Versuch der Gast-Software potentiell erfolgreich sein kann. Wenn die Bestimmung positiv ausfällt, wird ein Virtualisierungs-Trag erzeugt (Verarbeitungsblock 608). Alternativ wird kein Virtualisierungs-Trag erzeugt und die Gast-Software fährt mit der Operation fort (Verarbeitungsblock 610). Beispielsweise kann gemäß dem IA-32 ISA der RDMSR-Befehl nur von mit Supervisor-Privileg laufender Software ausgeführt werden. Wenn demzufolge das Gast-Software-OS, das mit dem Supervisor-Privileg läuft, diesen Befehl ausführt, kann dieser Versuch erfolgreich sein. Wenn eine Gast-Anwendung, die mit dem Benutzer-Privileg läuft, diesen Befehl ausführt, wird dieser Versuch nicht erfolgreich sein und ein allgemeiner Schutzfehler (general-protection fault) tritt auf. Ein Versuch des Gast-OS, den RDMSR-Befehl auszuführen, wird demgemäß ein Virtualisierungs-Trag verursachen, aber ein Versuch einer Gast-Anwendung wird von dem Gast-OS behandelt.
Bei einem Ausführungsbeispiel werden Virtualisierungs-Traps von potentiell erfolgreichen Versuchen des Gast-OS verursacht, auf die Steuerregister des Prozessors (beispielsweise CR0-CR4) zuzugreifen. Bei IA-32-Prozessoren beispielsweise werden Virtualisierungs-Traps als Antwort auf einen Versuch der Gast-Software erzeugt, MOV CR (ausgenommen der Versuche CR2 zu speichern, welche kein Virtualisierungs-Trap auslösen müssen), CLTS, LMSW oder SMSW-Befehle oder eine Task-Umschaltung auszuführen. Virtualisierungs-Traps können ferner von potentiell erfolgreichen Versuchen der Gast-Software verursacht werden, ein Interrupt-Flag IF zu setzen (beispielsweise mit STI-, POPF- oder IRET-Befehlen), wenn die Gast-Software einen anhängigen virtuellen Interrupt aufweist. Bei IA-32 ISA verursachen erfolgreiche Versuche, Befehle wie beispielsweise HLT, IN, INS/INSB/INSW/INSD, INVD, OUT, OUTS/OUTSB/OUTSW/OUTSD, RDMSR und WRMSR auszuführen Virtualisierungs-Traps. Diese Virtualisierungs-Traps halten die Gast-Software vom Anhalten des Prozessors und vom direkten Zugreifen auf I/O-Ports, Caches oder modellspezifische Register ab. Darüber hinaus können Virtualisierungs-Traps von Versuchen verursacht werden, CPUID-Befehle auszuführen, um es dem VMM zu ermöglichen die Abstraktion von von dem VMM ausgewählten Prozessormerkmalen zu präsentieren, von Versuchen, INVLPG-Befehle auszuführen, um es dem VMM zu ermöglichen, Adreßtranslationen richtig zu virtualisieren und von Versuchen, IRET-Befehle (wenn IRET für den Übergang in den V32-Modus verwendet wird) auszuführen, die von Gast-Software zum Implementieren eines VMM verwendet werden, das rekursiv verschachtelte VMMS erlaubt.
7 zeigt ein Ablaufdiagramm eines Verfahrens 700 zum Aufrechterhalten einer Umleitabbildung (redirection map) gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Gemäß diesem Ausführungsbeispiel hält der VMM eine Umleitabbildung aufrecht, um zu konfigurieren, welche Interrupts und Ausnahmen zu einer Virtualisierungs-Trag führen sollen (Verarbeitungsblock 704). Bei Verarbeitungsblock 706 wird das Auftreten eines Interrupts oder einer Ausnahme identifiziert. Anschließend wird die Umleitabbildung (redirection map) befragt, um ein Bit aufzufinden, das diesem Interrupt oder dieser Ausnahme in der Umleit-Bitmap zugeordnet ist (Verarbeitungsblock 708).
Bei Entscheidungskasten 710 wird bestimmt, ob dieses Interrupt von dem Gast-OS behandelt werden darf. Wenn die Bestimmung positiv ist, wird das Interrupt oder die Ausnahme an den V32-Modus übergeben und wird von dem Gast-OS behandelt (Verarbeitungsblock 714). Alternativ wird ein Virtualisierungs-Trag erzeugt, das einen Übergang aus dem V32-Modus bewirkt (Verarbeitungsblock 712).
8 zeigt ein Ablaufdiagramm eines Verfahrens 800 zum Steuern des Maskierens von Interrupts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Verschiedene Ausführungsbeispiele können verwendet werden, um das Maskieren von Interrupts zu steuern. Bei einem Ausführungsbeispiel sind sämtliche Interrupts nicht maskiert, wenn die Gast-Software läuft. Bei diesem Ausführungsbeispiel wird der Gast-Software erlaubt, ein Interrupt-Flag (beispielsweise wird dieses Flag für IA-32-Mikroprozessoren als EFLAGS.IF gekennzeichnet) zu manipulieren, jedoch wird diese Manipulation in Hinblick auf die Maskierung von Interrupts ignoriert. Bei einem anderen Ausführungsbeispiel ist die Maskierung von Interrupts abhängig von dem Interrupt-Flag. Bei diesem Ausführungsbeispiel ist es der Gast-Software nicht erlaubt, das Interrupt-Flag zu manipulieren. Insbesondere kann die Gast-Software davon abgehalten werden, auf das Interrupt-Flag zuzugreifen, indem ein Schatten- bzw. Shadow-Interrupt-Flag (beispielsweise EFLAGS.VMIF) für Modifikationen durch die Gast-Software bereitgestellt wird, indem ein Virtualisierungs-Trag als Antwort auf einen derartigen Versuch der Gast-Software erzeugt wird oder indem eine beliebige andere bekannte Technik verwendet wird.
Das Verfahren 800 beginnt mit einem Identifizieren eines Versuches einer Gast-Software, ein Interrupt-Flag zu modifizieren, das potentiell ein Maskieren von Interrupts steuern kann (Verarbeitungsblock 804). Bei dem Entscheidungskasten 806 wird bestimmt, ob das Interrupt-Flag die Maskierung der Interrupts steuert. Wenn die Bestimmung negativ ist, das heißt sämtliche Interrupts nicht maskiert sind, wird es der Gast-Software erlaubt, das Interrupt-Flag zu modifizieren (Verarbeitungsblock 808). Wie es zuvor beschrieben wurde, hat diese Modifikation keine Auswirkung auf die Maskierung der Interrupts.
Wenn andererseits die Maskierung der Interrupts von dem Interrupt-Flag abhängig ist, wird anschließend bestimmt, ob ein Shadow-Interrupt-Flag existiert, das heißt ob der Versuch der Gast-Software, die Maskierung der Interrupts zu beeinflussen, das Shadow-Flag beeinflußt (Entscheidungsbox 810). Wenn die Bestimmung negativ ist, das heißt wenn die Gast-Software versucht, das aktuelle Interrupt-Flag zu modifizieren, tritt ein Virtualisierungs-Trag auf (Verarbeitungsblock 812), das einen Übergang aus dem V32-Modus bewirkt (Verarbeitungsblock 816). Wenn alternativ das aktuelle Interrupt-Flag nicht für die Gast-Software zugänglich ist, wird der Gast-Software erlaubt, das Shadow-Interrupt-Flag zu modifizieren (Verarbeitungsblock 814).
9 zeigt eine Blockdarstellung eines Ausführungsbeispieles eines Verarbeitungssystems. Ein Verarbeitungs system 900 umfaßt einen Prozessor 920 und einen Speicher 930. Der Prozessor 920 kann eine beliebige Art von Prozessor sein, der Software ausführen kann, wie beispielsweise ein Mikroprozessor, ein digitaler Signalprozessor, eine Mikrosteuereinheit oder dgl. Das Verarbeitungssystem 900 kann ein Personalcomputer (PC), ein Mainframe, eine tragbare Handeinrichtung, ein tragbarer Computer, eine Set-Top-Box oder ein beliebiges anderes System sein, das Software umfaßt.
Der Speicher 930 kann eine Festplatte, eine Floppy-Disk, ein Speicher mit wahlfreiem Zugriff (RAM), ein Nur-Lese-Speicher (ROM), Flash-Speicher oder eine beliebige andere Art von von dem Prozessor 920 lesbarem Maschinenmedium sein. Der Speicher 930 kann Befehle zum Ausführen der Durchführung der verschiedenen erfindungsgemäßen Verfahrens-Ausführungsformen wie beispielsweise der Verfahren 400, 500, 600, 700 und 800 (4–8) speichern.
Es ist zu beachten, daß die obige Beschreibung zur Veranschaulichung und nicht zur Beschränkung dienen soll. Beim Lesen und Verstehen der obigen Beschreibung werden den Fachleuten zahlreiche andere Ausführungsbeispiele einfallen. Der Schutzbereich der Erfindung soll daher unter Bezugnahme auf die beigefügten Ansprüche bestimmt werden, zusammen mit dem gesamten Äquivalenzbereich, den diese Ansprüche abdecken.

Claims

Verfahren zur Unterstützung eines Virtuelle-Maschine-Monitors (310) durch einen Prozessor, wobei a) der Prozessor einen ersten und einen zweiten (V32) Prozessormodus unterstützt, b) der Prozessor den Virtuelle-Maschine-Monitor (310) in dem ersten Prozessormodus ausführt, c) der Prozessor eine Gast-Software (306, 308) in dem zweiten Prozessormodus und auf ihrem jeweils vorgesehenen, von ihr gewünschten Hardware-Privileg-Level ausführt (404), wobei die Gast-Software (306, 308) ursprünglich vorgesehen ist, um durch einen Prozessor eines Typs (IA-32-ISA), der den zweiten Prozessormodus nicht unterstützt, auf dem jeweils von ihr gewünschten Hardware-Privileg-Level ausgeführt zu werden, d) der Prozessor in dem zweiten Prozessormodus die Ausführung einer Operation bei einem ersten und einem zweiten Hardware-Privileg-Level unterstützt, wobei die Ausführung der Operation in dem Prozessor des Typs, der den zweiten Prozessormodus nicht unterstützt, bei dem ersten Hardware-Privileg-Level zu einem Zugriff auf bestimmte privilegierte Hardwareressourcen führen würde und bei dem zweiten Hardware-Privileg-Level nicht zum Zugriff auf die bestimmten Hardwareressourcen führen würde, e) der Prozessor, e.1) wenn er sich auf dem ersten Hardware-Privileg-Level befindet, beim Versuch der Ausführung der Operation einen Virtualisierungs-Trag erzeugt (608) und e.2) wenn er sich auf dem zweiten Hardware-Privileg-Level befindet, die Operation so ausführt (610), als ob sie durch den Prozessor des Typs, der den zweiten Prozessormodus nicht unterstützt, ausgeführt würde, f) der Virtualisierungs-Trag einen Übergang aus dem zweiten Prozessormodus in den ersten Prozessormodus bewirkt, g) der Virtuelle-Maschine-Monitor (310) beim einem Übergang aus dem zweiten Prozessormodus zum ersten Prozessormodus die Kontrolle über die von der Gast-Software (306, 308) initiierte Operation erhält (408), die Operation ausführt (410) und die Kontrolle an die Gast-Software (306, 308) durch einen Eintritt in den zweiten Prozessormodus zurück überträgt (412).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Gast-Software ein Gast-Betriebssystem (308) und wenigstens eine Gast-Anwendung (306) umfasst.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass das Gast-Betriebssystem (308) bei dem ersten Hardware-Privileg-Level und die Gast-Anwendung (306) bei dem zweiten Hardware-Privileg-Level läuft.
Verfahren nach einem der Ansprüche 1–3, dadurch gekennzeichnet, dass beim Übergang aus dem zweiten Prozessormodus in den ersten Prozessormodus ein Flag in dem Prozessor gesetzt wird und beim Übergang aus dem ersten Prozessormodus in den zweiten Prozessormodus das Flag zurückgesetzt wird.
Verfahren nach einem der Ansprüche 1–4, dadurch gekennzeichnet, dass beim Übergang aus dem zweiten Prozessormodus in den ersten Prozessormodus der von dem Prozessor adressierbare Adressraum gewechselt wird.
Verfahren nach einem der Ansprüche 1–5, dadurch gekennzeichnet, dass beim Übergang aus dem zweiten Prozessormodus in den ersten Prozessormodus der von der Gast-Software verwendete Prozessorzustand gesichert und der von dem Virtuelle-Maschine-Monitor (310) benötigte Prozessorzustand geladen wird.
Verfahren nach einem der Ansprüche 1–6, dadurch gekennzeichnet, dass der Virtuelle-Maschine-Monitor (310) beim Ausführen der von der Gast-Software (306, 308) initiierten Operation die von der Gast-Software gewünschte Funktionalität emuliert.
Prozessor (920) zum Ausführen eines Verfahrens zur Unterstützung eines Virtuelle-Maschine-Monitors nach einem der Ansprüche 1–7, wobei der Prozessor a) einen ersten und einen zweiten (V32) Prozessormodus unterstützt, b) den Virtuelle-Maschine-Monitor (310) in dem ersten Prozessormodus ausführt, c) eine Gast-Software (306, 308) in dem zweiten Prozessormodus und auf ihrem jeweils vorgesehenen, von ihr gewünschten Hardware-Privileg-Level ausführt, wobei die Gast-Software (306, 308) ursprünglich vorgesehen ist, um durch einen Prozessor eines Typs (IA-32-ISA), der den zweiten Prozessormodus nicht unterstützt, auf dem jeweils von ihr gewünschten Hardware-Privileg-Level ausgeführt zu werden, d) in dem zweiten Prozessormodus die Ausführung einer Operation bei einem ersten und einem zweiten Hardware-Privileg-Level unterstützt, wobei die Ausführung der Operation in einem Prozessor des Typs, der den zweiten Prozessormodus nicht unterstützt, bei dem ersten Hardware-Privileg-Level zu einem Zugriff auf bestimmte privilegierte Hardwareressourcen führen würde und bei dem zweiten Hardware-Privileg-Level nicht zum Zugriff auf die bestimmten Hardwareressourcen führen würde, und e.1) dann, wenn er sich auf dem ersten Hardware-Privileg-Level befindet, beim Versuch der Ausführung der Operation einen Virtualisierungs-Trag erzeugt (608), der einen Übergang aus dem zweiten Prozessormodus in den ersten Prozessormodus bewirkt, wobei der Virtuelle-Maschine-Monitor (310) beim dem Übergang aus dem zweiten Prozessormodus in den ersten Prozessormodus die Kontrolle über die von der Gast-Software (306, 308) initiierte Operation erhält (408), die Operation ausführt (410) und die Kontrolle an die Gast-Software (306, 308) durch einen Eintritt in den zweiten Prozessormodus zurück überträgt (412), oder e.2) dann, wenn er sich auf dem zweiten Hardware-Privileg-Level befindet, die Operation so ausführt (610), als ob sie durch den Prozessor des Typs, der den zweiten Prozessormodus nicht unterstützt, ausgeführt würde.
Prozessor nach Anspruch 8, dadurch gekennzeichnet, dass er ein Flag enthält, dass beim Übergang aus dem zweiten Prozessormodus in den ersten Prozessormodus gesetzt und beim Übergang aus dem ersten Prozessormodus in den zweiten Prozessormodus zurückgesetzt wird.
Prozessor nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass er seine Fähigkeit zur Unterstützung des zweiten Prozessormodus anzeigt, indem er in einem Register (EDX) ein dies anzeigendes Bit zurückgibt, wenn ein CPUID-Befehl mit einem Wert 1 in einem zweiten Register (EAX) ausgeführt wird.