DE10357804B4

DE10357804B4 - Neu-Beanspruchung vorhandener Felder in Adressübersetzungsdatenstrukturen zum Erweitern der Kontrolle über Speicherzugriffe

Info

Publication number: DE10357804B4
Application number: DE10357804A
Authority: DE
Inventors: Richard Hillsboro Uhlig; Gilbert Portland Neiger; Erik Portland Cota-Robles; Stalinselvaraj Portland Jeyasingh; Alain Portland Kagi; Michael Kozuch; Steven M. Hillsboro Bennett
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-12-12
Filing date: 2003-12-10
Publication date: 2008-11-13
Anticipated expiration: 2023-12-11
Also published as: CN1506847A; DE10357804A1; CN1282928C; US7073042B2; US20040117593A1

Abstract

Verfahren (300), wobei:
festgestellt wird (306), dass eine Modifikation des Inhalts einer von einem Virtuelle-Maschine-Monitor (VMM) verwalteten aktiven Adressübersetzungsdatenstruktur (206) erforderlich ist, wobei der Inhalt der aktiven Adressübersetzungsdatenstruktur (206) von einem Prozessor verwendet wird, um daraus Adress-Übersetzungen abzuleiten und in einem Übersetzungsnachschlagepuffer (TLB) (204) cache-zu-speichern;
ein Eintrag (210) in der aktiven Adressübersetzungsdatenstruktur (206) modifiziert wird, so dass der Eintrag (210) mit Ausnahme eines Teils (214) einem entsprechenden Eintrag (212) in einer Gast-Adressübersetzungsdatenstruktur (208) entspricht, wobei die Gast-Adressübersetzungsdatenstruktur (208) von einer Gast-Software für Adressübersetzungsoperationen verwendet wird,
wobei der Teil (214) des Eintrags (210), der nicht modifiziert wird (308), einem für eine betriebliche Verwendung durch die Gast-Software vorgesehenen Feld (216) innerhalb des Eintrags (212) der Gast-Adressübersetzungsdatenstruktur (208) entspricht und einen oder mehrere Zugriffssteuerindikatoren einschließt.

Description

Die Erfindung betrifft ein Verfahren zum Modifizieren eines Eintrags einer von einem Virtuelle-Maschine-Monitor (VMM) verwalteten Adreßübersetzungsdatenstruktur durch den Inhalt eines entsprechenden Eintrags einer Gast-Adreßübersetzungsdatenstruktur.
Ein Computerprozessor greift auf einen Systemspeicher zu, um Daten in dem Systemspeicher zu lesen oder in ihn zu speichern. Insbesondere verwendet der Prozessor die physikalische Adresse der Daten in dem Speicher, um die Daten zu identifizieren und auf sie zuzugreifen. Jedoch ist die physikalische Adresse, an der die Daten in dem Speicher gespeichert sind, nicht diejenige Adresse, die der Prozessor verwendet, um die Daten während interner Manipulationen zu indexieren. Statt dessen weist der Prozessor den Daten, die in Übereinstimmung mit Programmbefehlen verarbeitet werden, eine virtuelle Adresse zu. Somit erfordern Speicherzugriffe oftmals die Übersetzung von virtuellen Adressen in physikalische Adressen.
Ein herkömmlicher Adreßübersetzungsmechanismus basiert üblicherweise auf einem Übersetzungsnachschlagepuffer (TLB; Translation Lookaside Buffer), einer prozessor-internen Struktur, die als Cache für zuvor bearbeitete Adreßübersetzungen dient. Beispielsweise wird bei der Prozessorbefehlssatzarchitektur (ISA; Instruction Set Architecture) der 32-Bit-Intel^®-Architektur (hier als IA-32-ISA bezeichnet) die Adreßübersetzung von einem TLB und einer Seitentabellenhierarchie gesteuert. Die Seitentabellenhierarchie, auf welche mit Hilfe des Steuerregisters CR3 des Prozessors Bezug genommen wird, ist eine Übersetzungsdatenstruktur, die verwendet wird, um eine virtuelle Speicheradresse (auch als lineare Speicheradresse im Kontext der IA-32-ISA bezeichnet) in eine physikalische Speicheradresse zu übersetzen, wenn ein Paging freigegeben ist.
Eine Seitentabellenhierarchie schließt ein Seitenverzeichnis (PD; Page Directory), einen Satz von Seitentabellen (PTs; Page Tables) und mehrere Seitenrahmen (PFs; Page Frames) ein. Üblicherweise beginnt die Übersetzung einer virtuellen Speicheradresse in eine physikalische Speicheradresse mit einem Durchsuchen des TLB unter Verwendung entweder der oberen 20 Bits (für eine 4KB-Seite) oder der oberen 10 Bits (für eine 4MB-Seite) der virtuellen Adresse. Sofern eine Übereinstimmung gefunden wird, werden die oberen Bits eines physikalischen Seitenrahmens, die in dem TLB enthalten sind, mit den unteren Bits der virtuellen Adresse verbunden, um eine physikalische Adresse zu bilden. Wenn keine Übereinstimmung gefunden wird, konsultiert der Prozessor die Seitentabellenhierarchie, um die virtuell-zu-physikalische Übersetzung zu bestimmen, welche dann in dem TLB cache-gespeichert wird.
Jeder Eintrag in der PD und den PTs enthält üblicherweise verschiedene Felder, die die Zugreifbarkeit der Speicherseiten steuern. Beispiele derartiger Felder umfassen das Vorhanden-Flag (P-Flag; Present-Flag), welches anzeigt, ob die durch den Eintrag referenzierte Seite gültig ist, das User/Supervisor-Flag (U/S-Flag), das Zugriffe auf die durch den Eintrag referenzierte Seite auf der Grundlage von Privilegniveaus steuert, und das Lese/Schreib-Flag (R/W-Flag), das Zugriffe auf der Grundlage der Zugriffsart (das heißt Lesen oder Schreiben) steuert.
Adreßübersetzungsdatenstrukturen (Seitentabellenhierarchien) sind beispielsweise in Intel, „Microprocessor and Peripheral Handbook", Volume I: „Microprocessor", 1988, Seiten 4–48 bis 4–54, in Klaus-Dieter Thies, „80486 – Systemsoftware-Entwicklung – Ein Lehr- und Arbeitsbuch zur Intel-Mikroprozessortechnik", Carl Hanser Verlag München Wien, 1992, Seiten 557 bis 563, sowie in Hans-Peter Messmer, „PC-Hardwarebuch-Aufbau, Funktionsweise, Programmierung", 5. Auflage, Addison-Wesley, 1998, Seiten 129 bis 137, beschrieben.
Der Artikel von Judith S. Hall und Paul T. Robinson, „Virtualizing the VAX architecture", ACM SIGARCH Comp. Arch. News, Vol. 19, Nr. 3. Mai 1991, Seiten 380 bis 389, beschreibt Modifikationen an der VAX-Architektur derart, daß diese virtuelle Maschinen unterstützen kann. Die Druckschrift geht zunächst kurz auf die Theorie der virtuellen Maschinen ein, beschreibt dann einige Merkmale der VAX-Architektur, insbesondere die Fragen der Schutzringe, des Speichermanagaments und die bei der Virtualisierung auftretenden Probleme, und befaßt sich dann mit Änderungen an der Architektur, die zum Unterstützen eines VMM und zum Ausführen virtueller Maschinen vorgenommen wurden. Die Druckschrift schlägt zunächst vor, eine Ringkompression vorzunehmen, wobei die vier Zugriffsmodi User, Supervisor, Executive und Kernel der virtuellen Maschine auf drei Zugriffsmodi der realen Maschine abgebildet werden, indem die Modi Executive und Kernel auf dem Modus Executive abgebildet werden. Nur dem VMM wird gestattet, tatsächlich im Kernel-Modus zu arbeiten. Da die VAX-Architektur im Speichermanagement mit Seitentabellen arbeitet, bei denen die Seitentabellen-Einträge unter anderem ein Schutzfeld enthalten, ist aufgrund der Ringkompression eine Modifikation der Seitentabellenverwaltung erforderlich. Der VMM erzeugt und verwaltet Schattenseitentabellen des Betriebssystems der virtuellen Maschinen. Diese Schattenseitentabellen des VMM sind die normalen VAX-Seitentabellen der herkömmlichen Architektur und die einzigen Tabellen, die dem Mikrocode bekannt sind. Die Schattenseitentabellen enthalten die tatsächlichen physikalischen Seitennummern und übersetzte Schutzfelder, die den physikalischen Seitennummern und den Schutzfeldern der Seitentabelleneinträge der VM entsprechen. Die Übersetzung der Schutzfelder der Seitentabelleneinträge der VMs muß in Übereinstimmung mit dem Ringkompressionsschema erfolgen. Da die VAX-Architektur vorgibt, daß eine Hardware den Schutzcode eines Seitentabelleneintrags selbst dann überprüft, wenn das Gültig-Bit gelöscht ist, jedoch die Schutzbits eines nicht aktualisierten Schattenseitentabelleneintrags keine sinnvollen Werte enthalten, schlägt der Artikel vor, die Seitentabelleneinträge der Schattenseitentabelle mit Null-Seitentabelleneinträgen zu initialisieren. Die Null-Seitentabelleneinträge gestatten sowohl Lese- als auch Schreibzugriffe bei sämtlichen Modi und sind ungültig (invalid). Wenn somit die virtuelle Maschine (VM) eine Seite tangiert, deren Seitentabelleneintrag ein Null-Seitentabelleneintrag ist, ist die Schutzüberprüfung stets erfolgreich und die Maschine liefert einen Seitenfehler an den VMM. Der VMM aktualisiert dann den Schattenseitentabelleneintrag gemäß den Inhalten des Seitentabelleneintrags der VM und versucht die Referenz erneut. Der Schattenseitentabelleneintrag wird stets durch vollständige Übernahme des Eintrags der Seitentabelle des VM aktualisiert.
Der Erfindung liegt die Aufgabe zugrunde, die Möglichkeiten der Zugriffssteuerung zu erweitern.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 gelöst.
Im folgenden wird die Erfindung anhand von in den Zeichnungen dargestellten bevorzugten Ausführungsformen näher beschrieben. In den Zeichnungen zeigen:
1 ein Ausführungsbeispiel einer Virtuelle-Maschine-Umgebung, in welcher die vorliegende Erfindung betrieben werden kann;
2 eine Blockdarstellung einer Ausführungsform eines virtuellen TLB-Systems;
3 ein Ablaufdiagramm eines Ausführungsbeispiels eines Prozesses zum Neu-Beanspruchen (Reclaiming) vorhandener Felder einer Adreßübersetzungsdatenstruktur zum Erweitern der Kontrolle über Speicherzugriffe in einer Virtuelle-Maschine-Umgebung;
4 eine Blockdarstellung eines Ausführungsbeispiels eines virtuellen TLB-Systems, das die Adreßübersetzung in der IA-32-ISA unterstützt; und
5 die Formate der Seitenverzeichniseinträge (PDEs) und Seitentabelleneinträge (PTEs) in einer herkömmlichen Seitentabellenhierarchie für die IA-32-ISA.
Es wird ein Verfahren zum Neu-Beanspruchen (Reclaiming) vorhandener Bits in einer Adreßübersetzungsdatenstruktur zum Erweitern der Kontrolle über Speicherzugriffe in einer Virtuelle-Maschine-Umgebung beschrieben.
1 veranschaulicht ein Ausführungsbeispiel einer Virtuelle-Maschine-Umgebung 100, in welcher die vorliegende Erfindung betrieben werden kann. Bei diesem Ausführungsbeispiel weist die Plattform-Hardware 116 eine Rechnerplattform auf, welche beispielsweise in der Lage sein kann, ein Standardbetriebssystem (OS; Operating System) oder einen Virtuelle-Maschine-Monitor (VMM), wie beispielsweise einen VMM 112 auszuführen. Der VMM 112 kann, obwohl üblicherweise in Software implementiert, eine Maschinenschnittstelle für eine Software einer höheren Ebene emulieren und exportieren. Eine derartige Software einer höheren Ebene kann ein Standard- oder ein Echtzeit-Betriebssystem, eine in hohem Maße abgerüstete Betriebsumgebung mit beschränkter Betriebssystemfunktionalität sein oder kann auch herkömmliche Betriebssystemmöglichkeiten nicht enthalten. Alternativ kann der VMM 112 beispielsweise innerhalb oder auf einem weiteren VMM laufen. VMMs und ihre typischen Merkmale und Funktionalitäten sind Fachleuten gut bekannt und können beispielsweise in Software, Firmware oder einer Kombination verschiedener Techniken implementiert sein.
Die Plattform-Hardware 116 schließt einen Prozessor 118 und einen Speicher 120 ein. Der Prozessor 118 kann ein Prozessor eines beliebigen Typs sein, der in der Lage ist, Software auszuführen, wie beispielsweise ein Mikroprozessor, ein digitaler Signalprozessor, ein Mikrocontroller oder dergleichen. Der Speicher 120 kann eine Festplatte, eine Diskette, ein Speicher mit wahlfreiem Zugriff (RAM), ein Nur-Lese-Speicher (ROM), ein Flash-Speicher oder eine beliebige Kombination der genannten Einrichtungen oder irgendeine Art eines Maschinenmediums, das von dem Prozessor lesbar ist, sein. Der Speicher 120 kann Kanäle zur Durchführung der Ausführung des Verfahrensausführungsbeispiels der vorliegenden Erfindung speichern.
Die Plattform-Hardware 116 kann ein Personalcomputer (PC), ein Großrechner, ein Handheld-Gerät, ein transportabler Computer, eine Set-Top-Box oder irgendein anderes Rechnersystem sein.
Der VMM 112 präsentiert für andere Software (das heißt „Gast"-Software) die Abstraktion einer oder mehrerer virtuel ler Maschinen (VMs), welche dieselbe oder andere Abstraktionen an die verschiedenen Gäste zur Verfügung stellen können. 1 zeigt zwei VMs 102 und 114. Die auf jeder VM ablaufende Gast-Software kann ein Gast-Betriebssystem, wie beispielsweise das Gast-Betriebssystem 104 oder 106, und verschiedene Gast-Software-Anwendungen 108 und 110 einschließen. Die Gast-Betriebssysteme 104 und 106 erwarten, daß sie auf physikalische Ressourcen (beispielsweise Prozessorregister, Speicher und I/O-Einrichtungen) innerhalb der VMs 102 und 114, auf welchen die Gast-Betriebssysteme 104 und 106 laufen, zugreifen können und weitere Funktionen ausführen können. Während der Adreßübersetzungsoperationen erwartet das Gast-Betriebssystem beispielsweise, daß physikalischer Speicher zugeteilt, Schutz auf und zwischen Software-Anwendungen (zum Beispiel Anwendungen 108 und 110) zur Verfügung gestellt, eine Mehrzahl von Paging-Techniken verwendet wird, und so weiter. Bei einer Virtuelle-Maschine-Umgebung jedoch müssen der Prozessor 118 und der VMM 112 eine endgültige Kontrolle über Adreßübersetzungsoperationen haben, um den richtigen Betrieb der VMs 102 und 114 zu unterstützen und einen Schutz von und zwischen den VMs 102 und 114 zur Verfügung zu stellen. Bei einem Ausführungsbeispiel wird ein Adreßübersetzungssystem, das hier als System eines virtuellen Übersetzungsnachschlagepuffers (TLB) bezeichnet wird, zur Verfügung gestellt, das Versuche des Betriebssystems zum Steuern der Adreßübersetzung toleriert und unterstützt, während es dem Prozessor 118 und dem VMM 112 ermöglicht, die endgültige Kontrolle über die Adreßübersetzungsoperationen zu behalten. Einige Ausführungsformen des virtuellen TLB-Systems werden unten detaillierter beschrieben.
Die Ressourcen, auf die von der Gast-Software zugegriffen werden kann, können entweder als „privilegiert" oder als „nicht-privilegiert" klassifiziert werden. Bei privilegierten Ressourcen erleichtert der VMM 112 die von der Gast-Software gewünschte Funktionalität, während er die endgültige Kontrolle über diese privilegierten Ressourcen beibehält. Nicht-privilegierte Ressourcen brauchen nicht von dem VMM 112 kon trolliert zu werden; auf sie kann von der Gast-Software zugegriffen werden.
Bei einem Ausführungsbeispiel wird dann, wenn die Gast-Software versucht, auf eine privilegierte Ressource zuzugreifen, die Kontrolle auf den VMM 112 übertragen. In Erwiderung dessen gestattet der VMM 112 entweder der Gast-Software, auf die privilegierte Ressource zuzugreifen, oder er emuliert die von der Gast-Software gewünschte Funktionalität und überträgt dann die Kontrolle zurück an die Gast-Software. Bei einem Ausführungsbeispiel wird die Übertragung der Kontrolle zwischen der VM 102 oder 114 und dem VMM 112 durch Ausführen eines speziellen Befehls erreicht. Die Kontrolle der Gast-Software über diesen Mechanismus wird hier als VMX-Operation bezeichnet und die Übertragung der Kontrolle von der Gast-Software auf den VMM wird hier als VM-Verlassen (VM Exit) bezeichnet. Bei einem anderen Ausführungsbeispiel wird die Übertragung der Kontrolle zwischen den VM 102 oder 114 und dem VMM 112 durch Nicht-Befehls-Ereignisse, wie beispielsweise ein asynchrones Hardware-Interrupt oder einen Seitenfehler, initiiert.
Bei einem Ausführungsbeispiel werden dann, wenn ein VM-Verlassen auftritt, Komponenten des Prozessorzustands, die von der Gast-Software verwendet werden, gesichert und Komponenten des Prozessorzustands, die von dem VMM 112 benötigt werden, geladen. Dieses Sichern und Laden des Prozessorzustands kann in Abhängigkeit von der Prozessorbefehlssatzarchitektur (ISA; Instruction Set Architecture) die Wirkung eines Wechseln des aktiven Adreßraums haben. Bei der ISA der 32-Bit-Intel^®-Architektur (hier als IA-32-ISA bezeichnet) beispielsweise wird der aktive Adreßraum von den Werten in den Steuerregistern bestimmt, welche bei einem VM-Verlassen gesichert und wiederhergestellt werden können.
Bei einem Ausführungsbeispiel wird dann, wenn ein Übergang aus dem VMM 112 zu der Gast-Software auftritt, der Prozessorzustand, der bei dem VM-Verlassen gesichert wurde (und welcher von dem VMM 112 modifiziert sein könnte) wiederhergestellt, und die Steuerung wird an das Gast-Betriebssystem 104 oder 106 oder die Gast-Anwendungen 108 oder 110 zurückgegeben.
Es sei angemerkt, daß ein beliebiger anderer Mechanismus, der im Stand der Technik bekannt ist, zur Übertragung der Kontrolle zwischen der Gast-Software und dem VMM 112 ohne einen Verlust an Allgemeingültigkeit verwendet werden kann.
2 ist eine Blockdarstellung eines Ausführungsbeispiels eines virtuellen TLB-Systems 200. Das virtuelle TLB-System 200 schließt eine Gast-Adreßübersetzungsdatenstruktur 208 und einen virtuellen TLB 202 ein. Die Gast-Adreßübersetzungsdatenstruktur 208 zeigt an, wie das Gast-Betriebssystem (OS) beabsichtigt, virtuelle Speicheradressen in physikalische Speicheradressen zu übersetzen. Ein Beispiel einer solchen Adreßübersetzungsdatenstruktur ist eine Seitentabellenhierarchie, die bei der IA-32-ISA verwendet wird. Die Gast-Adreßübersetzungsdatenstruktur 208 wird von dem Gast-Betriebssystem verwaltet, welches auf einen Eintrag in der Gast-Adreßübersetzungsdatenstruktur 208 zugreifen und diesen modifizieren kann. Einige Einträge in der Gast-Adreßübersetzungsdatenstruktur 208 enthalten Felder, die speziell für Betriebszwecke der Software entwickelt wurden. Wie es in 2 gezeigt ist, enthält ein Beispieleintrag 212 in der Gast-Adreßübersetzungsdatenstruktur 208 ein für Software zur Verfügung stehendes Feld 216, das ein oder mehrere Bits enthält, die für eine betriebliche Verwendung durch Gast-Software ausgelegt sind (das heißt, die Gastsoftware kann Werte in diese Bitfelder für irgendwelche gewünschten Zwecke bringen). Es sei angemerkt, daß die Einträge, welche die für die Software zur Verfügung stehenden Bitfelder enthalten, und die Anzahl der Bits in den für die Software zur Verfügung stehenden Felder, die in jedem Eintrag vorhanden sind, in Abhängigkeit von der ISA variieren können. Bei der Seitentabellenhierarchie der IA-32-ISA beispielsweise enthält jeder Eintrag in einem Seitenverzeichnis und einer Seitentabelle drei für Software zur Verfügung stehende Bits („AVAIL"-Bits available bits), bei denen durch die Architektur garantiert wird, daß sie für eine Verwendung durch Systemprogrammierer zur Verfügung stehen. Im Ergebnis dürfen diese Bits von der Hardware nicht verwendet oder interpretiert werden (zum Beispiel um ir gendwelche spezielle Aktionen oder Schutzmechanismen zu bewirken).
Der virtuelle TLB 202 enthält einen physikalischen TLB 204, der von dem Prozessor verwaltet wird, und eine aktive Adreßübersetzungsdatenstruktur 206, die von dem VMM verwaltet wird. Die aktive Adreßübersetzungsdatenstruktur 206 und die Gast-Adreßübersetzungsdatenstruktur 208 leiten ihre Formate aus einem von der Architektur definierten Format (zum Beispiel dem IA-32-Format) ab. Der physikalische TLB 204 wird von dem Prozessor mit Adreßübersetzungen geladen, die aus der aktiven Adreßübersetzungsdatenstruktur 206 abgeleitet sind.
Bei einem Ausführungsbeispiel erzeugt der VMM die aktive Adreßübersetzungsdatenstruktur 206 auf der Grundlage der Gast-Adreßübersetzungsdatenstruktur 208 und modifiziert dann periodisch einen oder mehrere Einträge in der aktiven Adreßübersetzungsdatenstruktur 206 derart, daß sie den entsprechenden Einträgen in der Gast-Adreßübersetzungsdatenstruktur 208 entsprechen. Bei einem Ausführungsbeispiel modifiziert der VMM die aktive Adreßübersetzungsdatenstruktur 206 bei Empfang einer Kontrolle über ein Ereignis, das von der Gast-Software initiiert wird, und beim Bestimmen, daß die wahrscheinliche Ursache des Ereignisses eine Inkonsistenz zwischen dem Inhalt der aktiven Adreßübersetzungsdatenstruktur 206 und dem Inhalt der Gast-Adreßübersetzungsdatenstruktur ist. Ein derartiges Ereignis kann beispielsweise ein Versuch des Gast-Betriebssystems, den TLB 204 zu manipulieren (zum Beispiel eine Anforderung der Gast-Software zum Ungültig-Machen cache-gespeicherter Adreßübersetzungen in dem TLB 204) oder ein von dem Prozessor in Erwiderung einer von der Gast-Software ausgeführten Operation erzeugter Seitenfehler sein (zum Beispiel ein Seitenfehler, der in Erwiderung einer Anforderung der Gast-Software zum Schreiben in einen Speicherbereich erzeugt wird, der als Nur-Lese-Bereich in der aktiven Adreßübersetzungsdatenstruktur markiert ist, während er als beschreibbar in der Gast-Adreßübersetzungsdatenstruktur markiert ist.
Wenn der Inhalt der aktiven Adreßübersetzungsdatenstruktur 206 modifiziert wird, unterläßt es der VMM, die für die Soft ware zur Verfügung stehenden Bitfelder 216 aus der Gast-Adreßübersetzungsdatenstruktur 208 in die aktive Adreßübersetzungsdatenstruktur 206 zu kopieren, da die Bitfelder 216 intern von der Gast-Software verwendet werden und für den VMM keine Bedeutung haben. Da demzufolge ein in einem Eintrag der aktiven Adreßübersetzungsdatenstruktur 206 enthaltenes Bitfeld 214 nicht mit Daten aus der Gast-Adreßübersetzungsdatenstruktur 208 überschrieben wird, ist der VMM in der Lage, diese Bitfelder für seine eigenen Zwecke neu zu beanspruchen. Bei einem Ausführungsbeispiel verwendet der VMM ein Bitfeld innerhalb eines Eintrags (zum Beispiel dem Eintrag 210) der aktiven Adreßübersetzungsdatenstruktur 206, um Zugriffssteuerindikatoren 214 zu speichern, die die Zugreifbarkeit eines von dem Eintrag 210 referenzierten Speicherbereichs steuern. Beispiele der Zugriffssteuerindikatoren und ihre Verwendung in einer Virtuelle-Maschine-Umgebung werden unten detaillierter erläutert.
3 ist ein Ablaufdiagramm eines Ausführungsbeispiels eines Prozesses 300 für eine Neu-Beanspruchung vorhandener Felder einer Adreßübersetzungsdatenstruktur zum Erweitern der Kontrolle oder Steuerung von Speicherzugriffen in einer Umgebung einer virtuellen Maschine. Der Prozeß kann durch Verarbeitungslogik ausgeführt werden, die Hardware (zum Beispiel Schaltungen, spezielle Logik, programmierbare Logik, Mikrocode, etc.), Software (wie beispielsweise auf einer speziellen Maschine oder einem Mehrzweckcomputersystem ablaufende) oder eine Kombination von beidem umfassen kann.
Gemäß 3 beginnt der Prozeß 300 damit, daß die Verarbeitungslogik Zugriffssteuerindikatoren in einem oder in mehreren Einträgen einer aktiven Adreßübersetzungsdatenstruktur setzt (Verarbeitungsblock 302). Die Verarbeitungslogik setzt die Zugriffssteuerindikatoren, wenn sie einen Eintrag in der aktiven Adreßübersetzungsdatenstruktur erzeugt. Bei einem Ausführungsbeispiel wird ein Eintrag erzeugt, wenn die Verarbeitungslogik die gesamte aktive Adreßübersetzungsdatenstruktur auf der Grundlage einer Gast-Adreßübersetzungsdatenstruktur, die von dem Gast-Betriebssystem für Adreßübersetzungsoperatio nen verwendet wird, erzeugt. Alternativ erzeugt die Verarbeitungslogik einen Eintrag in der aktiven Adreßübersetzungsdatenstruktur, nachdem ein neuer Eintrag zu der Gast-Adreßübersetzungsdatenstruktur hinzugefügt worden ist. Bei einem Ausführungsbeispiel kann die Verarbeitungslogik, sobald die Zugriffssteuerindikatoren gesetzt sind, diese zu einem beliebigen Zeitpunkt modifizieren, sobald dies erforderlich ist.
Als nächstes, am Verarbeitungsblock 304 erfaßt die Verarbeitungslogik eine Übertragung der Kontrolle an den VMM, welche von einem Ereignis verursacht worden ist, das von der Gast-Software initiiert wurde (zum Beispiel einen Versuch der Gast-Software zum Manipulieren des TLB oder ein Seitenfehler, der in Erwiderung einer von der Gast-Software ausgeführten Operation erzeugt worden ist), und bewertet dieses Ereignis. Auf der Grundlage dieser Bewertung bestimmt die Verarbeitungslogik, ob dieses Ereignis eine Modifikation der aktiven Adreßübersetzungsdatenstruktur erfordert (Entscheidungskasten 306). Diese Feststellung kann beispielsweise davon abhängen, ob der Seitenfehler aufgrund der Inkonsistenz zwischen dem Inhalt der aktiven Adreßübersetzungsdatenstruktur und dem Inhalt der Gast-Adreßübersetzungsdatenstruktur oder aus irgendeinem anderen Grunde erzeugt wurde.
Sofern die am Entscheidungskasten 306 getroffene Feststellung negativ ist, endet der Prozeß 300. Alternativ, wenn die am Entscheidungskasten 306 getroffene Feststellung positiv ist, sieht die Verarbeitungslogik davon ab, die Zugriffssteuerindikatoren zu überschreiben, während der übrige Inhalt der aktiven Adreßübersetzungsdatenstruktur derart modifiziert wird, daß er mit dem Inhalt der Gast-Adreßübersetzungsdatenstruktur übereinstimmt (Verarbeitungsblock 308). Im Ergebnis werden die Zugriffssteuerindikatoren in der aktiven Adreßübersetzungsdatenstruktur zur Verwendung durch den Prozessor während Adreßübersetzungsoperationen aufrechterhalten.
Eine beispielhafte Funktionalität der Zugriffssteuerindikatoren wird jetzt unter Bezugnahme auf spezielle Merkmale der IA-32-ISA beschrieben. Es sei jedoch angemerkt, daß die Zugriffssteuerindikatoren für verschiedene Zwecke verwendet werden können, die von den unten erörterten abweichen, und mit verschiedenen Prozessoren, die keine IA-32-Prozessoren sind.
4 ist eine Blockdarstellung eines Ausführungsbeispiels eines virtuellen TLB-Systems 400, das eine Adreßübersetzung in der IA-32-ISA unterstützt. Das System 400 enthält einen virtuellen TLB 404, der eine aktive Übersetzungsdatenstruktur enthält, die von einer aktiven Seitentabellenhierarchie 406 und einem physikalischen TLB 408 repräsentiert wird. Das System 400 enthält außerdem eine Gast-Übersetzungsdatenstruktur, die von einer Gast-Seitentabellenhierarchie 402 dargestellt wird. Die aktive Seitentabellenhierarchie 406 und die Gast-Seitentabellenhierarchie 402 leiten ihr Format aus dem von der IA-32-Architektur definierten Format ab. Die Einträge der Gast-Seiten-Tabellenhierarchie 402 haben ein herkömmliches Format gemäß der IA-32-ISA.
5 veranschaulicht das Format 502 von Seitenverzeichniseinträgen (PDEs; Page Directory Entries) und das Format 504 von Seitentabelleneinträgen (PTEs; Page Table Entries) in einer herkömmlichen Seitentabellenhierarchie für die IA-32-ISA. Jeder PDE und PTE enthält einen Satz von Bits, die die Zugreifbarkeit der Speicherseiten steuern. Diese Bits umfassen beispielsweise das Vorhanden-Flag (P-Flag) 516 oder 510, welches anzeigt, ob die von dem Eintrag referenzierte Seite gültig ist oder nicht, das Benutzer/Supervisor-Flag (U/S; User/Supervisor) 520 oder 514, welches Zugriffe auf die von dem Eintrag referenzierte Seite auf der Grundlage eines Privilegierungsniveaus steuert, und das Lese/Schreib-Flag (R/W-Flag) 51 oder 512, das Zugriffe auf der Grundlage des Zugriffstyps (das heißt Lesen oder Schreiben) steuert. Darüber hinaus enthält jeder PDE und PTE drei „AVAIL"-Bits 506 und 508. Die AVAIL-Bits 506 und 508 sind Bits, bei denen von der Architektur garantiert wird, daß sie zur Verwendung durch Systemprogrammierer zur Verfügung stehen. Das heißt, eine Software kann Werte in die Bits AVAIL für irgendeinen gewünschten Zweck bringen (zum Beispiel zum Aufzeichnen von Informationen, die einer gegebenen Seite zugeordnet sind). Im Ergebnis darf eine Hardware diese Bits für keinen anderen Zweck interpretieren oder verwenden (zum Beispiel für neue Schutzmechanismen auf Seitenebene). Wenn aber diese Felder nicht von Software verwendet werden, sind sie überflüssig.
Kehren wir zur 4 zurück; die AVAIL-Bits in jedem PDE und PTE werden von dem VMM gesetzt und nicht mit Daten aus der Gast-Seitentabellenhierarchie 402 überschrieben, wenn der Inhalt der aktiven Seitentabellenhierarchie 406 modifiziert wird. Bei einem Ausführungsbeispiel werden die AVAIL-Bits gesetzt, wenn die aktive Seitentabellenhierarchie 406 erzeugt wird oder ein neuer Eintrag zu der aktiven Seitentabellenhierarchie 406 hinzugefügt wird.
Bei einem Ausführungsbeispiel werden sämtliche Einträge in der aktiven Seitentabellenhierarchie 406 anfänglich als ungültig markiert (unter Verwendung des P-Flags 516 in jedem PDE und des P-Flags 510 in jedem PTE), um den Initialisierungszustand des TLB, in dem der TLB keine Einträge aufweist, zu emulieren. Nachfolgend, wenn die Gast-Software eine virtuelle Adresse dem Prozessor präsentiert, findet der Prozessor nur ungültige Einträge in der aktiven Seitentabellenhierarchie 406 und es wird ein Seitenfehler erzeugt. Der Seitenfehler überträgt die Kontrolle aus dem Gast-Betriebssystem an den VMM. Der VMM kopiert dann zugehörige Einträge aus der Gast-Seitentabellenhierarchie 402 in die aktive Seitentabellenhierarchie 406, womit die aktive Seitentabellenhierarchie 406 wieder gefüllt wird. Während des Neuauffüllens werden die AVAIL-Bits in der Gast-Seitentabellenhierarchie 402 ignoriert (das heißt die AVAIL-Bits werden nicht in die aktive Seitentabellenhierarchie 406 kopiert).
Der Gast-Software wird es ermöglicht, die Gast-Seitentabellenhierarchie 402 einschließlich Änderungen der Virtuell-Zu-Physikalisch-Abbildung, Genehmigungen, etc. frei zu modifizieren. Demzufolge kann es sein, daß die aktive Seitentabellenhierarchie 406 nicht immer mit der Gast-Seitentabellenhierarchie 402 konsistent ist. Das heißt, die aktive Seitentabellenhierarchie 406 kann veraltet sein, bei spielsweise kann sie zu viele Zugriffe auf ihre Einträge gestatten, falsche Virtuell-Zu-Physikalische-Adreßabbildungen zur Verfügung stellen, etc. Wenn sich aus einer Inkonsistenz zwischen den Hierarchien 402 und 406 Probleme ergeben, gibt das Gast-Betriebssystem einen der Befehle 416 an den physikalischen TLB 408 aus. Diese Befehle führen zu einer Übertragung der Kontrolle von dem Gast-Betriebssystem an den VMM. Der VMM bestimmt dann die Ursache des Befehls und modifiziert den Inhalt der aktiven Seitentabellenhierarchie 406 (beispielsweise entfernt er die Einträge, auf die von der Gast-Software in dem ausgegebenen Befehl Bezug genommen wird, aus der aktiven Seitentabellenhierarchie 406). Während der Modifikation werden die AVAIL-Bits in der Gast-Seitentabellenhierarchie 402 nicht in die aktive Seitentabellenhierarchie 406 kopiert.
Da die AVAIL-Bits in der aktiven Seitentabellenhierarchie 406 ungeändert bleiben, können sie von dem VMM neu beansprucht werden. Sobald sie neu beansprucht sind, können die AVAIL-Bits auf verschiedene Weise verwendet werden. Beispielsweise kann eines der AVAIL-Bits ein Gast/Host-Zugriffsbit (G/H-Zugriffsbit) sein, das den Zugriff auf die Seite durch Gast-Software steuert. Das heißt, der Prozessor könnte einen Zugriff auf die von dem PTE referenzierte Seite nur dann gestatten, wenn der VMM (der Host) abläuft oder abgearbeitet wird, sofern das „G/H"-Bit in einem aktiven PTE gelöscht ist. Sofern das „G/H"-Bit gesetzt ist, kann der Prozessor den Zugriff auf die Seite gestatten, wenn entweder der VMM oder die Gast-Software abgearbeitet werden (laufen).
Das G/H-Bit kann verwendet werden, um Adreßraumkonflikte zwischen dem VMM und einem Gast-Betriebssystem zu lösen. Bei der gegenwärtigen IA-32-ISA tritt ein Adreßraumkonflikt typischerweise auf, weil vorhandene Prozessoren (zum Beispiel IA-32-Mikroprozessoren) es dem VMM nicht gestatten, eine Kontrolle über ein Ereignis zu empfangen, das von dem Gast-Betriebssystem initiiert worden ist (zum Beispiel ein Versuch des Gast-Betriebssystems, auf eine privilegierte Hardware-Ressource zuzugreifen), solange nicht ein Teil des VMM-Codes und/oder der Datenstrukturen in demselben virtuellen Adreßraum wie das Gast-Betriebssystem angeordnet ist. Da jedoch das Gast-Betriebssystem nicht erwartet, daß sich VMM-Code und/oder -Datenstrukturen in demselben Adreßraum aufhalten, könnte es versuchen, auf einen Bereich zuzugreifen, der in diesem Adreßraum von dem VMM belegt wird, was einen Adreßraumkonflikt zwischen Gast-Betriebssystem und dem VMM bewirkt. Dieser Konflikt könnte zu einem abnormen Abbruch von von dem VMM oder dem Gast-Betriebssystem durchgeführten Operationen führen.
Das „G/H"-Bit verhindert das Auftreten eines Adreßraumkonflikts zwischen dem Gast-Betriebssystem und dem VMM. Insbesondere mit dem „G/H"-Bit findet der VMM einen Platz in dem virtuellen Adreßraum des Gast-Betriebssystems, um seinen Code und seine Datenstrukturen abzubilden, und sichert, daß das zughörige „G/H"-Bit gelöscht wird, um den VMM-Code und die VMM-Datenstrukturen gegenüber Zugriffen durch das Gast-Betriebssystem zu schützen. Wenn ein Versuch des Gast-Betriebssystems zum Zugreifen auf den von dem VMM belegten Adreßraum erfaßt wird, werden der VMM-Code und die Datenstrukturen in einen nicht benutzten Bereich innerhalb des virtuellen Adreßraums des Gast-Betriebssystems neu abgebildet, und das Gast-Betriebssystem ist in der Lage, auf den gewünschten Adreßraum zuzugreifen.
Das „G/H"-Bit kann auch verwendet werden, um Adreßumschaltungen in den ISAs zu vereinfachen, die nicht erfordern, daß ein Teil des VMM-Codes und/oder der Datenstrukturen sich in dem Adreßraum des Gast-Betriebssystems aufhalten, um eine Kontrolle über ein von dem Gast-Betriebssystem initiiertes Ereignis zu erhalten. Wenn beispielsweise die Gast-Software von einer VMX-Operation gesteuert wird, bewirkt ein VM-Verlassen (Exit), daß ein vollständiges Adreßraumumschalten vor dem Übertragen der Kontrolle an dem VMM auftritt, so daß kein Erfordernis vorhanden ist, daß ein Teil des VMM-Codes und/oder der VMM-Datenstrukturen sich in dem Adreßraum des Gast-Betriebssystems aufhält. Jedoch ist die Ausführung einer vollständigen Adreßumschaltung für jedes VM-Verlassen aufwendig. Dementsprechend kann die Leistungsfähigkeit optimiert werden, indem ein Teil des VMM-Codes und/oder der VMM-Datenstrukturen in dem Adreßraum des Gast-Betriebssystems abgearbeitet wird und das G/H-Bit verwendet wird, um den VMM-Code und die Datenstrukturen gegenüber Zugriffen aus dem Gast-Betriebssystem zu schützen, wie es oben erörtert wurde.
Bei einem anderen Beispiel könnten zwei der AVAIL-Bits von dem Prozessor als Ausführungs-Privileg-Bit "X" (Execute) und Lese-Privileg-Bit "R" (Read) interpretiert werden, während das vorhandene „R/W"-Bit als Schreib-Privileg-Bit „W" (Write) neu interpretiert werden könnte. Im Ergebnis können verschiedene Arten von Seitenzugriffen unabhängig gesteuert werden. Beispielsweise könnte der Prozessor die Ausführung irgendwelcher Befehle aus der Seite verhindern, wenn das X-Bit gelöscht ist, und die Ausführung von Befehlen aus der Seite erlauben, wenn das X-Bit gesetzt ist. In ähnlicher Weise könnte das R-Bit Datenlesezugriffe auf die Seite steuern und das W-Bit könnte Datenschreibzugriffe auf die Seite steuern.
Die Kombination von unabhängig setzbaren R-, W- und X-Bits kann bei einer Verwendung mit dynamischen binären Übersetzern vorteilhaft sein, welche Befehlsbinärzahlen für verschiedene Zwecke, wie beispielsweise eine Befehlssatzemulation, ein Adreß-Tracing, etc. modifizieren. Beispielsweise könnte die Kombination der R-, W- und X-Bits eine Behandlung von selbstmodifizierenden Code (SMC) und selbst-überprüfenden Code (SEC) durch einen dynamischen binären Übersetzer auf IA-32-Prozessoren vereinfachen. Das heißt ein dynamischer binärer Übersetzer könnte die Kombination der R-, W- und X-Bits 001 auf einer Seite setzen, die übersetzte Befehle hält, womit die Ausführung des Codes durch den Prozessor gestattet wird, während Versuche des Codes erfaßt werden, die Befehlsbits des Codes zu modifizieren oder zu lesen (welche sich von den ursprünglichen Befehlen des Codes infolge der Übersetzung oder von Patching-Aktionen des binären Übersetzers unterscheiden können). Bei Seiten, die eine Mischung von Befehlen und Daten halten, kann ein binärer Übersetzer die Bits R und W in geeigneter Weise setzen, aber das X-Bit auf 0 halten, so daß der Code direkt auf Daten auf der Seite zugreifen kann, aber nicht in der Lage ist, Befehle auf der Seite auszuführen. Ein Ver such zum Ausführen von Befehlen auf der Seite bewirkt einen Übergang zu dem VMM, welcher dann die fehlgeschlagenen Befehle emulieren kann.
Die Kombination der Bits R, W und X könnte außerdem eine sichere Ausführung von Code gestatten, der einen eingebetteten geheimen Schlüssel oder Algorithmus enthält. Das heißt, der VMM könnte den einen eingebetteten geheimen Schlüssel oder Algorithmus enthaltenden Code auf eine Seite abbilden, die durch einen Eintrag referenziert wird mit der Kombination der Bits R, W und X, die auf 001 gesetzt ist. Im Ergebnis kann der sichere Code aufgerufen und ausgeführt werden, und gleichzeitig sind der eingebettete geheime Schlüssel oder Algorithmus gegenüber Lesen oder Modifizieren durch anderen Code, der im gleichen Adreßraum abläuft, geschützt.
Die Kombination der Bits R, W und X kann ferner verwendet werden, um Debugging-Operationen zu unterstützen. Insbesondere können vorhandene Seiten, die Daten halten, mit einer Kombination der Bits R, W und X abgebildet werden, die entweder auf 010 oder auf 110 von einem sich in dem VMM aufhaltenden Debugger abgebildet werden können. Mit diesen Schutzmechanismen kann der Debugger sofort feststellen, wenn problematischer Code versehentlich damit begonnen hat, Daten so auszuführen, als ob sie Befehle wären.
In noch einem anderen Beispiel könnte eines der AVAIL-Bits mit dem vorhandenen U/S-Bit kombiniert werden, um anzuzeigen, ob eine gegebene Seite durch einen Code zugreifbar ist, der auf einem bestimmten Privilegierungsniveau abläuft. Der VMM kann dann zwei Bits verwenden, um das höchste Privilegierungsniveau zu spezifizieren, auf welchem eine gegebene Seite zugreifbar ist. Beispielsweise könnte der Wert 00 anzeigen, daß nur der Code, der auf dem Privilegierungsniveau 0 abläuft, auf eine gegebene Seite zugreifen kann, der Wert 01 anzeigen, daß der Code, der auf den Privilegierungsniveaus 0 oder 1 abläuft, auf die Seite zugreifen kann, der Wert 10 anzeigen, daß der Code, der auf den Privilegierungsniveaus 0, 1 oder 2 abläuft, auf die Seite zugreifen kann, und der Wert 11 anzeigen, daß der Code, der auf einem beliebigen Privilegierungsniveau ab läuft, auf die Seite zugreifen kann. Die Verwendung von zwei Bits zum Steuern des Privilegierungsniveaus des zugreifenden Codes schafft einen höheren Grad der Flexibilität, macht es beispielsweise möglich, daß Gerätetreiber auf dem Privilegierungsniveau 1 und der Rest des Betriebssystem-Kernels auf dem Privilegierungsniveau 0 abgearbeitet wird, während Schutzmechanismen auf Seitenebene zum Schützen des Ring-0-Kernels gegen bösartige oder fehlerhafte Ring-1-Gerätetreiber verwendet werden. Diese Schutzmechanismen auf Seitenniveau sind mit dem vorhandenen U/S-Bit nicht möglich, welches die Ring 0, 1 und 2 zusammen als Supervisor(S)-Privilegniveau und Ring 3 als Benutzer(U)-Privilegniveau kennzeichnet.
Die oben unter Bezugnahme auf das G/H-Bit, die unabhängig setzbaren R-, W- und X-Bits und die Kombination des U/S-Bits mit einem AVAIL-Bit beschriebene Funktionalität kann gleichzeitig erreicht werden, indem die Bedeutungen der drei vorhandenen P-, R/W und U/S-Bits neu definiert werden und sie mit den drei neu beanspruchten AVAIL-Bits kombiniert werden. Insbesondere können drei der sich ergebenden sechs Bits als unabhängig setzbare R-, W- und X-Bits verwendet werden, zwei der verbleibenden drei Bits können verwendet werden, um den höchsten Ring zu kennzeichnen, auf welchen der Code Zugriffsrechte hat, und das letzte Bit kann als G/H-Bit verwendet werden. Für diese Interpretation der Bits könnte die Seite als „nicht vorhanden" angesehen werden, wenn die Kombination der Bits R, W und X eine Einstellung von 000 aufweist.
Es sei angemerkt, daß die vorhandenen Felder innerhalb der aktiven Adreßübersetzungsdatenstrukturen auf verschiedenartigste Weise interpretiert und verwendet werden können, die von den oben beschriebenen Möglichkeiten abweichen.

Claims

Verfahren (300), wobei: festgestellt wird (306), dass eine Modifikation des Inhalts einer von einem Virtuelle-Maschine-Monitor (VMM) verwalteten aktiven Adressübersetzungsdatenstruktur (206) erforderlich ist, wobei der Inhalt der aktiven Adressübersetzungsdatenstruktur (206) von einem Prozessor verwendet wird, um daraus Adress-Übersetzungen abzuleiten und in einem Übersetzungsnachschlagepuffer (TLB) (204) cache-zu-speichern; ein Eintrag (210) in der aktiven Adressübersetzungsdatenstruktur (206) modifiziert wird, so dass der Eintrag (210) mit Ausnahme eines Teils (214) einem entsprechenden Eintrag (212) in einer Gast-Adressübersetzungsdatenstruktur (208) entspricht, wobei die Gast-Adressübersetzungsdatenstruktur (208) von einer Gast-Software für Adressübersetzungsoperationen verwendet wird, wobei der Teil (214) des Eintrags (210), der nicht modifiziert wird (308), einem für eine betriebliche Verwendung durch die Gast-Software vorgesehenen Feld (216) innerhalb des Eintrags (212) der Gast-Adressübersetzungsdatenstruktur (208) entspricht und einen oder mehrere Zugriffssteuerindikatoren einschließt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass wenigstens einer der Zugriffssteuerindikatoren vor dem Modifizieren des Eintrags (210) der aktiven Adressübersetzungsdatenstruktur gesetzt wird (302).
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Zugriffssteuerindikator gesetzt wird, wenn der Eintrag (210) erzeugt wird.
Verfahren nach einem der Ansprüche 1–3, dadurch gekennzeichnet, dass die aktive Adressübersetzungsdatenstruktur (206) eine aktive Seitentabellenhierarchie ist.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass der Eintrag (210) in der aktiven Adressübersetzungsdatenstruktur (206) ein Seitentabelleneintrag oder ein Seitenverzeichniseintrag ist, und dass der wenigstens eine Zugriffssteuerindikator wenigstens ein der System-Software zur Verfügung stehendes AVAIL-Bit (506; 508) ist.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass eines der AVAIL-Bits (506; 508) ein Gast/Host-Zugriffsbit ist, das einen Zugriff auf eine entsprechende Seite in der Seitentabellenhierarchie durch die Gast-Software steuert.
Verfahren nach einem der Ansprüche 4 bis 6, dadurch gekennzeichnet, dass die Zugriffssteuerindikatoren einen Ausführungsprivilegindikator, der eine Ausführung von Befehlen aus einer zugehörigen Seite in der Seitentabellenhierarchie steuert, und einen Leseprivilegindikator, der Lesezugriffe auf die zugehörige Seite in der Seitentabellenhierarchie steuert, einschließen.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass ein Lese/Schreibbit als Schreibprivilegindikator neu interpretiert wird, der Schreibzugriffe auf die zugehörige Seite in der Seitentabellenhierarchie steuert.
Verfahren nach einem der Ansprüche 4 bis 8, dadurch gekennzeichnet, dass der wenigstens eine Zugriffssteuerindikator einen Privilegniveauzugriffsindikator einschließt, der Zugriffe auf eine zugehörige Seite in der Seitentabellenhierarchie durch einen auf dem spezifizierten Privilegniveau abgearbeiteten Befehlscode kontrolliert.