DE112004000498T5

DE112004000498T5 - Verfahren zur CPU-Simulation unter Verwendung virtueller Maschinenweiterungen

Info

Publication number: DE112004000498T5
Application number: DE112004000498T
Authority: DE
Inventors: Konstantin Levit-Gurevich; Igor Liokumovich; Ido Shamir
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2003-03-24
Filing date: 2004-02-11
Publication date: 2006-03-02
Also published as: GB0513157D0; GB2414579A; CN1973264B; US20040193394A1; CN1973264A; WO2004095283A3; WO2004095283A2

Abstract

Computersystem, das umfaßt:
eine zentrale Verarbeitungseinheit (CPU) zum Erzeugen und Steuern einer virtuellen Maschine, auf der simulierter Befehlscode läuft, und zum Erzeugen einer Abstraktion einer realen Maschine, so daß der Betrieb eines realen Betriebssystems für das Computersystem nicht behindert ist.

Description

COPYRIGHT-HINWEIS
Hierin enthalten ist Material, das Copyright-Schutz unterliegt. Der Copyright-Inhaber hat keinen Einwand gegen die Faksimilereproduktion der Patentoffenbarung, wie sie in den Patentakten oder -aufzeichnungen der Patent- und Warenzeichenbehörde erscheint, durch irgendeine Person, behält sich aber ansonsten alle Rechte auf das Copyright vor.
ERFINDUNGSGEBIET
Die vorliegende Erfindung betrifft Simulatoren für CPUs (zentrale Verarbeitungseinheit); die vorliegende Erfindung betrifft insbesondere das Verwenden einer direkten Ausführung von simuliertem Code auf einer CPU.
ALLGEMEINER STAND DER TECHNIK
Softwaresimulatoren für CPUs (z.B. Gambit, Archsim, usw.) besitzen einen großen Einsatzbereich in vielen Bereichen hinsichtlich Design, Validierung und Abstimmung integrierter Schaltungen. Diese Simulatoren werden üblicherweise für die Pre-Silicon-Softwareentwicklung (z.B. BIOS, Betriebssysteme, Compiler, Applikationen usw.), zur Architekturvalidierung (funktionell und Leistung) und mehr verwendet. Ein Benutzer kann eine Befehlssatzarchitektur (ISA – Instruction Set Architecture) einer neuen CPU bewerten, indem er Benchmarks auf einer Host-Maschine ausführt, auf der der Simulator läuft.
Auf der Basis der von dem Simulator erzeugten Ergebnisse kann ein Benutzer das neue CPU-Design entsprechend modifizieren oder verifizieren. Außerdem kann der Simulator erweitert werden, um das Verhalten einer ganzen PC-Plattform zu simulieren, einschließlich Busse und E/A-Einrichtungen (beispielsweise einen SoftSDV-Plattformsimulator). Eine mögliche Eingabe für einen derartigen Simulator kann ein als „simuliertes" oder „Gast"-OS bezeichnetes Betriebssystem sein.
Die permanente Zunahme sowohl des Umfangs als auch bei der Komplexität des simulierten Codes (Betriebssysteme und Applikationen) erfordert eine Verbesserung gegenwärtiger Simulationstechniken und die Einführung neuer Technologien, um eine signifikante Simulationsbeschleunigung zu erreichen. Wenn die simulierte CPU und die Host-CPU-Architekturen sehr ähnlich (oder identisch) sind, können die simulierten Befehle systemspezifisch (native) laufen. Die meisten Betriebssysteme für PCs übernehmen jedoch eine vollständige Kontrolle über die Maschinenressourcen. Wenn das simulierte Betriebssystem systemspezifisch laufen kann, kommt es somit in einen Konflikt mit dem Host-Betriebssystem wegen PC-Ressourcen (CPU, Einrichtungen, Speicher, usw.).
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Veranschaulicht wird die Erfindung beispielhaft, jedoch nicht beschränkend in den Figuren der beiliegenden Zeichnungen, in denen gleiche Referenzen ähnliche Elemente bezeichnen und in denen:
1 ein Blockschaltbild einer Ausführungsform eines Computersystems ist;
2 auf hoher Ebene eine Architektur einer Ausführungsform einer Simulationsumgebung darstellt und
3 ein Flußdiagramm einer Ausführungsform der Operation eines Full-Platform-Simulators ist.
AUSFÜHRLICHE BESCHREIBUNG
Ein Verfahren zur Verwendung von Hardwaresupport zur Virtualisierung, um Konflikte zwischen einem Host-Betriebssystem (OS) und einem Gast-OS, um eine vollständige Virtualisierung zu erhalten, wird beschrieben. In der folgenden ausführlichen Beschreibung der vorliegenden Erfindung werden zahlreiche spezifische Einzelheiten dargelegt, damit man ein eingehendes Verständnis der vorliegenden Erfindung erhält. Für den Fachmann ist jedoch offensichtlich, daß die vorliegende Erfindung ohne diese spezifischen Einzelheiten praktiziert werden kann. In anderen Fällen sind wohlbekannte Strukturen und Einrichtungen statt im Detail in Blockdiagrammform gezeigt, um zu vermeiden, daß die vorliegende Erfindung unklar wird.
Eine Bezugnahme in der Patentschrift auf „eine Ausführungsform" bedeutet, daß ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Charakteristik, die in Verbindung mit der Ausführungsform beschrieben sind, in mindestens einer Ausführungsform der Erfindung enthalten ist. Die Fälle des Auftretens des Ausdrucks „in einer Ausführungsform" an verschiedenen Stellen in der Patentschrift beziehen sich nicht notwendigerweise alle auf die gleiche Ausführungsform.
1 ist ein Blockschaltbild einer Ausführungsform eines Computersystems 100. Das Computersystem 100 umfaßt eine an einen Bus 105 gekoppelte zentrale Verarbeitungseinheit (CPU) 102. In einer Ausführungsform ist die CPU 102 ein Prozessor der Pentium^®-Familie von Prozessoren einschließlich der Pentium^®-II-Prozessorfamilie, Pentium^®-III-Prozessoren und Pentium^®-IV-Prozessoren, erhältlich von der Firma Intel Corporation in Santa Clara, Kalifornien, USA. Alternativ können andere CPUs verwendet werden.
Auch ein Chipsatz 107 ist an den Bus 105 gekoppelt. Der Chipsatz 107 umfaßt einen MCH (Memory Control Hub) 110. Der MCH 110 kann einen Speichercontroller 112 umfassen, der an einen Hauptsystemspeicher 115 gekoppelt ist. Der Hauptsystemspeicher 115 speichert Daten und Sequenzen von Befehlen, die von der CPU 102 oder irgendeiner anderen Einrichtung, die im System 100 enthalten ist, ausgeführt werden. Bei einer Ausführungsform umfaßt der Hauptsystemspeicher 115 einen dynamischen Direktzugriffsspeicher (DRAM); der Hauptsystemspeicher 115 kann jedoch auch unter Verwendung anderer Speicherarten implementiert werden. Auch zusätzliche Einrichtungen können an den Bus 105 gekoppelt sein, wie etwa mehrere CPUs und/oder mehrere Systemspeicher.
Der MCH 110 kann auch eine Grafikschnittstelle 113 umfassen, die an einen Grafikbeschleuniger 130 gekoppelt ist. In einer Ausführungsform ist die Grafikschnittstelle 113 an den Grafikbeschleuniger 130 über einen beschleunigten Grafikport (AGP) gekoppelt, der entsprechend einer von der Firma Intel Corporation in Santa Clara, Kalifornien, USA, entwickelten AGP Specification Revision 2.0-Schnittstelle arbeitet.
Außerdem koppelt die Hub-Schnittstelle den MCH 110 an einen Eingangs-/Ausgangssteuer-Hub (ICH) 140 über eine Hub-Schnittstelle. Der ICH 140 bietet eine Schnittstelle zu Eingabe-/Ausgabe-(E/A)-Einrichtungen innerhalb des Computersystems 100. Der ICH 140 kann an einen Peripheral-Component-Interconnect-Bus gekoppelt sein, der einem von der Firma PCI Special Interest Group of Portland, Oregon, USA, entwickelten Bus Specification Revision 2.1 entspricht. Somit umfaßt der ICH 140 eine PCI-Brücke 146, die eine Schnittstelle zu einem PCI-Bus 142 liefert. Die PCI-Brücke 146 liefert einen Datenweg zwischen CPU 102 und Peripherieeinrichtungen.
Der PCI-Bus 142 umfaßt eine Audioeinrichtung 150 und ein Laufwerk 155. Der Durchschnittsfachmann versteht jedoch, daß andere Einrichtungen an den PCI-Bus 142 gekoppelt sein können. Zusätzlich erkennt der Durchschnittsfachmann, daß CPU 102 und MCH 110 kombiniert sein könnten, um einen einzelnen Chip auszubilden. Ein weiterer Grafikbeschleuniger 130 kann in anderen Ausführungsformen im MCH 110 enthalten sein.
2 veranschaulicht eine Ausführungsform der Architektur 200 für eine Simulationsumgebung. Die Architektur 200 umfaßt Hardware 205, auf der die Simulationsumgebung läuft. Gemäß einer Ausführungsform unterstützt die Hardware 205 Lagrande-Technology. Lagrande-Technology (LT) ist eine Technologie, die die Unterstützung für virtuelle Maschinen auf IA-32-Prozessoren gestattet. Unterstützung ist gegeben für zwei Hauptklassen von Software: Monitor (oder Host) und Gast. Monitor-Software (oder einfacher „der Monitor") sollte die volle Kontrolle der CPU 102 haben, wenn sie läuft. Der Monitor liefert Gastsoftware mit einer Prozessorabstraktion und gestattet ihre Ausführung auf der CPU 102. Der Monitor sollte jedoch in der Lage sein, die Kontrolle der Prozessorressourcen, des physischen Speichers, des Interruptmanagements und des E/A beizubehalten.
Gemäß einer Ausführungsform wird Unterstützung der CPU 102 zur Virtualisierung mit einer neuen Form von Prozessorbetrieb bereitgestellt, die als Virtual-Machine-Extension-(VMX (Erweiterung einer virtuellen Maschine))-Betrieb bezeichnet wird. In dem VMX-Betrieb wird ein neuer Befehlssatz ermöglicht. Außerdem werden zwei Arten von Control-Transfers, die als VM-Entries und VM-Exits bezeichnet werden, ermöglicht. Diese Übergänge werden von einer neuen Struktur verwaltet, die als eine virtuelle-Maschine-Steuerstruktur (oder VMCS (virtual machine command structure)) bezeichnet wird.
Alle Gastsoftware läuft im VMX-Betrieb. Die die Ausführung des VMX-Betriebs steuernde VMCS kann bestimmte Ereignisse, Operationen und Situationen verursachen, die VM-Exits verursachen. Ein VM-Exit bewirkt, daß der Prozessor die Steuerung an einen Monitoreintrittspunkt überträgt, der durch Steuern der VMCS bestimmt ist. Der Monitor erhält somit die Kontrolle über den Prozessor bei einem VM-Exit und kann eine Aktion durchführen, die für das Ereignis, die Operation oder Situation angemessen ist, das bzw. die den VM-Exit verursachte. Er kann dann zu dem Kontext zurückkehren, verwaltet durch die VMCS über einen VM-Entry.
Wenn der VM-Monitor die VMCS ordnungsgemäß konstruiert, kann sie verhindern, daß Gastsoftware bestimmt, daß sie im VMX-Betrieb läuft. Die VMCS wurde so ausgelegt, daß sie Einrichtungen enthält, die es dem VM-Monitor gestatten würden, die CPU 102 zu virtualisieren.
Wieder unter Bezugnahme auf 2 umfaßt die Simulationsumgebung eine Direct Execution Umgebung 210 und eine Host-OS-Umgebung 220. Die Direct Execution Environment 210 umfaßt Gastcode (OS und/oder Applikationen), die auf einer virtuellen Maschine laufen. Bei Start (oder Wiederaufnahme) einer virtuellen Maschine fuhrt die Hardware 205 eine vollständige Kontextumschaltung vom Kontext eines Host-OS zu dem des Gast-OS durch und gestattet, daß der Gast-Code (auf einer ursprünglichen Privilegebene und bei den ursprünglichen virtuellen Adressen) systemspezifisch (natively) auf der CPU 102 löuft. Die CPU 102 führt übliche Architekturprüfungen aus. Während die CPU 102 auf der virtuellen Maschine läuft, führt sie zusätzliche Prüfungen aus, um Virtualisierungsereignisse (unten beschrieben) zu entdecken.
Die Host-OS-Umgebung 220 umfaßt einen Full Platform Simulator (Simulator für eine volle Plattform) 222 und einen Monitor 224. Bei einer Ausführungsform läuft ein Full Platform Simulator 222 in einer Benutzerprivilegebene. Teile des Monitors 224 laufen mit dem Systemprivileg und Teile laufen in der Benutzerprivilegebene. Der Monitor 224 steuert die Ausführung des Gast-Codes und stellt eine Brücke zwischen der Direct Execution Umgebung 210 und der Host-OS-Umgebung 220 dar. Der Monitor 224 erzeugt eine virtuelle Maschine (VM) und nimmt sie wieder auf durch Verwendung von Unterstützung der Hardware 205.
Außerdem holt sich der Monitor 224 die Kontrolle von der virtuellen Maschine zurück, wenn der auf der virtuellen Maschine laufende Code versucht, eine sensitive Aktion auszuführen. Diese sensitiven Aktionen, die in der VM nicht ausgeführt werden dürfen, werden als „Virtualisierungsereignisse" bezeichnet. Bei einer Ausführungsform konfiguriert der Monitor 224 die CPU, bei der Virtualisierungsereignisse geprüft werden sollten, während sie auf der virtuellen Maschine laufen, sowie, welche Zustandskomponenten bei Wiederaufnahme der VM geladen/wiederhergestellt werden sollten.
Gemäß einer Ausführungsform umfassen Virtualisierungsereignisse Hardware Interrupts, Versuche zur Änderung des virtuellen Adreßraums (Page Tables), Zugang zu Geräten (z.B. E/A-Befehle), Steuerregisterzugang, Page-Faults-Verarbeitung usw. Der Monitor 224 führt die erforderliche Zustandssynchronisierung durch und verarbeitet ein Virtualisierungsereignis.
Der Monitor 224 analysiert den Grund, der den Austritt aus der virtuellen Maschine bewirkte, und führt eine entsprechende Virtualisierungs-Operation durch. Bei einer Ausführungsform verarbeitet der Monitor 224 das Virtualisierungsereignis und nimmt die Direct Execution Umgebung wieder zurück auf. Alternativ gibt der Monitor 224 die Steuerung zur Simulation des einen Fehler erzeugenden Befehls an den Full Platform Simulator 222 weiter.
Bei einer weiteren Ausführungsform führt der Monitor 224 Virtualisierungsoperationen auf eine Weise aus, die verhindert, daß das Gast-OS der Integrität des Host-OS schadet. Beispielsweise handhabt der Monitor 224 in der virtuellen Maschine verwendete Page Tables und bildet die virtuellen Gast-Adressen auf die vom Hostspeicher zugewiesenen anstatt auf vom Gast-OS beabsichtigte physische Adressen ab.
Der Platform Simulator 222 läuft als ein regulärer Prozeß auf dem Host-OS. 3 ist ein Flußdiagramm einer Ausführungsform des Betriebs des Full Platform Simulators 222. Bei dem Verarbeitungsblock 310 beginnt die Simulation. Beim Entscheidungsblock 320 bestimmt der Platform Simulator 222, ob zur Direct Execution umgeschaltet werden soll.
Falls der Platform Simulator 222 entscheidet, zur Direct Execution umzuschalten, wird der Monitor 224 mit einer Anforderung zum Start (oder zur Wiederaufnahme) der Direct Execution aufgerufen, und ein Gastzustand wird virtualisiert, Verarbeitungsblock 330. Ansonsten geht die Simulation beim Platform Simulator 222 weiter, Verarbeitungsblock 380. Beim Verarbeitungsblock 340 wird die virtuelle Maschine gestartet (oder wiederaufgenommen). Danach beginnt die virtuelle Maschine, den Gast-OS-Code abzuarbeiten.
Zu einem bestimmten Zeitpunkt während des Laufens des Gast-OS-Codes ereignet sich ein sensitives (oder Virtualisierungs-)Ereignis. Deshalb wird bei Verarbeitungsblock 350 aus der virtuellen Maschine ausgestiegen, und der aktuelle Zustand wird gesichert/wiederhergestellt. Bei Entscheidungsblock 360 wird bestimmt, ob das sensitive Ereignis ein komplexes Ereignis ist. Wenn das Ereignis kein komplexes Ereignis ist, ist das Ereignis ein Virtualisierungsereignis, und das Virtualisierungsereignis wird bei Verarbeitungsblock 365 verwaltet. Danach wird die Steuerung zum Verarbeitungsblock 330 zurückgegeben, wo der Gastzustand virtualisiert wird.
Wenn das Ereignis ein komplexes Ereignis ist, wird der Gastzustand entvirtualisiert, Verarbeitungsblock 370. Bei Verarbeitungsblock 380 werden wieder Befehle simuliert. Bei Entscheidungsblock 390 wird bestimmt, ob die Simulation geendet hat. Falls nicht, wird die Steuerung zum Verarbeitungsblock 310 zurückgegeben, wo die Simulation weitergeht. Ansonsten wird die Simulation gestoppt.
Die obige Beschreibung beschreibt eine Virtual-Machine-Architektur, die eine Unterstützung für die Erzeugung, Beibehaltung und Steuerung einer virtuellen Maschine ermöglicht, die Gast-Code (simulierten Code) abarbeiten kann, während sie eine volle Abstraktion einer realen Maschine erzeugt. Somit werden Virtual Machine Extensions für die leichte Detektion sensitiver CPU-Ereignisse verwendet, was zu der Fähigkeit führt, zwischen einer virtuellen Maschine, auf der Gast-Code (oder simulierter Code) läuft, und einem Virtual-Machine-Monitor, der eine Komponente der Host-Software ist, umzuschalten.
Während für einen Durchschnittsfachmann auf dem Gebiet nach der Lektüre der obigen Beschreibung ohne Zweifel viele Änderungen und Modifikationen der vorliegenden Erfindung offensichtlich sind, versteht sich, daß jede besondere Ausführungsform, die gezeigt und über eine Veranschaulichung beschrieben worden ist, in keiner Weise als einschränkend angesehen werden soll. Deshalb sollen Bezugnahmen auf Einzelheiten verschiedener Ausführungsformen den Schutzbereich der Ansprüche nicht einschränken, die selbst nur jene Merkmale aufführen, die als für die Erfindung wesentlich angesehen werden.
ZUSAMMENFASSUNG
Gemäß einer Ausführungsform wird ein Computersystem offenbart. Das Computersystem umfaßt eine zentrale Verarbeitungseinheit (CPU) zum Erzeugen und Steuern einer virtuellen Maschine, die simulierten Befehlscode abarbeitet, und zum Erzeugen einer Abstraktion einer realen Maschine, so daß der Betrieb eines realen Betriebssystems für das Computersystem nicht behindert ist.

Claims

Computersystem, das umfaßt: eine zentrale Verarbeitungseinheit (CPU) zum Erzeugen und Steuern einer virtuellen Maschine, auf der simulierter Befehlscode läuft, und zum Erzeugen einer Abstraktion einer realen Maschine, so daß der Betrieb eines realen Betriebssystems für das Computersystem nicht behindert ist.
Computersystem nach Anspruch 1, wobei auf der CPU der simulierte Befehlscode und das reale Betriebssystem laufen.
Computersystem nach Anspruch 1, das weiterhin umfaßt: eine direkte Ausführungsumgebung zum Speichern simulierten Befehlscodes und zugehöriger Daten und eine Host-Betriebssystemumgebung.
Computersystem nach Anspruch 3, wobei die Hostbetriebssystemumgebung umfaßt: einen Monitor zum Erzeugen der virtuellen Maschine unter Verwendung der Hardware und einen Plattformsimulator zum Ausführen von Simulationen von Virtualisierungsereignissen;
Computersystem nach Anspruch 4, wobei der Monitor Virtualisierungsoperationen ausführt.
Computersystem nach Anspruch 5, wobei der Monitor die Steuerung immer dann von der virtuellen Maschine erhält, wenn die virtuelle Maschine versucht, ein Virtualisierungsereignis auszuführen.
Computersystem nach Anspruch 6, wobei der Monitor eine Liste von durch die virtuelle Maschine zu prüfenden Virtualisierungsereignissen setzt.
Computersystem nach Anspruch 7, wobei der Monitor die Steuerung an den Monitor zur Verarbeitung des Virtualisierungsereignisses weitergibt.
Computersystem nach Anspruch 8, wobei der Monitor auf die Bestimmung der Art des Virtualisierungsereignisses eine bestimmte Virtualisierungsoperation durchführt.
Computersystem nach Anspruch 9, wobei der Monitor das Virtualisierungsereignis verarbeitet und die Ausführung an den Monitor zurückgibt.
Computersystem nach Anspruch 9, wobei der Monitor die Steuerung an den Plattformsimulator zur Simulierung des Virtualisierungsereignisses weitergibt.
Computersystem nach Anspruch 8, bei welchem die Monitor-Virtualisierungsoperation verhindert, daß der simulierte Befehlscode das reale Betriebssystem beeinflußt.
Verfahren, das umfaßt: Simulieren von Befehlscode auf einer zentralen Verarbeitungseinheit (CPU), die Virtual Machine Extensions (VMX) implementiert; Virtualisieren von simuliertem Befehlscode; Starten einer virtuellen Maschine (VM) auf der CPU und Ausführen von simuliertem Befehlscode auf der VM.
Verfahren nach Anspruch 13, das weiterhin umfaßt: Detektieren eines sensitiven Ereignisses; Verlassen der VM und Analysieren des sensitiven Ereignisses.
Verfahren nach Anspruch 14, das weiterhin umfaßt: Bestimmen, ob das sensitive Ereignis ein komplexes Ereignis ist, und Virtualisieren des simulierten Befehlscodes, wenn das sensitive Ereignis kein komplexes Ereignis ist.
Verfahren nach Anspruch 15, welches weiterhin ein Wiederaufnehmen der VM umfaßt, nachdem der simulierte Befehlscode virtualisiert ist.
Verfahren nach Anspruch 15, das weiterhin umfaßt: Entvirtualisieren des simulierten Befehlscodes, wenn das sensitive Ereignis ein komplexes Ereignis ist und Simulieren des Befehlscodes.
System, das umfaßt: Hardware zum Erzeugen und Steuern einer virtuellen Maschine, auf der simulierter Befehlscode läuft, und zum Erzeugen einer Abstraktion einer realen Maschine, so daß der Betrieb eines realen Betriebssystems für das Computersystem nicht behindert ist; eine direkte Ausführungsumgebung zum Speichern simulierten Befehlscodes und zugehöriger Daten und eine Host-Betriebssystemumgebung.
System nach Anspruch 18, wobei die Hostbetriebssystemumgebung umfaßt: einen Monitor zum Erzeugen der virtuellen Maschine unter Verwendung der Hardware und einen Plattformsimulator zum Ausführen von Simulationen von Virtualisierungsereignissen;
System nach Anspruch 19, wobei der Monitor Virtualisierungsoperationen ausführt.
System nach Anspruch 20, wobei der Monitor die Steuerung immer dann von der virtuellen Maschine erhält, wenn die virtuelle Maschine versucht, ein Virtualisierungsereignis auszuführen.
Computersystem nach Anspruch 21, wobei der Monitor eine Liste von durch die virtuelle Maschine zu prüfenden Virtualisierungsereignissen setzt.
System nach Anspruch 22, wobei der Monitor auf die Bestimmung der Art des Virtualisierungsereignisses eine bestimmte Virtualisierungsoperation durchführt.
System nach Anspruch 23, wobei der Monitor das Virtualisierungsereignis verarbeitet und die direkte Ausführungsumgebung wieder aufnimmt.
Computersystem nach Anspruch 24, wobei der Monitor die Steuerung an den Plattformsimulator zur Simulierung des Virtualisierungsereignisses weitergibt.
Computersystem nach Anspruch 23, wobei der Monitor Operationen derart virtualisiert, daß verhindert wird, daß der simulierte Befehlscode das reale Betriebssystem beeinflußt.