DE112004003066B4

DE112004003066B4 - Verwendung mehrerer Monitore virtueller Maschinen zur Abwicklung priviligierter Ereignisse

Info

Publication number: DE112004003066B4
Application number: DE112004003066.8T
Authority: DE
Inventors: Gilbert Neiger; Steven Bennett; Alain Kagi; Stalinselvaraj Jeyasingh; Andrew Anderson; Richard Uhlig; Erik Cota-Robles; Scott Rodgers; Lawrence Smith III
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2003-09-15
Filing date: 2004-09-10
Publication date: 2016-07-28
Anticipated expiration: 2024-09-11
Also published as: GB2420889B; WO2005029326A1; TW200513837A; TWI259950B; DE112004003080B4; CN103064725B; CN102693148B; CN1849585A; HK1084472A1; CN101976202A; JP4354488B2; GB0602500D0; CN102693148A; GB2420889A; CN1849585B; CN101976202B; US20050071840A1; US7424709B2; CN103064725A; DE112004001697T5

Abstract

Prozessor mit einer Leitwegelogik in Form eines Mikrocodes, einer programmierbaren Logik oder einer hartcodierten Logik, wobei die Leitwegelogik ausgebildet ist, das folgende Verfahren auf dem Prozessor auszuführen, wenn darauf mehrere Virtual Machine Monitore parallel eingerichtet sind: Erkennen des Auftretens eines privilegierten Ereignisses während des Betriebs von Gast-Software auf einer virtuellen Maschine (VM) oder während des Betriebs eines Virtual Machine Monitors, wobei privilegierte Ereignisse von der Gast-Software nicht behandelt werden können und die mehreren Virtual Machine Monitore eingerichtet sind, privilegierte Ereignisse zu behandeln; Ermitteln des Typs des erkannten privilegierten Ereignisses; Ermitteln eines Wertes aus einem Prozessor-Register oder einem Speicher im Plattform-Chipsatz, das bzw. der mit dem Typ des privilegierten Ereignisses verbunden ist; Identifizieren eines der eingerichteten Virtual Machine Monitore durch den ermittelten Wert, um das erkannte privilegierte Ereignis durch den identifizierten Virtual Machine Monitor zu behandeln; Leiten des erkannten privilegierten Ereignisses zum identifizierten Virtual Machine Monitor; Erzeugen eines VM-Exit Befehls, um die Steuerung von der aktuell ausgeführten Gast-Software beziehungsweise dem aktuell ausgeführten Virtual Maschine Monitor auf den identifizierten Virtual Machine Monitor zu übertragen.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft im Allgemeinen virtuelle Maschinen und insbesondere die Abwicklung privilegierter Ereignisse unter Verwendung mehrerer Monitore virtueller Maschinen.
Allgemeiner Stand der Technik
Ein herkömmlicher Monitor virtueller Maschinen (Virtual Machine Monitor, VMM) ist typischerweise auf einem Computer in Betrieb und stellt für eine andere Software die Abstraktion einer oder mehrerer virtueller Maschinen dar, wie z. B. in US-Patent Nr. US 6,496,847 offenbart ist. Jede virtuelle Maschine kann als eine in sich abgeschlossene Plattform fungieren, welche ihr eigenes „Nebenbetriebssystem” („guest operating system”, d. h. ein Betriebssystem (Operating System, OS), bei welchem der VMM die Wirtsfunktion ausübt) und andere Software ausführt, zusammen als Nebensoftware (guest software) bezeichnet. Die Nebensoftware geht davon aus, so zu arbeiten, als ob sie auf einem dafür vorgesehenen Computer ablaufen würde, anstatt auf einer virtuellen Maschine. Das heißt, die Nebensoftware geht davon aus, verschiedene Ereignisse zu steuern und Zugriff auf Hardware-Betriebsmittel zu haben. Die Hardware-Betriebsmittel können prozessorresidente Betriebsmittel (z. B. Befehlsregister) sein, speicherresidente Betriebsmittel (z. B. Deskriptortabellen) und Betriebsmittel, welche sich auf der zugrundeliegenden Hardware-Plattform befinden (z. B. Eingabe/Ausgabe-Einheiten). Die Ereignisse können interne Unterbrechungen (internal interrupts), externe Unterbrechungen (external interrupts), Ausnahmesituationen (exeptions), Plattformereignisse (z. B. eine Initialisierung (INIT) oder Systemverwaltungs-Unterbrechungen (System Management Interrupts, SMIs)), die Ausführung bestimmter Befehle usw. sein.
In der Umgebung einer virtuellen Maschine sollte der VMM die letzte Kontrolle über diese Ereignisse und Hardware-Betriebsmittel haben können, um die richtige Operation der Nebensoftware, die auf den virtuellen Maschinen abläuft, bereitzustellen, und zum Schutz vor der Nebensoftware, die auf den virtuellen Maschinen abläuft, und dieser untereinander. Um dies zu erreichen, erhält der VMM typischerweise die Steuerung, wenn die Nebensoftware auf ein geschütztes Betriebsmittel zugreift, oder wenn andere Ereignisse (wie z. B. Unterbrechungen oder Ausnahmesituationen) auftreten. Wenn zum Beispiel eine Operation in einer virtuellen Maschine, welche von dem VMM unterstützt wird, bewirkt, dass eine Systemeinheit eine Unterbrechung erzeugt, dann wird die aktuell laufende virtuelle Maschine unterbrochen und die Steuerung des Prozessors wird an den VMM weitergegeben. Der VMM empfängt dann die Unterbrechung und wickelt die Unterbrechung selbst ab oder gibt die Unterbrechung an die geeignete virtuelle Maschine weiter.
US 6,496,847 offenbart bereits ein System mit mehreren VMMs, über die mehrere virtuelle Maschinen gesteuert sind. Die VMMs sind jedoch starr jeweils einer virtuellen Maschine zugeordnet.
Die vorliegende Erfindung sieht einen Prozessor nach Anspruch 1 sowie ein System nach Anspruch 7 und ein Verfahren nach Anspruch 16 vor.
Kurze Beschreibung der Zeichnungen
Die vorliegende Erfindung wird beispielhaft und nicht beschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht, in welchen gleiche Bezugsziffern sich auf ähnliche Elemente beziehen, und in welchen:
1 eine Ausführungsform einer Umgebung einer virtuellen Maschine veranschaulicht, in welcher die vorliegende Erfindung arbeiten kann;
2 einen Aufbau mehrerer VMMs in der Umgebung einer virtuellen Maschine veranschaulicht;
3 ein Flussdiagramm einer Ausführungsform eines Verfahrens zur Abwicklung privilegierter Ereignisse in der Umgebung einer virtuellen Maschine mit mehreren VMMs ist;
4, 6 und 7 Ausführungsbeispiele für Verfahren zum Identifizieren eines VMM zur Abwicklung eines privilegierten Ereignisses veranschaulichen; und
5 eine beispielhafte Anwendung des Verfahrens 400 in der Umgebung einer virtuellen Maschine mit zwei VMMs veranschaulicht.
Beschreibung von Ausführungsformen
Es wird ein Verfahren und eine Vorrichtung zur Abwicklung privilegierter Ereignisse unter Verwendung mehrerer Monitore virtueller Maschinen beschrieben. In der folgenden Beschreibung werden zu Erläuterungszwecken zahlreiche spezielle Einzelheiten angegeben, um für ein genaues Verständnis der vorliegenden Erfindung zu sorgen. Es ist jedoch dem Fachmann ersichtlich, dass die vorliegende Erfindung ohne diese speziellen Einzelheiten ausgeführt werden kann.
Einige Abschnitte der detaillierten Beschreibungen, die nun folgen, sind in Form von Algorithmen und symbolischen Darstellungen von Operationen an Daten-Bits innerhalb der Register oder des Speichers eines Computersystems angegeben. Diese algorithmischen Beschreibungen und Darstellungen sind die Mittel, welche vom Fachmann auf dem Gebiet der Datenverarbeitung benutzt werden, um anderen Fachleuten den Gegenstand ihrer Arbeit möglichst effektiv zu übermitteln. Ein Algorithmus wird hier und im Allgemeinen als in sich abgeschlossene Folge von Operationen verstanden, welche zu einem gewünschten Ergebnis führt. Die Operationen sind solche, welche physikalische Beeinflussungen physikalischer Größen erfordern. Gewöhnlich, aber nicht notwendigerweise, nehmen diese Größen die Form elektrischer oder magnetischer Signale an, welche gespeichert, übertragen, verknüpft, verglichen und auf andere Weise beeinflusst werden können. Es hat sich beizeiten als bequem erwiesen, hauptsächlich aus Gründen der allgemeinen Verwendung, diese Signale als Bits, Werte, Elemente, Symbole, Buchstaben, Begriffe, Zahlen oder Ähnliches zu bezeichnen.
Man sollte jedoch bedenken, dass all diese und ähnliche Begriffe mit den geeigneten physikalischen Größen verbunden werden müssen und lediglich bequeme Etikettierungen darstellen, mit denen diese Größen versehen sind. Soweit nicht in den folgenden Erörterungen im Einzelnen anders angegeben, versteht es sich, dass über die vorliegende Erfindung hinweg Erörterungen, bei welchen Begriffe wie „Verarbeiten” oder „Rechnen” oder „Berechnen” oder „Ermitteln” oder Ähnliches verwendet werden, sich auf die Vorgänge und Verfahren eines Computersystems oder einer ähnlichen elektronischen Recheneinheit beziehen können, welche Daten, die als physikalische (elektronische) Einheiten innerhalb der Register und Speicher des Computersystems dargestellt sind, beeinflusst und in andere Daten umformt, welche ähnlich als physikalische Größen innerhalb der Speicher und Register des Computersystems oder anderer solcher Einheiten zur Datenspeicherung, Datenübertragung oder Datenanzeige dargestellt sind.
In der folgenden detaillierten Beschreibung der Ausführungsformen wird Bezug genommen auf die begleitenden Zeichnungen, welche als Veranschaulichung spezielle Ausführungsformen darstellen, in welchen die Erfindung ausgeführt werden kann. In den Zeichnungen beschreiben gleiche Ziffern über die verschiedenen Ansichten hinweg im Wesentlichen ähnliche Komponenten. Diese Ausführungsformen werden detailliert genug beschrieben, um zu ermöglichen, dass der Fachmann die Erfindung ausführen kann. Es können andere Ausführungsformen benutzt werden, und es können strukturelle, logische und elektrische Veränderungen vorgenommen werden, ohne den Schutzbereich der vorliegenden Erfindung zu verlassen. Außerdem versteht es sich, dass die verschiedenen Ausführungsformen der Erfindung, obwohl verschieden, sich nicht notwendigerweise gegenseitig ausschließen. Zum Beispiel kann ein bestimmtes Merkmal, eine Struktur oder eine Eigenschaft, welches) in einer Ausführungsform beschrieben wird, in anderen Ausführungsformen enthalten sein. Die folgende detaillierte Beschreibung darf daher nicht als beschränkend angesehen werden, und der Schutzbereich der vorliegenden Erfindung wird nur durch die beigefügten Ansprüche definiert, zusammen mit der gesamten Reichweite der Äquivalente, auf welche sich solche Ansprüche beziehen.
Obwohl in den unten angegebenen Beispielen Ausführungsformen der vorliegenden Erfindung im Zusammenhang mit Ausführungseinheiten und Logikschaltungen beschrieben werden, können andere Ausführungsformen der vorliegenden Erfindung über eine Software ausgeführt werden. Zum Beispiel kann die vorliegende Erfindung in einigen Ausführungsformen als ein Computerprogrammprodukt oder eine Software bereitgestellt werden, welche(s) ein maschinen- oder computerlesbares Medium beinhalten kann, auf welchem Befehle gespeichert sind, die verwendet werden können, um einen Computer (oder andere elektronische Einheiten) zu programmieren, um ein Verfahren gemäß der vorliegenden Erfindung durchzuführen. In anderen Ausführungsformen könnten Schritte der vorliegenden Erfindung durch spezielle Hardware-Elemente, welche eine festverdrahtete Logik zur Durchführung der Schritte enthalten, oder durch irgendeine Kombination von programmierten Computerelementen und speziellen Hardware-Elementen durchgeführt werden.
Daher kann ein maschinenlesbares Medium irgendeinen Mechanismus zum Speichern oder Übertragen von Daten in einer von einer Maschine (z. B. einem Computer) lesbaren Form beinhalten, ist aber nicht auf Disketten, optische Platten, CompactDiscs Read-Only Memory (CD-ROM) und magnetooptische Platten, Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), Löschbare Programmierbare Nur-Lese-Speicher (EPROM), Elektrisch Löschbare Programmierbare Nur-Lese-Speicher (EEPROM), Magnetkarten oder optische Karten, Flash-Speicher, eine Übertragung über das Internet, elektrische, optische, akustische oder andere Formen verbreiteter Signale (z. B. Trägerwellen, Infrarotsignale, Digitalsignale usw.) oder Ähnliches beschränkt.
Ferner kann eine Entwicklung verschiedene Stufen durchlaufen, von der Erzeugung über die Simulierung zur Fabrikation. Daten, welche eine Entwicklung darstellen, können die Entwicklung auf viele Weisen darstellen. Erstens, wie es bei Simulationen zweckmäßig ist, kann die Hardware unter Verwendung einer Hardware-Beschreibungssprache oder einer anderen funktionellen Beschreibungssprache dargestellt werden. Außerdem kann in einigen Stufen des Entwicklungsverfahrens ein Schaltungsmodell mit Logik- und/oder Transistor-Gattern erzeugt werden. Desweiteren erreichen die meisten Entwicklungen in irgendeiner Stufe eine Datenposition, welche die physikalische Anordnung verschiedener Einheiten in dem Hardware-Modell darstellt. In dem Fall, wenn herkömmliche Halbleiterfabrikationstechniken angewendet werden, kann es sich bei den Daten, die ein Hardware-Modell darstellen, um die Daten handeln, welche das Vorliegen oder Fehlen verschiedener Merkmale auf unterschiedlichen Maskenschichten für Masken beschreiben, welche verwendet werden, um den integrierten Schaltkreis herzustellen. In jeder Darstellung der Entwicklung können die Daten in jeder Form eines maschinenlesbaren Mediums gespeichert sein. Eine optische oder elektrische Welle, welche moduliert oder auf andere Weise erzeugt ist, um solche Daten zu übertragen, ein Speicher oder ein magnetischer oder optischer Speicher wie z. B. eine Speicherplatte können das maschinenlesbare Medium sein. Jedes dieser Medien kann die Entwicklungs- oder Software-Daten „tragen” oder „anzeigen”. Wenn eine elektrische Trägerwelle, welche den Code oder die Entwicklung anzeigt oder trägt, in dem Umfang übertragen wird, dass eine Kopie, Pufferung oder Rückübertragung des elektrischen Signals durchgeführt wird, dann wird eine neue Kopie hergestellt. Somit kann ein Datenaustausch-Provider oder ein Netzwerk-Provider Kopien eines Gegenstandes (einer Trägerwelle) herstellen, welcher Techniken der vorliegenden Erfindungen umfasst.
1 veranschaulicht eine Ausführungsform einer Umgebung 100 einer virtuellen Maschine, in welcher die vorliegende Erfindung arbeiten kann. In dieser Ausführungsform umfasst die unbestückte Plattform-Hardware 110 eine Rechenplattform, welche zum Beispiel ein Standard-Betriebssystem (OS) oder Monitore virtueller Maschinen (VMMs) wie die VMMs 125 ausführen kann.
Die Plattform-Hardware 110 kann von einem Personal-Computer (PC), Großrechner, Handgerät, tragbaren Computer, Aufsatzgerät oder irgendeinem anderen Rechensystem sein. Die Plattform-Hardware 110 umfasst mindestens einen Prozessor 112, einen Speicher 120 und möglicherweise andere Plattform-Hardware (z. B. Eingabe-Ausgabe-Einheiten), welche nicht dargestellt ist.
Der Prozessor 112 kann jede Art von Prozessor sein, der Software ausführen kann, wie z. B. ein Mikroprozessor, Digitalsignalprozessor, Mikrocontroller oder Ähnliches. Der Prozessor 112 kann Mikrocode, eine programmierbare Logik oder eine hartcodierte Logik zur Ausführung von Ausführungsformen des Verfahrens der vorliegenden Erfindung umfassen.
Der Speicher 120 kann eine Festplatte, eine Diskette, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein Flash-Speicher, irgendeine Kombination der obigen Geräte oder irgendeine andere Art von Maschinenmedium sein, welches von dem Prozessor 112 lesbar ist. Der Speicher 120 kann Befehle oder Daten zur Ausführung von Ausführungsformen des Verfahrens der vorliegenden Erfindung speichern.
Jeder VMM 125, obwohl er typischerweise in Software verwirklicht wird, kann eine bloße Maschinenschnittstelle emulieren und an eine höherwertige Software exportieren. Eine solche höherwertige Software kann ein Standard oder Echtzeit-OS umfassen, kann ein sehr abgespecktes Organisationsprogramm mit beschränkter Betriebssystem-Funktion sein, muss keine herkömmlichen OS-Leistungsmerkmale enthalten usw. Die VMMs 125 können zum Beispiel in Hardware, Software, Firmware oder durch eine Kombination verschiedener Techniken verwirklicht werden.
Wenn er in Betrieb ist, dann verkörpert jeder VMM 125 für eine „Nebensoftware” (also eine andere Software als diejenige der VMMs 125) die Abstraktion einer oder mehrerer virtueller Maschinen (VMs). Die VMMs 125 können den verschiedenen Nebensoftwares dieselben oder unterschiedliche Abstraktionen bereitstellen. Die Nebensoftware, die auf jeder VM abläuft, kann ein Neben-OS (z. B. ein Neben-OS 134, 144 oder 154) und verschiedene Nebensoftware-Anwendungen (z. B. die Anwendungen 136, 146 und 156) umfassen. Zusammenfassend werden das Neben-OS und Nebensoftware-Anwendungen hier als Nebensoftware 103, 105 und 115 bezeichnet.
Die Nebensoftware 103, 105 und 115 geht davon aus, auf physikalische Betriebsmittel (z. B. Prozessorregister, Speicher und E/A-Einheiten) innerhalb der VMs 132, 142 und 152, auf welchen die Nebensoftware abläuft, zuzugreifen. Die VMMs 125 erleichtern den Zugriff auf die von der Nebensoftware gewünschten Betriebsmittel, während sie die letzte Kontrolle über die Betriebsmittel innerhalb der Plattform-Hardware 110 behalten. Außerdem geht die Nebensoftware 103, 105 und 115 davon aus, verschiedene Ereignisse wie Ausnahmesituationen, Unterbrechungen und Plattformereignisse (z. B. Initialisierungen (INIT) und Systemverwaltungsunterbrechungen (SMIs)) abzuwickeln. Einige dieser Ereignisse sind „privilegiert”, weil sie von der Nebensoftware nicht abgewickelt werden können, um eine richtige Operation der VMs 132, 142 und 152 und der Nebensoftware 103, 105 und 115 sicherzustellen, und zum Schutz vor der Nebensoftware 103, 105 und 115 und dieser untereinander. Die privilegierten Ereignisse werden von den VMMs 125 abgewickelt.
Im Einzelnen wird, um jedes privilegierte Ereignis abzuwickeln, ein bestimmter VMM identifiziert bzw. ermittelt. In einer Ausführungsform wird unter Anwendung der Leitweglogik 130 ein bestimmter VMM identifiziert. In einigen Ausführungsformen ist die Leitweglogik 130 als Mikrocode, programmierbare Logik oder hartcodierte Logik verwirklicht. In anderen Ausführungsformen ist die Leitweglogik 130 als Software verwirklicht, die sich auf dem Speicher 120 befindet. In noch einer anderen Ausführungsform ist die Leitweglogik 130 als eine Kombination von Hardware und Software verwirklicht.
Wenn einmal ein bestimmter VMM identifiziert ist, dann erleichtert er die von der Nebensoftware gewünschte Funktionalität, während er die letzte Kontrolle bzw. die Steuerung über dieses privilegierte Ereignis behält. Das Tätigkeit des Erleichterns der Funktionalität für die Nebensoftware kann eine breite Vielfalt von Aktivitäten seitens der VMMs 125 beinhalten. Diese Aktivitäten der VMMs 125 sollten den Schutzbereich der vorliegenden Erfindung nicht beschränken.
Das System 100 kann zwei oder mehr VMMs 125 umfassen, welche auf der Plattform-Hardware 110 ausgeführt werden. In einer Ausführungsform laufen die VMMs 125 parallel ab, und jeder VMM 125 kann von einer VM die Steuerung erhalten. 2 veranschaulicht eine Ausführungsform eines solchen Aufbaus der VMMs 125 innerhalb des Systems 100.
In 2 ist ein beispielhafter paralleler Aufbau der VMMs 210 bis 214 veranschaulicht. Gemäß diesem Aufbau wird die Steuerung von einer VM auf einen bestimmten VMM übertragen, wenn während des Betriebs einer VM ein privilegiertes Ereignis auftritt. Der bestimmte VMM wird auf der Basis bestimmter Kriterien identifiziert bzw. ermittelt, was unten noch detaillierter erörtert wird. Wenn der bestimmte VMM einmal ermittelt ist, dann werden die Daten, welche sich auf das Virtualisierungsereignis beziehen, zu diesem VMM weitergeleitet, und die Steuerung wird auf ihn übertragen. Zum Beispiel kann das privilegierte Ereignis 1, welches während des Betriebs der VM 202 auftritt, eine Übertragung von der VM 202 auf den VMM 210 bewirken, das privilegierte Ereignis 2, welches während des Betriebs der VM 202 auftritt, kann eine Übertragung von der VM 202 auf den VMM 212 bewirken, das privilegierte Ereignis 3, welches während des Betriebs der VM 206 auftritt, kann eine Übertragung von der VM 206 auf den VMM 212 bewirken, und das privilegierte Ereignis 4, welches während des Betriebs der VM 206 auftritt, kann eine Übertragung von der VM 206 auf den VMM 214 bewirken. Ein entsprechender VMM wickelt dann das Virtualisierungsereignis ab und kann die Steuerung zu einer VM, von welcher die Steuerung empfangen wurde, zurückübertragen. In einer Ausführungsform wird die Übertragung der Steuerung von einem VMM auf eine VM erreicht durch Ausführen eines speziellen Befehls erreicht. Die Übertragung der Steuerung von einem VMM auf eine VM wird hier als VM-Entry (VM-Eingang) bezeichnet, und die Übertragung der Steuerung von einer VM auf einen VMM wird hier als VM-Exit (VM-Ausgang) bezeichnet.
In einer Ausführungsform wird, wenn ein VM-Exit auftritt, die Steuerung an einem speziellen Entry-Punkt (z. B. einem Wert eines Befehlszeigers), welcher in einer speicherresidenten Steuerungsstruktur einer virtuellen Maschine (Virtual Machine Control Structure, VMCS) dargestellt ist, die vom Prozessor unterhalten wird, zu einem VMM weitergeleitet. In einer anderen Ausführungsform wird die Steuerung nach der Zwischenadressierung durch eine Umleitstruktur (z. B. die Unterbrechungsdeskriptoren-Tabelle in der Prozessor-Befehlsvorratsarchitektur (Instruction Set Architecture, ISA) des Intel^® Pentium^® 4 (hier als IA-32 ISA bezeichnet)) zu einem VMM weitergeleitet. Alternativ kann irgendein anderer auf dem Fachgebiet bekannter Mechanismus verwendet werden, um die Steuerung von einer VM auf einen VMM zu übertragen.
Ein privilegiertes Ereignis kann während des Betriebs eines VMM auftreten. Beispiele privilegierter Ereignisse, welche während des Betriebs eines VMM auftreten können, können zum Beispiel Systemverwaltungs-Unterbechungen (SMIs), INIT, nichtmaskierbare Unterbrechungen (Non-Maskable Interrupts, NMIs), Hardware-Unterbrechungen, Inter-Prozessor-Unterbrechungen (Interprocessor-Interrupts, IPIs) usw. sein. In einer Ausführungsform wird, wenn während des Betriebs eines VMM ein privilegiertes Ereignis auftritt, eine Leitweglogik angewendet, um einen VMM zu ermitteln, der dafür vorgesehen ist, dieses privilegierte Ereignis abzuwickeln. Wenn der vorgesehene VMM nicht der VMM ist, welcher zu der Zeit in Betrieb ist, dann werden die Daten, die sich auf das privilegierte Ereignis beziehen, zu dem vorgesehenen VMM weitergeleitet, und die Steuerung wird auf ihn übertragen. Zum Beispiel kann das privilegierte Ereignis 5, welches während des Betriebs des VMM 210 auftritt, eine Übertragung von dem VMM 210 zu dem VMM 212 bewirken. Der VMM 212 wickelt dann das privilegierte Ereignis ab und kann die Steuerung auf den VMM 210 zurückübertragen. Bei Dialogen zwischen dem VMM 210 und dem VMM 212 spielt also der VMM 210 die Rolle einer VM. Dementsprechend wird in einer Ausführungsform ein VM-Exit(VM-Ausgang)- und ein VM-Entry(VM-Eingang)-Mechanismus ähnlich dem oben bezüglich der Übertragung der Steuerung zwischen einer VM und einem VMM beschriebenen verwendet, um die Steuerung zwischen den VMMs zu übertragen.
3 ist ein Flussdiagramm einer Ausführungsform eines Verfahrens 300 zur Abwicklung privilegierter Ereignisse in der Umgebung einer virtuellen Maschine mit mehreren VMMs. Das Verfahren kann durch eine Verarbeitungslogik ausgeführt werden, welche Hardware (z. B. eine Schaltungsanordnung, dafür vorgesehene Logik, programmierbare Logik, Mikrocode usw.), Software (wie eine auf einem allgemeinen Computersystem oder einer oder dafür vorgesehenen Maschine ablaufende) oder eine Kombination beider umfassen kann.
Mit Bezug auf 3 beginnt das Verfahren 300 damit, dass die Verarbeitungslogik das Auftreten eines privilegierten Ereignisses erkennt (Verarbeitungsblock 302). Ein privilegiertes Ereignis ist ein Ereignis, welches nicht von der aktuell ablaufenden Software abzuwickeln ist. Solche privilegierten Ereignisse können Ausnahmesituationen, Unterbrechungen, Plattformereignisse, die Ausführung eines „privilegierten” Befehls (eines Befehls, dessen Ausführung einen VM-Exit bewirkt) usw. sein. Ein privilegiertes Ereignis kann während des Betriebs einer Nebensoftware oder während des Betriebs eines VMM auftreten.
Im Verarbeitungsblock 304 ermittelt die Verarbeitungslogik, welcher der mehreren VMMs das privilegierte Ereignis abwickeln soll. Die Ermittlung kann auf verschiedenen Faktoren wie Eigenschaften des privilegierten Ereignisses, aktuellen Werten vorgesehener Felder, welcher durch die VMMs modifizierbar sind, Betriebsparametern der VMMs, Betriebsparametern der Nebensoftware usw. basieren. In einem Beispiel basiert die Ermittlung auf dem Typ des privilegierten Ereignisses, wie unten im Zusammenhang mit 4 noch detaillierter erörtert wird. In einem anderen Beispiel basiert die Ermittlung auf aktuellen Werten von Steuerungsfeldern, welche durch einen der mehreren VMMs konfiguriert werden, wie unten im Zusammenhang mit 6 noch detaillierter erörtert wird. In noch einem anderen Beispiel basiert die Ermittlung auf der Auswertung von Belastungs- und/oder Benutzungseigenschaften der VMMs, wie unten im Zusammenhang mit 7 noch detaillierter erörtert wird. In noch einem anderen Beispiel basiert die Ermittlung auf der Kombination der obigen Faktoren.
Wenn die Verarbeitungslogik einmal bestimmt hat, welche VMM das privilegierte Ereignis abzuwickeln hat, leitet sie die Daten, welche sich auf das privilegierte Ereignis beziehen, zu dem vorgesehenen VMM weiter und überträgt die Steuerung auf diesen VMM (Verarbeitungsblock 306). Der VMM kann dann das privilegierte Ereignis selbst abwickeln oder zur Abwicklung an Nebensoftware weiterleiten.
4, 6 und 7 veranschaulichen Ausführungsbeispiele für Verfahren zum Ermitteln eines VMM zur Abwicklung eines privilegierten Ereignisses. Die Verfahren können durch die Verarbeitungslogik ausgeführt werden, welche Hardware (z. B. eine Schaltungsanordnung, dafür vorgesehene Logik, programmierbare Logik, Mikrocode usw.), Software (wie eine auf einem allgemeinen Computersystem oder einer oder dafür vorgesehenen Maschine ablaufende) oder eine Kombination beider umfassen kann.
Mit Bezug auf 4 beginnt Verfahren 400 damit, dass die Verarbeitungslogik das Vorliegen eines privilegierten Ereignisses während des Betriebs von Nebensoftware oder eines VMM erkennt (Verarbeitungsblock 402). In Verarbeitungsblock 404 ermittelt die Verarbeitungslogik den Typ des privilegierten Ereignisses. Als nächstes ermittelt die Verarbeitungslogik, welcher VMM dafür vorgesehen ist, privilegierte Ereignisse dieses Typs abzuwickeln (Verarbeitungsblock 406). In einer Ausführungsform ist jeder Ereignistyp statisch auf einen bestimmten VMM aufgegliedert (z. B. unter Verwendung einer hartcodierten Logik). In einer anderen Ausführungsform ist die Ermittlung dynamisch, wie unten im Zusammenhang mit 6 beschrieben. In noch einer anderen Ausführungsform wird eine Kombination statisch ermittelter VMMs und dynamisch ermittelter VMMs verwendet. Das bedeutet, einige Ereignistypen können statisch auf entsprechende VMMs aufgegliedert sein, während andere Ereignistypen für die Ermittlung zusätzliche Prozessoroperationen erforderlich machen können.
Wenn die aktuell operierende Einheit nicht der vorgesehene VMM ist (Entscheidungskasten 408), dann überträgt die Verarbeitungslogik die Steuerung auf den vorgesehenen VMM (Verarbeitungsblock 410). In einer Ausführungsform kann die Übertragung auf den vorgesehenen VMM durch Erzeugen eines VM-Exit geschehen. Alternativ kann irgendein anderer auf dem Fachgebiet bekannter Mechanismus angewendet werden, um die Steuerung auf den vorgesehenen VMM zu übertragen.
Wenn die aktuell operierende Einheit der vorgesehene VMM ist, dann wird das Ereignis an den aktuell laufenden VMM weitergeleitet (Verarbeitungsblock 412). In einer Ausführungsform wird die Weiterleitung des Ereignisses an den VMM durchgeführt, indem ein VM-Exit von dem VMM zu sich selbst synthetisiert wird. In einer anderen Ausführungsform wird das Ereignis weitergeleitet, wie es in der Umgebung einer nichtvirtuellen Maschine weitergeleitet würde (z. B. durch Zwischenadressierung durch eine Unterbrechungsdeskriptoren-Tabelle, oder indem man eine Übertragung auf einen Systemverwaltungsmodus bewirkt). Es sollte angemerkt werden, dass eine Vielfalt anderer auf dem Fachgebiet bekannter Mechanismen angewendet werden kann, um das Ereignis an den aktuell laufenden VMM weiterzuleiten.
5 veranschaulicht eine beispielhafte Anwendung des Verfahrens 400 in der Umgebung einer virtuellen Maschine mit zwei VMMs gemäß einer Ausführungsform der vorliegenden Erfindung. Einer der beiden VMMs (z. B. VMM 508) ist ausschließlich dafür vorgesehen, bestimmte Plattformereignisse (z. B. Systemverwaltungs-Unterbrechungen (SMIs), IPIs, nichtmaskierbare Unterbrechungen usw.) abzuwickeln. VMM 508 wird als der Plattform-VMM (PVMM) bezeichnet. In einigen Ausführungsformen ist der PVMM dafür vorgesehen, nur SMIs abzuwickeln. In anderen Ausführungsformen wickeln PVMMs zusätzliche Ereignistypen ab, ebenso wie SMIs. In noch anderen Ausführungsformen werden mehrere PVMMs verwendet, wobei jeder unterschiedliche Plattformereignisse abwickelt.
Wenn ein privilegiertes Ereignis auftritt, dann ermittelt die Leitweglogik 510 (routing logic) den Typ des Ereignisses. Wenn das Ereignis ein Plattformereignis ist, welches von dem PVMM 508 abzuwickeln ist, dann leitet die Leitweglogik 510 es zum VMM 508. Anderenfalls wird das Ereignis zum VMM 506 geleitet. Wie in 5 veranschaulicht, kann die Leitweglogik 510 Ereignisse leiten, welche während des Betriebs von Nebensoftware oder während des Betriebs eines VMM auftreten.
Die Leitung eines Ereignisses zu einem VMM kann unterschiedlich sein, abhängig davon, welche Einheit ausgeführt wurde, als das Ereignis auftrat. Wenn eine Nebensoftware ausgeführt wurde, dann wird in einer Ausführungsform die Übertragung auf den von der Leitweglogik 510 ausgewählten VMM über einen VM-Exit vorgenommen. Wenn der von der Leitweglogik 510 ausgewählte VMM ausgeführt wurde, als das Ereignis auftrat, dann kann das Ereignis durch eine Vielfalt von Mechanismen an den VMM weitergeleitet werden, wie oben im Zusammenhang mit 4 beschrieben.
Die Verwendung eines zweiten VMM, welcher ausschließlich dafür vorgesehen ist, bestimmte Plattformereignisse abzuwickeln, vermeidet eine Produktabhängigkeit zwischen Hardware-Lieferanten und OS-Lieferanten. Das bedeutet, sie ermöglicht Plattform-Hardware-Lieferanten, unabhängig von OS-Lieferanten den Code für den zweiten VMM (den PVMM) zu entwickeln. In ähnlicher Weise können OS-Lieferanten unabhängig von den Hardware-Lieferanten den Code für den ersten VMM entwickeln. Außerdem verbessert die Verwendung zweier VMMs, welche unterschiedliche Funktionen erfüllen, die Systemsicherheit und begrenzt die Exposition des Codes, welcher aus Sicherheitsgründen bestätigt werden muss.
Mit Bezug auf 6 beginnt das Verfahren 600 damit, dass die Verarbeitungslogik das Vorliegen eines privilegierten Ereignisses während des Betriebs von Nebensoftware oder eines VMM erkennt (Verarbeitungsblock 602). In Verarbeitungsblock 604 empfängt die Verarbeitungslogik Daten, welche das privilegierte Ereignis identifizieren. Als nächstes greift die Verarbeitungslogik auf ein Betriebsmittel (z. B. eine In-Memory-Datenstruktur, ein Prozessorregister, einen Speicher im Plattform-Chipsatz, ein Register in einer Eingabe-Ausgabe-Einheit usw.) zu, welches die Auswahl eines VMM zur Abwicklung privilegierter Ereignisse steuert (Verarbeitungsblock 606), und liest den aktuellen Wert aus einem Betriebsmittelfeld aus, welches mit der Kennung des privilegierten Ereignisses verbunden ist (Verarbeitungsblock 608).
In einer Ausführungsform ist die Kennung des privilegierten Ereignisses der Typ des privilegierten Ereignisses, und die Verarbeitungslogik verwendet den Typ des privilegierten Ereignisses, um den Wert eines Betriebsmittelfeldes zu ermitteln, welcher mit diesem Typ des privilegierten Ereignisses verbunden ist.
In einer anderen Ausführungsform ermitteln die Identifikationsdaten eine spezielle Eingabe-Ausgabe-Adresse, welche mit dem privilegieren Ereignis verbunden ist. In dieser Ausführungsform analysiert die Verarbeitungslogik den Eingabe-Ausgabe-Zugriff, welcher mit dem privilegierten Ereignis verbunden ist, ermittelt, auf welche Eingabe-Ausgabe-Adresse zugegriffen wird, und verwendet diese Eingabe-Ausgabe-Adresse dann, um den Wert eines Betriebsmittelfeldes zu finden, welcher mit einem Eingabe-Ausgabe-Adressbereich verbunden ist, zu welchem die ermittelte Eingabe-Ausgabe-Adresse gehört. In einer Ausführungsform werden die Werte der Betriebsmittelfelder während der Initialisierung eingestellt und können nicht verändert werden. In einer anderen Ausführungsform können die Werte der Betriebsmittelfelder von einem VMM (z. B. einem Haupt-VMM) auf der Basis solcher Faktoren wie Sicherheitserfordernissen, der Kenntnis des VMM von der Plattform usw. dynamisch konfiguriert werden. Diese dynamische Konfigurierung von Werten von Betriebsmittelfeldern ermöglicht, dass eine VMM-Funktionalität partitioniert wird, was möglicherweise die Sicherheit, die Leistungsfähigkeit des Systems, die Entwicklungsmethodologien usw. verbessert.
Ferner ermittelt die Verarbeitungslogik auf Basis des aktuellen Wertes des entsprechenden Feldes, welcher VMM dafür vorgesehen ist, das privilegierte Ereignis abzuwickeln (Verarbeitungsblock 610), und überträgt, wenn die aktuell operierende Einheit nicht der vorgesehene VMM ist (Entscheidungskasten 612), die Steuerung auf den vorgesehenen VMM (Verarbeitungsblock 614). In einer Ausführungsform kann die Übertragung auf den vorgesehenen VMM durch Erzeugen eines VM-Exit erfolgen. Alternativ kann die Übertragung auf den vorgesehenen VMM über irgendeinen anderen auf dem Fachgebiet bekannten Mechanismus erfolgen.
Wenn der vorgesehene VMM die aktuell operierende Einheit ist, dann leitet die Verarbeitungslogik das Ereignis zu diesem VMM weiter (Verarbeitungsblock 616), wie oben im Zusammenhang mit 4 und 5 beschrieben.
Mit Bezug auf 7 beginnt das Verfahren 700 damit, dass die Verarbeitungslogik das Vorliegen eines privilegierten Ereignisses während des Betriebs von Nebensoftware oder eines VMM erkennt (Verarbeitungsblock 702). In Verarbeitungsblock 704 ermittelt die Verarbeitungslogik für jeden VMM in dem System die Benutzungs-Belastungsparameter von Betriebsmitteln. Als nächstes wertet die Verarbeitungslogik für die VMMs die Benutzungs- und/oder Belastungsparameter der Betriebsmittel hinsichtlich des Belastungsausgleichs aus (Verarbeitungsblock 706) und ermittelt auf Basis der obigen Belastungsausgleichsauswertung, welcher VMM der beste Kandidat für die Abwicklung des privilegierten Ereignisses ist (Verarbeitungsblock 708). Ferner überträgt die Verarbeitungslogik, wenn die aktuell operierende Einheit nicht der VMM ist, welcher als bester Kandidat ermittelt wurde (Entscheidungskasten 712), die Steuerung auf den ermittelten VMM (Verarbeitungsblock 714). In einer Ausführungsform kann die Übertragung auf den ermittelten VMM durch Erzeugung eines VM-Exit erfolgen. Alternativ kann die Übertragung auf den ermittelten VMM über irgendeinen anderen auf dem Fachgebiet bekannten Mechanismus erfolgen.
Wenn der vorgesehene VMM die aktuell operierende Einheit ist, dann leitet die Verarbeitungslogik das Ereignis zu diesem VMM weiter (Verarbeitungsblock 716), wie oben im Zusammenhang mit 4 bis 6 beschrieben.
Somit sind ein Verfahren und eine Vorrichtung zur Abwicklung privilegierter Ereignisse unter Verwendung mehrerer VMMs beschrieben worden. Es versteht sich, dass die obige Beschreibung veranschaulichend und nicht beschränkend sein soll. Nach dem Lesen und Verstehen der obigen Beschreibung werden dem Fachmann viele andere Ausführungsformen ersichtlich sein. Der Schutzbereich der Erfindung sollte daher mit Bezug auf die beigefügten Ansprüche ermittelt werden, zusammen mit der vollständigen Reichweite der Äquivalente, auf welche sich solche Ansprüche beziehen.
Ausführungsformen der Erfindung können sich ferner auf eines oder mehrere der folgenden Beispiele beziehen:

1. Verfahren, welches das Folgende umfasst: Erkennen des Auftretens eines privilegierten Ereignisses; Ermitteln, welcher aus einer Vielzahl von Monitoren virtueller Maschinen (VMMs) das privilegierte Ereignis abwickeln soll; und Übertragen der Steuerung auf den einen aus der Vielzahl von VMMs.
2. Verfahren nach Beispiel 1, wobei die Vielzahl von VMMs einen Haupt-VMM und einen oder mehrere parallele VMMs aufweist.
3. Verfahren nach Beispiel 1, wobei das Ermitteln, welcher aus einer Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, das Folgende umfasst: Ermitteln eines Typs des privilegierten Ereignisses; und Identifizieren eines VMM aus der Vielzahl von VMMs, welcher dafür vorgesehen ist, privilegierte Ereignisse des ermittelten Typs abzuwickeln.
4. Verfahren nach Beispiel 1, wobei das Ermitteln, welcher aus einer Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, das Folgende umfasst: Zugreifen auf ein Feld, welches mit dem privilegierten Ereignis in einem Betriebsmittel verbunden ist; und Identifizieren eines VMM aus der Vielzahl von VMMs, welcher dafür vorgesehen ist, das privilegierte Ereignis abzuwickeln, basierend auf einem Wert des Feldes.
5. Verfahren nach Beispiel 4, wobei das Feld, welches mit dem privilegierten Ereignis verbunden ist, ein Feld ist, welches mit einem Typ des privilegierten Ereignisses verbunden ist.
6. Verfahren nach Beispiel 4, wobei das Feld, welches mit dem privilegierten Ereignis verbunden ist, ein Feld ist, welches mit einem Eingabe-Ausgabe-Adressbereich verbunden ist, zu welchem eine Eingabe-Ausgabe-Adresse des privilegierten Ereignisses gehört.
7. Verfahren nach Beispiel 4, wobei der Wert des Feldes, welches mit dem privilegierten Ereignis verbunden ist, entweder vorgegeben oder dynamisch konfigurierbar ist.
8. Verfahren nach Beispiel 1, wobei das Ermitteln, welcher aus einer Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, das Folgende umfasst: Auswerten von Betriebsmittel-Benutzungsparametern der Vielzahl von VMMs; und Identifizieren eines VMM aus der Vielzahl von VMMs, welcher dafür vorgesehen ist, das privilegierte Ereignis abzuwickeln, basierend auf der Auswertung der Betriebsmittel-Benutzungsparameter.
9. Verfahren nach Beispiel 4, wobei das Betriebsmittel sich in irgendeinem von einem Speicher, einem Prozessor, einem Chipsatz und einer Eingabe-Ausgabe-Einheit befindet.
10. Verfahren nach Beispiel 1, wobei es sich bei dem privilegierten Ereignis um irgendeines aus einer Unterbrechung, einer Ausnahmesituation, einer Ausführung eines privilegierten Befehls und einem Plattformereignis handelt.
11. Verfahren nach Beispiel 1, wobei das privilegierte Ereignis während eines Betriebs von Nebensoftware auftritt.
12. Verfahren nach Beispiel 1, wobei das privilegierte Ereignis während eines Betriebs eines aus der Vielzahl von VMMs auftritt.
13. System, welches das Folgende umfasst: eine Vielzahl von Monitoren virtueller Maschinen (VMMs); und eine Leitweglogik, um das Auftreten eines privilegierten Ereignisses zu erkennen, um zu ermitteln, welcher aus einer Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, und um die Steuerung auf den einen aus der Vielzahl von VMMs zu übertragen.
14. System nach Beispiel 13, wobei die Vielzahl von VMMs einen Haupt-VMM und einen oder mehrere parallele VMMs aufweist.
15. System nach Beispiel 13, wobei die Leitweglogik ermittelt, welcher aus der Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, indem sie einen Typ des privilegierten Ereignisses ermittelt und einen VMM aus der Vielzahl von VMMs identifiziert, welcher dafür vorgesehen ist, privilegierte Ereignisse des ermittelten Typs abzuwickeln.
16. System nach Beispiel 13, wobei die Leitweglogik ermittelt, welcher aus der Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, indem sie Betriebsmittelbenutzungs-Parameter der Vielzahl von VMMs auswertet und, basierend auf der Auswertung der Betriebsmittelbenutzungs-Parameter, einen VMM aus der Vielzahl von VMMs identifiziert, welcher dafür vorgesehen ist, das privilegierte Ereignis abzuwickeln.
17. System nach Beispiel 13, wobei es sich bei dem privilegierten Ereignis um irgendeines aus einer Unterbrechung, einer Ausnahmesituation, einer Ausführung eines privilegierten Befehls und einem Plattformereignis handelt.
18. System nach Beispiel 13, wobei das privilegierte Ereignis während des Betriebs von Nebensoftware auftritt.
19. System nach Beispiel 13, wobei das privilegierte Ereignis während eines Betriebs eines aus der Vielzahl von VMMs auftritt.
20. System, welches das Folgende umfasst: einen Speicher, auf welchem Nebensoftware und eine Vielzahl von Monitoren virtueller Maschinen (VMMs) gespeichert sind; und einen Prozessor, welcher an den Speicher gekoppelt ist, um die Nebensoftware auszuführen, um das Auftreten eines privilegierten Ereignisses zu erkennen, um zu ermitteln, welcher aus einer Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, und um die Steuerung auf den einen aus der Vielzahl von VMMs zu übertragen.
21. System nach Beispiel 20, wobei die Vielzahl von VMMs einen Haupt-VMM und einen oder mehrere parallele VMMs aufweist.
22. System nach Beispiel 20, wobei der Prozessor ermittelt, welcher aus der Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, indem er einen Typ des privilegierten Ereignisses ermittelt und einen VMM aus der Vielzahl von VMMs identifiziert, welcher dafür vorgesehen ist, privilegierte Ereignisse des ermittelten Typs abzuwickeln.
23. System nach Beispiel 20, wobei der Prozessor ermittelt, welcher aus der Vielzahl von VMMs das privilegierte Ereignis abwickeln soll, indem er Betriebsmittelbenutzungs-Parameter der Vielzahl von VMMs auswertet und, basierend auf der Auswertung der Betriebsmittelbenutzungs-Parameter, einen VMM aus der Vielzahl von VMMs ermittelt, welcher dafür vorgesehen ist, das privilegierte Ereignis abzuwickeln.
24. System nach Beispiel 20, wobei es sich bei dem privilegierten Ereignis um irgendeines aus einer Unterbrechung, einer Ausnahmesituation, einer Ausführung eines privilegierten Befehls und einem Plattformereignis handelt.
25. System nach Beispiel 20, wobei das privilegierte Ereignis während des Betriebs von Nebensoftware oder einem aus der Vielzahl von VMMs auftritt.
26. Maschinenlesbares Medium, welches Befehle enthält, welche dann, wenn sie durch ein Betriebssystem ausgeführt werden, bewirken, dass das Betriebssystem ein Verfahren ausführt, wobei das Verfahren das Folgende umfasst: Erkennen eines Auftretens eines privilegierten Ereignisses; Ermitteln, welcher aus einer Vielzahl von Monitoren virtueller Maschinen (VMMs) das privilegierte Ereignis abwickeln soll; und Übertragen der Steuerung auf den einen aus der Vielzahl von VMMs.
27. Maschinenlesbares Medium nach Beispiel 26, wobei die Vielzahl von VMMs einen Haupt-VMM und einen oder mehrere parallele VMMs aufweist.
28. Maschinenlesbares Medium nach Beispiel 26, wobei es sich bei dem privilegierten Ereignis um irgendeines aus einer Unterbrechung, einer Ausnahmesituation, einer Ausführung eines privilegierten Befehls und einem Plattformereignis handelt.
29. System nach Beispiel 26, wobei das privilegierte Ereignis während des Betriebs von Nebensoftware oder einem aus der Vielzahl von VMMs auftritt.

Claims

Prozessor mit einer Leitwegelogik in Form eines Mikrocodes, einer programmierbaren Logik oder einer hartcodierten Logik, wobei die Leitwegelogik ausgebildet ist, das folgende Verfahren auf dem Prozessor auszuführen, wenn darauf mehrere Virtual Machine Monitore parallel eingerichtet sind: Erkennen des Auftretens eines privilegierten Ereignisses während des Betriebs von Gast-Software auf einer virtuellen Maschine (VM) oder während des Betriebs eines Virtual Machine Monitors, wobei privilegierte Ereignisse von der Gast-Software nicht behandelt werden können und die mehreren Virtual Machine Monitore eingerichtet sind, privilegierte Ereignisse zu behandeln; Ermitteln des Typs des erkannten privilegierten Ereignisses; Ermitteln eines Wertes aus einem Prozessor-Register oder einem Speicher im Plattform-Chipsatz, das bzw. der mit dem Typ des privilegierten Ereignisses verbunden ist; Identifizieren eines der eingerichteten Virtual Machine Monitore durch den ermittelten Wert, um das erkannte privilegierte Ereignis durch den identifizierten Virtual Machine Monitor zu behandeln; Leiten des erkannten privilegierten Ereignisses zum identifizierten Virtual Machine Monitor; Erzeugen eines VM-Exit Befehls, um die Steuerung von der aktuell ausgeführten Gast-Software beziehungsweise dem aktuell ausgeführten Virtual Maschine Monitor auf den identifizierten Virtual Machine Monitor zu übertragen.
Prozessor nach Anspruch 1, wobei die Vielzahl von VMMs einen Haupt-VMM und mehrere parallele VMMs aufweist.
Prozessor nach Anspruch 1, wobei das Ermitteln, welcher aus der Vielzahl von VMMs das erkannte privilegierte Ereignis abwickeln soll, das Folgende umfasst: Auswerten von Betriebsmittel-Benutzungsparametern der Vielzahl von VMMs; und Identifizieren eines VMM aus der Vielzahl von VMMs, welcher dafür vorgesehen ist, das erkannte privilegierte Ereignis abzuwickeln, basierend auf der Auswertung der Betriebsmittel-Benutzungsparameter.
Prozessor nach Anspruch 3, wobei das Betriebsmittel sich in irgendeinem von einem Speicher, einem Prozessor, einem Chipsatz und einer Eingabe-Ausgabe-Einheit befindet.
Prozessor nach Anspruch 1, wobei es sich bei dem erkannten privilegierten Ereignis um irgendeines aus einer Unterbrechung, einer Ausnahmesituation, einer Ausführung eines privilegierten Befehls und einem Plattformereignis handelt.
Prozessor nach Anspruch 1, wobei die Vielzahl von VMMs auf einer Plattformhardware ausgeführt werden.
System, welches das Folgende umfasst: eine Vielzahl von Monitoren virtueller Maschinen (VMMs), die eingerichtet sind, um eine Vielzahl von privilegierten Ereignissen abzuwickeln; und ein Prozessor nach Anspruch 1.
System nach Anspruch 7, wobei die Vielzahl von VMMs einen Haupt-VMM und einen oder mehrere parallele VMMs aufweist.
System nach Anspruch 7, wobei es sich bei dem erkannten privilegierten Ereignis um irgendeines aus einer Unterbrechung, einer Ausnahmesituation, einer Ausführung eines privilegierten Befehls und einem Plattformereignis handelt.
System nach Anspruch 7, wobei die Leitwegelogik durch hardwarekodierte Logik verwirklicht ist.
System nach Anspruch 7, wobei ein privilegiertes Ereignis während eines Betriebs eines aus der Vielzahl der VMMs auftritt.
System nach Anspruch 7, welches ferner das Folgende umfasst: einen Speicher, auf welchem die Nebensoftware und die Vielzahl von Monitoren virtueller Maschinen (VMMs) gespeichert sind, die eingerichtet sind, die Vielzahl von privilegierten Ereignissen abzuwickeln; und wobei der Prozessor an den Speicher gekoppelt ist, um die Nebensoftware auszuführen, um das Auftreten des einen von der Vielzahl von privilegierten Ereignissen, die nicht von der Nebensoftware abgewickelt werden können, zu erkennen.
System nach Anspruch 12, wobei die Vielzahl von VMMs einen Haupt-VMM und einen oder mehrere parallele VMMs aufweist.
System nach Anspruch 12, wobei es sich bei dem privilegierten Ereignis um irgendeines aus einer Unterbrechung, einer Ausnahmesituation, einer Ausführung eines privilegierten Befehls und einem Plattformereignis handelt.
System nach Anspruch 12, wobei das erkannte privilegierte Ereignis während des Betriebs von einem aus der Vielzahl von VMMs auftritt.
Verfahren, das von einem Prozessor nach Anspruch 1 ausgeführt wird, umfassend: Erkennen des Auftretens eines privilegierten Ereignisses während des Betriebs von Gast-Software auf einer virtuellen Maschine (VM) oder während des Betriebs eines Virtual Machine Monitors, wobei privilegierte Ereignisse von der Gast-Software nicht behandelt werden können und die mehreren Virtual Machine Monitore eingerichtet sind, privilegierte Ereignisse zu behandeln; Ermitteln des Typs des erkannten privilegierten Ereignisses; Ermitteln eines Wertes aus einem Prozessor-Register oder einem Speicher im Plattform-Chipsatz, das bzw. der mit dem Typ des privilegierten Ereignisses verbunden ist; Identifizieren eines der eingerichteten Virtual Machine Monitore durch den ermittelten Wert, um das erkannte privilegierte Ereignis durch den identifizierten Virtual Machine Monitor zu behandeln; Leiten des erkannten privilegierten Ereignisses zum identifizierten Virtual Machine Monitor; Erzeugen eines VM-Exit Befehls, um die Steuerung von der aktuell ausgeführten Gast-Software beziehungsweise dem aktuell ausgeführten Virtual Maschine Monitor auf den identifizierten Virtual Machine Monitor zu übertragen.