-
Technisches Gebiet
-
Ausführungsformen
der vorliegsenden Erfindung betreffen im allgemeinen Computersysteme und
insbesondere die Funktionssteuerung virtueller Maschinen in Computersystemen.
-
Hintergrund
-
Durch
die Architektur einer virtuellen Maschine wird eine physikalische
Maschine logisch partitioniert, so daß die zugrunde liegende Hardware
der Maschine zeitanteilig geteilt wird und als eine oder mehrere
unabhängig
voneinander arbeitende virtuelle Maschinen (VM) erscheint. Ein Virtuelle-Maschine-Monitor
(VMM) läuft
auf einem Computer und erleichtert anderer Software die Abstrahierung
einer oder mehrerer VMn. Jede VM kann als eine eigenständige Plattform
funktionieren, auf der ihr eigenes Betriebssystem (OS) und Anwendungssoftware
läuft. Die
in einer VM laufende Software wird hier kollektiv als Gast-Software
bezeichnet.
-
Die
Gast-Software erwartet so zu arbeiten, als ob sie auf einem zweckbestimmten
Computer und nicht in einer VM laufen würde. Das bedeutet, daß die Gast-Software
erwartet, verschiedene Ereignisse zu steuern und auf Hardware-Ressourcen
auf dem Rechner (z. B. der physikalischen bzw. realen Maschine)
zuzugreifen. Die Hardware-Ressourcen der realen Maschine können einen
oder mehrere Prozessoren, sich auf den Prozessoren befindende Ressourcen
(z. B. Steuerungsregister, Caches und andere), Speicher (und sich
in einem Speicher befindende Strukturen, wie z. B. Deskriptortabellen)
und andere Ressourcen (wie z. B. Eingabe-Ausgabevorrichtungen) umfassen, die
sich in der realen Maschine befinden. Die Ereignisse können Interrupts
(Programmunterbrechungen), Exceptions (Ausnahmen), Plattformereignisse
(z. B. Initialisierungs- (INIT) oder Systemverwaltungsinterrupts
(SMIs) und dergleichen) umfassen.
-
Der
VMM kann Gast-Softwarezustände
in und aus den Vorrichtungen, dem Speicher und den Registern der
realen Maschine je nach Bedarf umlagern. Der VMM kann die Leistungsfähig keit
einer VM erhöhen,
indem ein direkter Zugriff auf die zugrundeliegende physikalische
Maschine zugelassen wird. Das kann insbesondere dann zweckmäßig sein, wenn
in der Gast-Software
ein Betrieb in einem nicht privilegierten Modus ausgeführt wird,
wodurch der Zugriff der Software auf die physikalische Maschine eingeschränkt ist,
oder wenn Operationen Hardwareressourcen in der physikalischen Maschine
nicht verwenden, über
welche der VMM die Kontrolle behalten möchte.
-
Der
VMM erlangt die Kontrolle dann wieder, wenn ein Gast-Vorgang bzw.
-Programmschritt bzw. -Operation die korrekte Ausführung des
VMM oder einer beliebigen der nicht ausführenden VMn beeinflußt. Gewöhnlich prüft der VMM
derartige Vorgänge, wobei
er bestimmt, ob ein Problem besteht, bevor das Fortschreiten des
Vorgangs zur zugrundeliegenden physikalischen Maschine zugelassen
wird, oder er den Vorgang im Auftrag eines Gastes emuliert. Beispielsweise
kann es notwendig sein, daß der VMM
die Kontrolle wiedererlangt, wenn der Gast auf I/O-Vorrichtungen
zugreift, wenn er versucht, die Maschinenkonfiguration (z. B. durch Ändern der
Steuerregisterwerte) zu ändern,
wenn er versucht, auf bestimmte Speicherbereiche zuzugreifen, und
dergleichen.
-
Bestehende
Systeme, bei welchen ein VM-Betrieb unterstützt wird, steuern die Ausführungsumgebung
einer VM unter Verwendung einer Struktur mit festem Format, auf
die hierin als Virtuelle-Maschine-Steuerungsstruktur (Virtual Machine Control
Structure, VMSS) Bezug genommen wird. Die VMSS ist in einem Speicherbereich
gespeichert und enthält
beispielsweise den Zustand des Gastes, den Zustand des VMM und die
Steuerungsinformation, die angibt, unter welchen Bedingungen der
VMM die Kontrolle während
der Gastausführung
wiedererlangen möchte.
Der Prozessor (die Prozessoren) in der physikalischen Maschine liest
(lesen) Informationen von der VMSS, um die Ausführungsumgebung der VM und des
VMM zu bestimmen, und um das Verhalten der Gast-Software unter der
Steuerung des VMM einzuschränken.
-
Bei
herkömmlichen
Architekturen wird die VMSS im Speicher der physikalischen bzw.
realen Maschine angeordnet und wird dem VMM der Zugriff darauf unter
Verwendung gewöhnlicher
Speicherlese- und Schreibbefehle gewährt. Aus diesem Grund muß das Format
der VMSS architektonisch in der Prozessorbefehlssatzarchitektur
definiert werden (und ähnlich
wie bei anderen Systemstrukturen und Befehlskodierungen in Beschreibungen
und Anleitungen dokumentiert werden). Der VMM ist direkt für diese
Spezifizierungen kodiert. Durch diese Strukturierung wird die Flexibilität bei der
Implementierung des (der) Prozessors (Prozessoren), welche den VMM
unterstützen,
eingeschränkt.
Da die Form der VMSS Architektur-definiert ist, kann die Mikroarchitektur
einer speziellen Prozessorimplementierung keine Änderung am Format, an den Inhalten,
der Organisation oder den Speicheranforderungen der VMSS-Daten aus
Gründen
der Leistungsfähigkeit, Erweiterbarkeit,
Kompatibilität,
Sicherheit und dergleichen vornehmen, ohne daß ebenfalls entsprechende Modifizierungen
an der installierten Basis der VMM-Implementierungen erforderlich
sind.
-
Daher
besteht ein Bedarf an flexibleren Implementierungen von Architekturen
für virtuelle
Maschinen, die nicht starr mit der zugrundeliegenden Implementierung
der realen Maschinen gekoppelt sind.
-
US 6,397,242 B1 offenbart
ein Virtualisierungssystem mit einem virtuellen Maschinenmonitor für einen
Computer mit einer segmentierten Architektur. Daraus ist bekannt,
dass ein virtueller Maschinenmonitor eine Architekturkompatibilität zwischen unterschiedlichen
Prozessorarchitekturen unter Zuhilfenahme einer binären Emulation
oder binären Translation
herstellen kann.
-
Es
ist die Aufgabe der vorliegenden Erfindung, einen Prozessor bereitzustellen,
der unabhängig
vom Datenlayout einer virtuellen Maschinensteuerungsstruktur Zugriffe
auf die virtuelle Maschinensteuerungsstruktur durch einen virtuellen
Maschinenmonitor ohne die Notwendigkeit einer Anpassung des virtuellen
Maschinenmonitors an eine jeweilige virtuelle Maschinensteuerungsstruktur
zulässt
sowie ein entsprechendes Verfahren.
-
Die
Aufgabe wird gelöst
durch einen Prozessor mit den Merkmalen gemäß Anspruch 1 sowie durch ein
Verfahren mit den Merkmalen gemäß Anspruch
4. Ausführungsformen
der Erfindung sind in den Unteransprüchen angegeben.
-
Kurzbeschreibung der Zeichnungen
-
1 ist
ein Diagramm einer VM-Architektur gemäß einer Ausführungsform
der Erfindung.
-
2 ist
ein Ablaufdiagramm eines Verfahrens zur Steuerung einer VM gemäß einer
Ausführungsform
der Erfindung.
-
3 ist
ein Diagramm eines VMSS-Zugriffsbefehls gemäß einer Ausführungsform
der Erfindung.
-
4 ist
ein Ablaufdiagramm eines Verfahrens zum Lesen von Daten von einer
VMSS gemäß einer
Ausführungsform
der Erfindung.
-
5 ist
ein Ablaufdiagramm eines Verfahrens zum Schreiben von Daten in eine
VMSS gemäß einer
Ausführungsform
der Erfindung.
-
Beschreibung der Ausführungsformen
-
Es
wird eine neuartige VM-Steuerungsarchitektur beschrieben. In der
vorliegenden detaillierten Beschreibung der Ausführungsformen wird auf die begleitenden
Zeichnungen Bezug genommen, die einen Teil davon bilden und in welchen
für Darstellungszwecke,
jedoch ohne Beschränkung,
spezielle ausführbare
Ausführungsformen
der Erfindung gezeigt sind. Diese Ausführungsformen werden mit ausreichenden
Einzelheiten beschrieben, die einem Durchschnittsfachmann ihr Verständnis und
ihre Implementierung ermöglichen.
Es ist jedoch zu beachten, daß andere
Ausführungsformen
verwendet werden können
und daß strukturelle, logische
und elektrische Änderungen
daran vorgenommen werden können,
ohne von der Idee und vom Umfang der vorliegenden Offenbarung abzuweichen.
Die folgende detaillierte Beschreibung ist daher nicht in einem
beschränkenden
Sinn zu verstehen und der Umfang der Ausführungsformen der hier offenbarten
Erfindungen wird lediglich durch die beigefügten Ansprüche definiert.
-
Ein
VMM stellt für
andere Software (wie z. B. „Gast-Software", „Gäste" oder einfach „Gast") die Abstraktion
einer oder mehrere VMn dar. Der VMM kann den verschiedenen Gästen dieselbe
oder verschiedene Abstraktionen bieten. Jeder Gast erwartet, daß ihm sämtliche
Möglichkeiten
(facilities) der in der VM dargestellten Hardwareplattform für seinen
Gebrauch zur Verfügung
stehen. Beispielsweise erwartet der Gast, daß er Zugriff auf alle Register,
Caches, Strukturen, I/O-Vorrichtungen, Speicher und dergleichen
gemäß der Architektur
des Prozessors und der in der VM dargestellten Plattform hat. Des
weiteren erwartet jeder Gast, daß er verschiedene Ereignisse, wie
beispielsweise Ausnahmen (exceptions), Interrupts und Plattformereignisse,
wie z. B. die Initialisierung (INIT) und Systemverwaltungsinterrupts
(SMIs) behandeln kann.
-
Einige
dieser Ressourcen und Ereignisse sind „privilegiert", da sie vom VMM
verwaltet werden müssen,
um einen korrekten Betrieb der VMn sicherzustellen und den VMM und
andere VMn zu schützen.
Für die
privilegierten Ressourcen und Ereignisse vereinfach der VMM die
von der Gast-Software gewünschte
Funktionalität,
während
er die letztendliche Kontrolle über
diese Ressourcen und Ereignisse beibehält. Der Vorgang des Vereinfachens
der Funktionalität
für die
Gast-Software kann eine Vielzahl von Aktivitäten auf der Seite des VMM umfassen.
Die Aktivitäten
des VMM sowie seine Eigenschaften begrenzen nicht den Umfang der
verschiedenen Ausführungsformen
der vorliegenden Erfindung.
-
Wenn
eine Gast-Software auf privilegierte Ressourcen zugreift oder falls
ein privilegiertes Ereignis auftritt, kann die Kontrolle bzw. Steuerung
auf den VMM übertragen
werden. Der Transfer der Kontrolle von der Gast-Software auf den
VMM wird als ein VM-Austritt (exit) bezeichnet. Nachdem der Ressourcenzugriff
erleichtert ist oder das Ereignis in entsprechender Weise behandelt
wurde, kann der VMM die Kontrolle an die Gast-Software zurückgeben.
Der Transfer der Kontrolle vom VMM an die Gast-Software wird als
ein VM-Eintritt (entry) bezeichnet.
-
Die
Virtuelle-Maschine-Steuerungsstruktur (VMSS) ist eine architektonisch
definierte Struktur, die beispielsweise den Zustand der Gast-Software, den
Zustand des VMM, Steuerunginformationen, die angeben, unter welchen
Bedingungen der VMM wünscht,
den Gast von einer Ausführung
abzuhalten, und Informationen, welche den kürzlichsten bzw. letzten VM-Austritt betreffen,
umfaßt.
Bei gängigen Systemen
befindet sich eine Darstellung der VMSS, die mit der architektonisch
definierten Struktur exakt übereinstimmt,
im Speicher. Der Prozessor in der physikalischen Maschine liest
die Informationen von der VMSS, um die Ausführungsumgebung der VM zu bestimmen
und ihr Verhalten zu beschränken.
-
Während der
Gast-Ausführung
fragt der Prozessor die Kontrollinformationen in der VMSS ab, um zu
bestimmen, welche Gast-Aktionen (z. B. die Ausführung bestimmter Befehle, das
Auftreten bestimmter Ausnahmen etc.) und Ereignisse (z. B. externe
Interrupts) VM-Austritte verursachen. Wenn ein VM-Austritt auftritt,
werden Komponenten des Prozessorstatus, die von der Gast-Software
verwendet werden, in der VMSS gespeichert und Komponenten des Prozessorstatus,
die vom VMM angefordert werden, von der VMSS geladen. Wenn ein VM-Austritt auftritt,
wird die Steuerung an den VMM 120 unter Verwendung beliebiger
dem Durchschnittsfachmann bekannter Mechanismen weitergegeben.
-
Wenn
ein VM-Eintritt erfolgt, wird der Prozessorstatus, der beim VM-Austritt
gespeichert wurde (und der durch den VMM modifiziert sein kann)
wiederhergestellt und die Steuerung an die Gast-Software zurückgegeben.
Um den ersten VM-Eintritt für
einen Gast zu erleichtern, schreibt der VMM einen geeigneten Gast-Status
in die VMSS. Während
ein VM-Austritt verarbeitet wird, kann der VMM einen Gast-Status
in der VMSS ändern.
Bei einigen Ausführungsformen
werden mehrere VMSS-Strukturen, die mehrere VMn unterstützen, von
einem einzigen VMM auf einer einzigen physikalischen Maschine verwaltet.
Die VMSSen müssen
nicht die gesamte oben beschriebene Information umfassen und können zusätzlich Informationen
umfassen, die bei der Steuerung der VM unterstützen. Bei einigen Ausführungsformen
kann eine VMSS einen beträchtlichen Umfang
an zusätzlichen
Informationen umfassen.
-
1 veranschaulicht
ein Diagramm einer VM-Architektur 100 gemäß einer
Ausführungsform der
Erfindung. Die VM-Architektur 100 umfaßt eine Basishardwareplattform 110 (z.
B. eine physikalische Maschine). Die Basishardwareplattform 110 umfaßt einen
oder mehrere Prozessoren 112, die jeweils Zugriff auf einen
flüchtigen
und/oder nicht flüchtigen Speicher 116 haben.
Zusätzlich
können
andere Elemente von der Basishardwareplattform umfaßt sein, die
in 1 nicht gezeigt sind (wie z. B. Eingabe-Ausgabe-Vorrichtungen).
Die VM-Architektur 100 umfaßt auch
einen VMM 120, der ein oder mehrere VMn (z. B. 130, 140 und 150)
verwaltet, wobei jede VM (z. B. 130, 140 und 150)
eines oder mehrere OSe (z. B. 150, 160 und 170)
und Anwendungen (z. B. 152, 162 und 172)
unterstützt.
Die Prozessoren 112 können
von jeder Art eines Prozessors sein, der sich zur Ausführung von
Software eignet, wie beispielsweise ein Mikroprozessor, ein digitaler
Signalprozessor, ein Mikrokontroller oder dergleichen. Die Prozessoren 112 können einen
Mikrocode, eine programmierbare Logik oder eine festkodierte Logik
zur Durchführung
der Ausführung
von Verfahrensausführungsformen
der vorliegenden Erfindung umfassen.
-
Bei
dem Speicher 116 kann es sich um eine Festplatte, eine
Floppydisc, einen Direktzugriffsspeicher (RAM), einen Lese-Nur-Speicher
(ROM), einen Flash-Speicher und um Kombinationen der oben genannten
Vorrichtungen oder um jede beliebige andere Art eines mittels eines
Prozessors 112 lesbaren Maschinenmediums handeln. Im Speicher 116 können Befehle
oder Daten zur Durchführung
der Ausführung
von Verfahrensausführungsformen
der vorliegenden Erfindung gespeichert sein.
-
Der
Speicher 116 umfaßt
einen VMSS-Bereich 118 zur Verwendung durch den Prozessor 112 beim
Aufrechterhalten des Status der VMSS, wie in weiteren Einzelheiten
nachfolgend beschrieben ist.
-
Die
Prozessoren 112 können
von jeder Art eines Prozessors sein, der sich zur Ausführung von Software
eignet, wie beispielsweise ein Mikroprozessor, ein Digitalsignalprozessor,
ein Mikrokontroller oder dergleichen. Jeder Prozessor 12 kann
einen VMSS-Cache 114 umfassen, der in weiteren Einzelheiten
im folgenden beschrieben ist. Die Prozessoren 112 können Mikrocode,
eine programmierbare Logik oder eine festkodierte Logik zur Durchführung der
Ausführung
von Verfahrensausführungsformen der
vorliegenden Erfindung umfassen.
-
Falls
er vorhanden ist, kann der VMSS-Cache 114 zur temporären Speicherung
oder zur Speicherung während
der gesamten Lebensdauer einiger oder aller VMSS-Stati verwendet
werden. Der VMSS-Cache 114 kann Register, einen Cache-Speicher
oder jeden beliebigen anderen Speicher umfassen. In 1 ist
der VMSS-Cache 114 als Teil des Prozessors 112 gezeigt.
Er kann sich jedoch auch außerhalb
des Prozessors 112 in jeder beliebigen Komponente der bloßen Plattformhardware 110 befinden.
In der folgenden Erläuterung
wird der VMSS-Cache 114 auch als „Prozessor-interner Speicher" oder „Prozessor-interne
Ressourcen" bezeichnet.
Man beachte jedoch, daß sich
dieser Speicher auch in anderen Plattformkomponenten als dem Prozessor 112 befinden.
Der VMSS-Cache 114 ist für die Implementierung der erfindungsgemäßen Verfahren nicht
zwingend erforderlich.
-
Herkömmlicherweise
würde ein
VMM auf eine VMSS im Speicher unter Verwendung gewöhnlicher
Lese- und Schreibbefehle zugreifen. In der VM-Architektur 100 aus 1 greift
der VMM 120 jedoch indirekt durch eine Gruppe vom Prozessor
bereitgestellter VMSS-Zugriffsbefehle 119 auf
den VMSS-Bereich 118 zu. Die VMSS-Zugriffsbefehle 114 verwenden
den VMSS-Bereich 118 und irgendeinen beliebigen verfügbaren VMSS-Cache 114.
Bei einer Ausführungsform
umfassen die VMSS-Zugriffsbefehle 119 einen Operanden,
der ein Kennzeichner der VMSS-Komponente ist, auf die zugegriffen
wird. Der Kennzeichner wird hier als ein „Komponenten-Kennzeichner" bezeichnet. Der
VMM 120 muß nicht
in Kenntnis darüber
sein, daß irgendeine
spezielle VMSS-Komponente im VMSS-Bereich 118 oder im VMSS-Cache 114 gespeichert
ist. Die VM-Architektur 100 gewährleistet des weiteren, daß unvorhersehbare
Ergebnisse auftreten können,
falls gewöhnliche
Lese- und Schreibbefehle zum Zugriff auf den VMS-Bereich 118 verwendet
werden. Die Verwendung der VMSS-Zugriffsbefehle 119 gewährt dem Prozessor 112 Freiheiten
bezüglich
seines Gebrauchs eines verfügbaren
Prozessor-internen bzw. -integrierten und Speicher-basierten Speichers
(z. B. der VMSS-Bereich 118) und läßt auch eine Vielzahl von Leistungsoptimierungen
zu.
-
Bei
einigen Ausführungsformen
werden die VMSS-Zugriffsbefehle 119 durch die Prozessormikroarchitektur
durch Lesen von und Schreiben in Speicher im VMSS-Bereich 118 implementiert.
Bei anderen Ausführungsformen
können
die VMSS-Zugriffsbefehle 119 prozessorinterne Ressourcen
lesen und/oder in diese schreiben. Der VMM 120 muß nicht darüber unterrichtet
sein, wie die zugrunde liegende physikalische Maschinenmikroarchitektur
die VMSS unterstützt.
Auf diese Weise kann die zugrunde liegende Prozessorimplementierung
zur Berücksichtigung
der Leistung, Sicherheit, Zuverlässigkeit
oder anderer Betrachtungen modifiziert werden, ohne den VMM 120 mit
der zugrunde liegenden Prozessorimplementierung inkompatibel zu
machen, und es können
für jede
Prozessorimplementierung individualisierte VMSS-Implementierungen
entwickelt werden.
-
Das
folgende Beispiel veranschaulicht den Nachteil einer VM-Architektur,
bei der keine VMSS-Zugriffsbefehle 119 verwendet werden.
Falls eine Prozessorimplementierung VMSS- Daten in einem Prozessor-internen Speicher
temporär
speichern kann, erfolgt ein Schreiben von Daten in den speicherinternen
VMSS-Bereich lediglich dann, wenn ein spezielles Ereignis auftritt.
Während
der Zeitperiode, in der die VMSS-Daten zwischengespeichert sind,
gibt ein gewöhnliches
Lesen an den VMSS-Bereich 118 einen Stale-Wert (einen inkorrekten
Wert) zurück.
Ein gewöhnliches
Schreiben in den VMSS-Bereich 118 aktualisiert nicht die
Daten im prozessorinternen Speicher, sofern keine speziellen Vorkehrungen
mittels der Prozessorimplementierung getroffen werden, um den Schreibvorgang
richtig auf den Speicher abzubilden. Ohne die Verwendung der VMSS-Zugriffsbefehle 119 muß die Prozessorimplementierung
den VMSS-Bereich mit jedem temporären oder in prozessorinternen
Ressourcen zwischengespeicherten Status konsistent halten. Das kann bestimmte
Leistungsoptimierungen, Erweiterungen der VM-Architektur etc., wie
in weiteren Einzelheiten im nachfolgenden erläutert wird, ausschließen. Im Gegensatz
zu den gewöhnlichen
Speicheroperationen geben VMSS-Lesebefehle gegebenenfalls einen prozessorintern
gespeicherten Wert zurück
und VMSS-Schreibbefehle aktualisieren den VMSS-Zustand korrekt,
wo auch immer er sich befindet. Diese Befehle werden in Einzelheiten
im nachfolgenden beschrieben.
-
Um
die VMSS-Zugriffsbefehle 119 zu vereinfachen, wird jedes
Element der VMSS durch eine architektonisch definierte Konstante
identifiziert, die die Komponente der VMSS identifiziert. Diese
Konstanten-Werte werden hier als „Komponenten-Kennzeichner" bezeichnet. Bei
einer Ausführungsform handelt
es sich bei dem Komponenten-Kennzeichner um einen 16-Bit-Wert, der
jedoch bei anderen Ausführungsformen
größer oder
kleiner sein kann.
-
Bei
der folgenden Erläuterung
wird eine Anzahl von Feldern in der VMSS bei Beschreibungen verschiedener
Ausführungsformen
der Erfindung verwendet. Beispielsweise ist GUEST_EIP das Feld, das
den Befehlszeiger für
die Gast-Software enthält, VM_CONTROLS
das Feld, das Bits enthält,
die die VM-Ausführungsumgebung
steuern, etc. Ein Verständnis
der Syntax und Semantik der verschiedenen Felder ist für das Verständnis der
hier beschriebenen Erfindung nicht notwendig. Zusätzlich sind den
Feldern spezifische architektonisch definierte Komponenten-Kennzeichner
gegeben. Die speziellen bei den Beispielen verwendeten Felder und
Werte der Komponenten-Kennzeichner beschränken in keiner Weise die Anwendbarkeit
der Erfindung.
-
Eine
Darstellung des Vorteils der Verwendung der VMSS-Befehle 119 ist
wie folgt. Man beachte, daß eine
Prozessorimplementierung das im VMSS-Bereich 118 gespeicherte
Daten layout von einer Prozessorimplementierung zu einer anderen ändern kann.
Beispielsweise kann bei einer ersten Prozessorimplementierung das
GUEST_EIP-Feld des VMSS-Bereichs beginnend beim 28. Byte des VMSS-Bereichs
gespeichert sein. Bei einer zweiten Prozessorimplementierung kann
dasselbe VMSS-Feld beim 16. Byte im VMSS-Bereich gespeichert sein.
Ein VMM 120, der für
eine Anfangsimplementierung geschrieben ist und die VMSS-Zugriffsbefehle 119 verwendet,
ist auch auf der letzteren Implementierung des Prozessors 112 funktional,
obwohl sich das Layout des VMSS-Bereichs 118 geändert hat.
Diese Kompatibilität
wird erreicht, da die Implementierung der VMSS-Zugriffsbefehle in
den beiden Prozessorimplementierungen das Layout des verwendeten
VMSS-Bereichs 118 verstehen und entsprechend auf die notwendigen
Daten zugreifen.
-
Bei
einigen Ausführungsformen
kann es zur Vereinfachung der VMSS-Zugriffsbefehle 119 erforderlich
sein, dem VMM 120 einen Speicherbereich (z. B. den VMSS-Bereich 118)
zur Seite zu stellen, um den gesamten oder einen Teil des vom Prozessor 112 für die VMSS
benötigten
Speichers unterzubringen. Bei diesen Ausführungsformen der Erfindung ermöglicht es
ein vom Prozessor gelieferter Befehl, daß der VMM 120 einen
Zeiger oder eine Adresse des VMSS-Bereichs 118 zum Prozessor 112 liefert. Bei
einer Ausführungsform
ist die Adresse eine physikalische Adresse. Bei anderen Ausführungsformen können virtuelle
oder lineare Adressen verwendet werden. Die dem Prozessor 112 unter
Verwendung dieses Befehls zur Verfügung gestellte Adresse wird im
nachfolgenden als ein VMSS-Zeiger bezeichnet. Dieser Befehl informiert
den Prozessor 112 über
den Ort des VMSS-Bereichs 224. Dieser neue Befehl aktiviert
eine VMSS, die vom Prozessor 112 insgesamt oder zum Teil
in mit dem VMSS-Zeiger
bezeichneten VMSS-Bereich 118 gespeichert sein kann.
-
Gemäß einer
weiteren Ausführungsform kann
ein Mechanismus bereitgestellt werden, der es ermöglicht,
daß der
VMM 120 den Speicherumfang 116 herausfinden kann,
der für
einen VMSS-Bereich 118 reserviert werden muß. Beispielsweise
kann in der Prozessorbefehlssatzarchitektur (ISA) des Intel Pentium
IV (auf die hier als die IA-32 ISA Bezug genommen wird) ein modellspezifisches
Register (MSR) bereitgestellt werden, das die erforderliche VMSS-Bereichsgröße umfaßt. Gemäß einer
weiteren Ausführungsform
wird ein Befehl bereitgestellt, der die erforderliche VMSS-Bereichsgröße zurückgibt. Jeder
andere verfügbare
Mechanismus kann verwendet werden, um diese Information zum VMM
zu übertragen.
Auf diese Weise kann sich die Größe des erforderlichen
Speicherbereichs 118 von einer Prozes sorimplementierung
zu einer anderen ändern, ohne
daß eine
Umgestaltung oder Umkompilierung des VMM 120 zwingend wäre.
-
Beispielsweise
sei angenommen, daß ein erster
Prozessor 112 für
den VMSS-Bereich 118 im Speicher 116 64 Byte benötigt. Dieses
Erfordernis wird dem VMM 120, wie oben beschrieben, berichtet. Ein
VMM 120 wird unter Verwendung des oben beschriebenen Mechanismus
zur Bestimmung, wieviel Speicher 116 dem VMSS-Bereich 118 zuzuweisen ist,
so geschrieben, daß er
auf dieser Prozessorimplementierung läuft. Eine zweite Prozessorimplementierung
wird erzeugt, die nun 128 Byte für
einen VMSS-Speicher im Speicher 116 benötigt. Der für die erste Prozessorimplementierung
geschriebene VMM 120 wird auch auf der zweiten Implementierung
korrekt funktionieren, da er den für den VMSS-Bereich 118 korrekten
Speicherumfang zuweisen wird.
-
Während der
VMSS-Zeiger aktiv ist, kann der Prozessor 112 den gesamten
oder einen Teil der VMSS im VMSS-Bereich 118 oder alternativ
in sich auf dem Prozessor 112 befindenden Ressourcen oder
an jedem beliebigen anderen verfügbaren
Ort (d. h. im VMSS-Cache 114) speichern. Zusätzlich kann
der Prozessor 112 nicht architektonische Statusinformation
im VMSS-Bereich 118 oder in prozessorinternen Ressourcen
speichern. Beispielsweise kann der Prozessor 112 temporäre Variablen,
mikroarchitektonische, einer VM (z. B. 130, 140 oder 150)
zugeordnete Stati, Indikatoren des Status der VM (z. B. 130, 140 oder 150)
und dergleichen speichern. Die Software verwendet keine gewöhnlichen Speicherlese-
und Schreibvorgänge,
um auf den VMSS-Bereich zuzugreifen, während der VMSS-Zeiger aktiv
ist. Diese Beschränkung
stellt die Korrektheit des Betriebs des VMM 120 und der
dem VMSS zugeordneten VM (z. B. 130, 140 oder 150)
sicher.
-
Ein
weiterer vom Prozessor bereitgestellter Befehl schreibt beliebige
VMSS-Daten, die in prozessorinternen Ressourcen zwischengespeichert
waren, in den VMSS-Bereich 118, invalidiert die entsprechenden
Daten im prozessorinternen Speicher und deaktiviert des weiteren
den VMSS-Zeiger. Gemäß einer
Ausführungsform
kann die VMSS beispielsweise durch Schreiben eines Statusindikators,
der architektonisch oder nicht architektonisch definiert ist, in den
VMSS-Bereich als inaktiv markiert werden. Gemäß einer anderen Ausführungsform
kann der prozessorinterne Speicher einfach entleert und der prozessorinterne
Status für
die VMSS deaktiviert (invalidiert) werden. Dieser Befehl wird vor
jedem Versuch des VMM 120, die Inhalte des VMSS-Bereichs 118 zu bewegen,
ausgeführt.
Wenn ein VMM 120 versucht, den VMSS-Bereich 118 zu
bewegen, kann er dies mit einer einzigen Datenblockbewegung ausführen, da das
VMSS-Format beibehalten wird und nur der Prozessorimplementierung
bekannt ist. Zusätzlich
ist diese Blockbewegung möglich,
da der VMM über
die Größe des VMSS-Bereichs
unterrichtet ist (er hat den Speicher basierend auf den hier beschriebenen
Mechanismen zugewiesen). Individuelle Elemente der VMSS müssen für den VMM 120 nicht
erkennbar sein.
-
Bei
einigen Ausführungsformen
kann ein für eine
spezielle Ausführungsform
spezifischer Mechanismus es zulassen, daß der VMM 120 die
Prozessorimplementierung identifiziert, die eine spezielle VMSS
eingerichtet hat. Der VMM 120 kann diese Prozessoridentifizierung
dazu verwenden, um zu bestimmen, ob die VMSS mit einer anderen Prozessorimplementierung
kompatibel ist. Bei einer Ausführungsform
befindet sich dieser Kennzeichner in den ersten vier Bytes des VMSS-Bereichs 118 und
wird an den VMM 120 beispielsweise in einer MSR oder mit
Hilfe jedes anderen Verfahrens berichtet. Vor dem ersten Gebrauch
einer VMSS kann es erforderlich sein, daß der VMM 120 diesen
Kennzeichner an die geeignete Stelle in der VMSS schreibt und somit kann
das Format dieses Teils des VMSS-Bereichs 118 architektonisch
definiert werden. Bei einigen Ausführungsformen ist es ersterbenswert,
daß alle Implementierungen
identische, architektonisch definierte Teile des VMSS-Bereichs 118 definieren.
-
Bei
anderen Ausführungsformen
können neue
architektonisch definierte Teile des VMSS-Bereichs 118 definiert sein,
vorausgesetzt, daß vorherige
Ausführungsformen
die neu definierten Bereiche undefiniert gelassen haben und die
neu definierten Bereiche nicht mit dem Betrieb eines VMM 120 interferieren,
der keinen expliziten Gebrauch davon macht. Auf diese Weise sind
beliebige für
diese Ausführungsformen
geschriebene VMMe 120 auf den neueren Implementierungen
betriebsfähig.
-
Bei
einigen Ausführungsformen
umfassen die vom Prozessor bereitgestellten Befehle 119 eine Zahl
unterschiedlicher Befehle:
- – ein VMSS-Lade-Zeiger-Befehl
umfaßt
eine Speicheradresse als einen Operanden. Diese Adresse ist der
Ort, an dem der Prozessor 120 die VMSS (die z. B. den Beginn
des VMSS-Bereichs 118)
speichern kann. Die dieser Adresse zugeordnete VMSS wird durch den
Befehl aktiviert. Dieser Befehl ermöglicht auch die Aktivierung
einer VM (z. B. 130, 140 oder 150), die
der VMSS zugeordnet und von dieser gesteuert wird, und den Gebrauch
verschiedener anderer nachfolgend beschriebener Befehle. Bei einer
Ausführungsform handelt
es sich bei der Adresse um eine physikalische Adresse. Bei anderen
Ausführungsformen kann
eine virtuelle oder lineare Adresse verwendet werden.
- – ein
VMSS-Speicher-Zeiger-Befehl speichert einen Zeiger auf den aktiven
VMSS-Bereich 118 in einem
Register (z. B. im Prozessor 112) oder an einem Speicherort
(z. B. im Speicher 116). Die Stelle eines derartigen Speicherorts
kann dem Befehl als Operand zur Verfügung gestellt werden.
- – ein
VMSS in ein Register (ein VMSS-Lesebefehl liest eine Komponente
der z. B. im Prozessor 112) oder einen Speicherort (z.
B. im Speicher 116). Der Befehl kann eine Zahl von Parameter
einschließlich
eines Komponenten-Kennzeichners umfassen, der die VMSS-Komponente, die von der
VMSS gelesen werden soll, und den Ort bezeichnet (z. B. das Register
oder den Speicherort), an dem die von bzw. aus der VMSS gelesenen
Daten gespeichert werden sollen.
- – ein
VMSS-Schreibbefehl lädt
eine Komponente der VMSS aus einem Register (z. B. im Prozessor 112)
oder von einem Speicherort (z. B. im Speicher 116). Ähnlich wie
der VMSS-Lesebefehl kann ein VMSS-Schreibbefehl Operanden für den VMSS-Komponenten-Kennzeichner umfassen. Zusätzlich kann
er einen den Ort (z. B. das Register oder den Speicherort) der in
die VMSS zu schreibenden Daten beschreibenden Operanden umfassen.
- – ein
VMSS-Löschungsbefehl
stellt sicher, daß die Inhalte
der gesamten prozessorinternen, der VMSS zugeordneten Speicherung
in den VMSS-Bereich 118 zurückgespeichert werden, invalidiert
Daten in den prozessorinternen Ressourcen und deaktiviert des weiteren
den VMSS-Zeiger. Dieser Befehl kann ohne Operanden arbeiten, wobei
ein momentan aktiver VMSS-Zeiger beseitigt und deaktiviert wird,
oder kann bei einer alternativen Ausführungsform den VMSS-Zeiger, für den das
Beseitigen und die Deaktivierung erforderlich ist, als Operanden
nehmen. Bei einer Ausführungsform
kann ein VMSS-Löschungsbefehl
die VMSS durch Schreiben eines architektonisch oder nicht-architektonisch
definierten Statusindikators in den VMSS-Bereich als inaktiv markieren.
-
Schließlich bewirkt
ein VMSS-Eingabebefehl einen Transfer der Steuerung (d. h. einen
VM-Eintritt) zur durch die aktive VMSS definierten VM (z. B. 130, 140 oder 150)
durch Laden eines Prozessorstatus entsprechend der Semantik der
VM-Architektur 100 und des Inhalts der VMSS. Alternativ
kann der Befehl ein einzugebendes Argument zusammen mit dem VMSS-Zeiger
(oder dem Ort dieses Zeigers) umfassen.
-
Die
oben beschriebenen, vom Prozessor gelieferten Befehle 119 geben
lediglich eine Ausführungsform
wieder, da eine Vielzahl verschiedener oder alternativer Befehle 119 vorgesehen
werden kann. Beispielsweise kann der VMSS-Löschungsbefehl bei einigen Ausführungsformen
VMSS-Daten von einem prozessorinternen Speicher in den VMSS-Bereich 118 kopieren,
ohne daß der VMSS-Zeiger
deaktiviert wird. Operanden können explizit
oder implizit sein. Andere Befehle 119 (oder Varianten
der oben dargelegten Befehle 119), die auf alle im Prozessor 112 aktiven
VMSS-Zeiger wirken und dergleichen können vorgesehen werden.
-
Wie
für den
Fachmann erkennbar ist, umfassen herkömmliche VM-Architekturen eine
statische, architektonisch definierte Form für die VMSS im Speicher. Dadurch
ist die Fähigkeit
der Prozessorimplementierungen, die Größe, die Organisation oder die
Inhalte der VMSS zu erweitern oder zu ändern, begrenzt, da Änderungen
an der VMSS entsprechende Änderungen
der VMM-Implementierungen erfordern würden. Zusätzlich weist die Prozessorimplementierung
bei der Zuweisung von Speicher der VMSS-Daten zu prozessorinternen
Ressourcen eine geringere Flexibilität auf, da herkömmliche
VMMe unter Verwendung gewöhnlicher
Speicher-Lese- und Schreiboperationen auf herkömmliche VMSSen zugreifen. Beispielsweise
kann es sein, daß der
Prozessor nicht in der Lage ist, bestimmte Teile der VMSS in prozessorinternen
Ressourcen während
eines VM-Austritts zum VMM zwischenzuspeichern, da der Prozessor
Schwierigkeiten bei der Erfassung, ob der VMM Modifizierungen an
den entsprechenden Bereichen der VMSS im Speicher ausgeführt hat,
haben kann. Dieses Unvermögen,
die Kohärenz
zwischen den prozessorinternen Ressourcen und den speicherinternen
VMSS-Bildern zu
bestätigen,
verkompliziert die Fehler- und Konsistenzprüfung, die vor dem Ausführen von
Gast-Software in der Folge eines VM-Eintritts erforderlich sein
kann.
-
Jedoch
greifen bei verschiedenen Ausführungsformen
der vorliegenden Erfindung die VMMe 120 nicht direkt auf
das VMSS-Speicherbild unter Verwendung gewöhnlicher Speicher-Lese- und Schreiboperationen
zu, verwenden kein vordefiniertes Format für die VMSS im Speicher 116 und
bestimmen die erforderliche Speichergröße für die VMSS im Speicher 116 in
Laufzeit.
-
Das
Binden von VMSS-Speichererfordernissen in Laufzeit und die Verwendung
von vom Prozessor gelieferten Befehlen 119, wie oben beschreiben wurde,
ist in 2 dargestellt. 2 veranschaulicht den
Zustand des VMSS-Zeigers durch eine Vielzahl von Aktivitäten im VMM.
Die Verarbeitung beginnt im Block 210. Zu diesem Zeitpunkt
gibt es keinen aktiven VMSS-Zeiger. Im Block 210 bestimmt
der VMM die Größe des vom
Prozessor zur Unterstützung
der VMSS benötigten
Speicherbereichs. Wie oben beschrieben, kann dies beispielsweise
durch Lesen eines bestimmten MSR erreicht werden.
-
Im
Block 220 ordnet der VMM den benötigten Speicher zu. Der VMSS-Zeiger
ist immer noch inaktiv. Obwohl dieser Speicherbereich optimalerweise im
physikalischen Speicher benachbart bzw. nahtlos ist, ist für den Fachmann
erkennbar, daß dieses
Erfordernis bei dieser Ausführungsform
nicht erforderlich ist. Der VMM aktiviert die VMSS durch Liefern
der Adresse des VMSS-Bereichs zum Prozessor unter Verwendung des
VMSS-Lade-Zeiger-Befehls,
der oben beschrieben wurde (Eintritt in Block 230). An diesem
Punkt wird der VMSS-Zeiger als ein arbeitender VMSS-Zeiger bezeichnet.
Nachdem der VMSS-Zeiger aktiv ist, kann der VMM Komponenten der
VMSS unter Verwendung der geeigneten VMSS-Zugriffsbefehle (die in 1 als 119 und
in 2 als 232 und 234 gezeigt sind)
lesen und schreiben. Auf diese Lese- oder Schreiboperationen folgend
bleibt der VMSS-Zeiger aktiv.
-
Wenn
der VMM beabsichtigt, dem Gast die Ausführung zu erlauben, verwendet
er den VM-Eintrittsbefehl,
um den Gast in die Maschine zu laden (Eintritt in Block 240).
Nach dem VM-Eintritt
ist der VMSS-Zeiger immer noch aktiv, wobei er jedoch nun als ein
steuernder VMSS-Zeiger funktioniert, der vom Prozessor dazu verwendet
wird, die Umgebung und das Verhalten der Gast-Ausführung zu
bestimmen.
-
Wenn
ein VM-Austritt erfolgt, kehrt die Steuerung zum VMM zurück (unter
Rückkehr
vom Block 240 zum Block 230). Der VMSS-Zeiger
bleibt wieder als ein arbeitender VMSS-Zeiger aktiv. Der VMM kann
VMSS-Felder (Pfeile 232 und 234) in geeigneter
Weise lesen und schreiben und kann den Gast wiederum unter Verwendung
des VM-Eintrittsbefehls (unter Rückkehr
zum Block 240) einführen.
Alternativ kann der VMM den VMSS-Zeiger unter Verwendung des VM-Löschungsbefehls
deaktivieren, wobei zu diesem Zeitpunkt der VMSS-Zeiger inaktiv wird (unter Rückkehr zum
Zustand 220).
-
Man
beachte, daß das
Verfahren 200 nicht auf eine bestimmte Folge von Arbeitsschritten
beschränkt
ist, da der VMM zu jedem beliebigen Zeitpunkt eine Vielzahl von
Arbeitsschritten ausführen kann
(z. B. VM-Lesen, VM-Schreiben, VM-Eintritt, etc.). Zusätzlich kann
zu jedem beliebigen Zeitpunkt, in dem ein gegebener Prozessor das
Verfahren 200 verwendet, ein einzelner VMSS-Zeiger oder
eine Vielzahl von VMSS-Zeigern aktiv oder inaktiv sein. Bei einigen
Ausführungsformen
können
mehrere VMSSs in einem gegebenen Prozessor zu einem beliebigen Zeitpunkt
aktiv sein. Auf diese Weise kann ein VMM zwischen VMn umschalten,
ohne einen VMSS-Löschungsbefehl
auszuführen,
wodurch die Verarbeitungseffizienz der VM verbessert wird.
-
Bei
einer Ausführungsform
kann ein zusätzlicher
vom Prozessor gelieferter Befehl den VMM in die Lage versetzen,
die Zahl gleichzeitiger oder paralleler VMSSen, die zu einem bestimmten
Zeitpunkt aktiv sein können,
abzufragen und zu erhalten. Bei anderen Ausführungsformen kann ein MSR bereitgestellt
werden, das der VMM lesen kann, um diese Information zu erhalten.
Bei einer alternativen Ausführungsform
kann die Zahl der VMSS-Zeiger, die gleichzeitig aktiv sein können (und
daher beispielsweise in prozessorinternen Ressourcen zwischengespeichert
sein können),
für die
VMM-Software nicht direkt erkennbar sein, wobei die Prozessorimplementierung Überlaufbedingungen
automatisch behandelt, wenn ein VMM mehr VMSS-Zeiger aktiviert,
als der Prozessor in prozessorinternen Ressourcen speichern kann.
In diesem Fall kann der Prozessor geeignete VMSS-Daten zu zugeordneten
VMSS-Bereichen im
Speicher automatisch entleeren. Bei einigen Ausführungsformen können in
einer Anzahl der vom Prozessor gelieferten und oben anhand der Erläuterung
der 1 beschriebenen Befehle explizite VMSS-Zeigerargumente
erforderlich sein.
-
Bei
bestimmten Ausführungsformen
der vorliegenden Erfindung werden Anforderungen an die Software,
die mit der Verwaltung der prozessorinternen und speicherinternen
Speicherung der VMSS-Daten verbundenen Details zu bewältigen, beseitigt.
Somit verwaltet der VMM jede der VMn, die seiner Steuerung unterliegt,
auf einem höheren
Abstraktionsniveau. Diese Strategie ermöglicht, daß die oben in Verbindung mit 1 und 2 erläuterten vom
Prozessor gelieferten Befehle die Details der VMSS-Speicherung verwalten,
so daß die
VM-Ausführung
durch Hinzufügen
oder Modifizieren der vom Prozessor gelieferten Befehle günstiger
und optimaler geändert
oder erweitert werden kann, ohne die bestehende VMM-Software zu ändern.
-
3 ist
ein Diagramm, in dem der Gebrauch der VMSS-Lese-/Schreib-Befehle
bei einer Ausführungsform
der vorliegenden Erfindung abgebildet ist. Es ist das architektonische
VMSS-Format 305 gezeigt, obwohl es nicht explizit vom VMM
verwendet wird. Vielmehr wird der VMM unter Kenntnis der VMSS-Komponenten-Kennzeichner,
Feldgrößen und
Feldsemantik programmiert, jedoch nicht mit einer architektonischen
Definition der Form der VMSS-Speicherung im Speicher. Wenn ein VMM
auf ein Feld in der architektonischen VMSS 305 zugreifen
möchte,
führt er
ein VMSS-Lesen (oder gegebenenfalls VMSS-Schreiben) durch. In 3 ist
zur Veranschaulichung lediglich das VMSS-Lesen gezeigt. Ein Parameter
für den
VMSS-Lese-Befehl 310 ist ein Komponenten-Kennzeichner,
wobei es sich um eine architektonisch definierte Konstante handelt, die
die Komponente der VMSS definiert. Der Prozessor verwendet den Komponenten-Kennzeichner
je nach Zweckmäßigkeit
zur Abbildung auf prozessorinterne (z. B. den VMSS-Cache 322)
oder speicherinterne Ressourcen (z. B. den VMSS-Bereich 324),
um auf die VMSS-Daten im Auftrag des VMM unter Verwendung einer
Abbildefunktion 320 zuzugreifen. Falls die im VMSS-Bereich
oder im VMSS-Cache
gespeicherten Daten nicht im architektonisch definierten Format
vorliegen, werden die Daten in geeigneter Weise unter Verwendung
einer Umformatierungsfunktion 323 für eine Anpassung umformatiert.
-
Zwei
beispielhafte VMSS-Zugriffsbefehle sind in 3 gezeigt.
Obwohl beide Beispiele sich auf VMSS-Lesebefehle beziehen, tritt
eine ähnliche Gruppe
von Aktivitäten
für VMSS-Schreib-Befehle auf,
wie in den nachfolgenden Erläuterungen
mit Bezug auf 5 in Einzelheiten angegeben
ist.
-
Unter
Bezugnahme auf 3 greift ein erster beispielhafter
VMSS-Lese-Befehl 310 auf die GUEST_EIP-Komponente zu, die
eine architektonisch definierte Kodierung von 0 × 4032 aufweist. Die Prozessorimplementierung
hält Daten
für diese
Komponente im VMSS-Bereich 324 aufrecht, wie durch die
Abbildefunktion 320 bestimmt ist. Der Prozessor liest die
entsprechenden Komponentendaten vom VMSS-Bereich 324 unter
Verwendung eines Speicherlesevorgangs 330. Der Lesevorgang 330 versteht
den Ort der Komponente im VMSS-Bereich 324 (wie wiederum
durch die Abbildefunktion 320 bestimmt ist; bei diesem
Beispiel befindet er sich beim Offset 12 im VMSS-Bereich). Der Prozessor
gibt dann den Datenwert zum VMM zurück (wie als Pfeil 331 gezeigt
ist).
-
Ein
zweiter beispielhafter VMSS-Lese-Befehl 350 greift auf
die VM_CONTROLS-Komponente zu,
die eine architektonisch definierte Kodierung von 0 × 1076 aufweist.
Diese Prozessorimplementierung behält diese Komponente im VMSS-Cache 322 bei (wie
durch die Abbildefunktion 320 bestimmt ist). Der Prozessor
greift auf den VMSS-Cache 322 zu, um die Daten wiederzugewinnen.
In diesem Fall werden die Daten prozessorintern in einer Form gespeichert,
die nicht mit der architektonischen Definition der VM_CONTROLS-Komponente zusammenpaßt (z. B. die
Daten werden prozessorintern als ein umgeordnetes 8-Byte-Objekt gespeichert,
während
die architektonische Definition des VM_CONTROLS-Feldes ein 4-Byte-Objekt ist). Der Prozessor
formatiert die VM_CONTROLS-Daten vor einer Rückgabe der Daten zur VM unter
Verwendung der Umformatierungsfunktion 323 um, so daß sie mit
der architektonischen Definition des Feldes übereinstimmen. Dieser umformatierte
Wert (d. h. der Wert, der mit der architektonischen Definition der
angeforderten Komponente zusammenpaßt) wird zum VMM zurückgegeben
(wie als Pfeil 326 gezeigt ist).
-
Unter
Verwendung dieser VMSS-Zugriffsbefehle ist ein VMM, der eine oder
mehrere VMn verwaltet, von welchen jede durch eine separate VMSS identifiziert
ist, zur Verwaltung der einer VMSS zugeordneten Speicherung nicht
erforderlich, da sie vom Speicher in prozessorinternen Ressourcen
zwischengespeichert wird. Zusätzlich
muß der
VMM sich ändernde
Einzelheiten bezüglich
der Prozessorimplementierung, wie beispielsweise die Formatierung von
Daten im Speicher oder in prozessorinternen Ressourcen, nicht bewältigen.
Somit können
Prozessorentwickler die VMSS-Zugriffsbefehle ändern oder modifizieren, um
die Leistungsfähigkeit
der VM zu verbessern und die Fähigkeiten
der VM zu erweitern, ohne den Betrieb bestehender VMMe oder VMn nachteilig
zu beeinflussen. Bestehende VMMe und VMn können jedoch von derartigen Änderungen
profitieren, da die Leistungsfähigkeit,
Zuverlässigkeit, Skalierbarkeit
oder andere Verbesserungen an neue Implementierungen der VM-Architektur
weitergegeben werden.
-
4 ist
ein Ablaufdiagramm eines Verfahrens 400 zur Ausführung eines
VMSS-Lese-Befehls gemäß einer
Ausführungsform
der vorliegenden Erfindung. In 410 wird eine VMSS-Lese-Aufforderung (read
request) von einem VMM empfangen. In 420 wird der VMSS-Komponenten-Kennzeichner
von der VMSS-Leseaufforderung erfaßt. Beim Komponenten- Kennzeichner handelt
es sich um eine architektonisch definierte Konstante, die die gewünschte Komponente
der VMSS identifiziert.
-
Ein
Prozessor überprüft den Komponenten-Kennzeichner
in 430, um zu bestimmen, ob die dem Komponenten-Kennzeichner
zugeordnete VMSS-Komponente sich im Speicher befindet. Falls die
VMSS-Komponente im Speicher gespeichert ist, wird die Adresse der
Speicherstelle in 440 berechnet und werden die der VMSS-Komponente
zugeordneten VMSS-Daten in 450 erfaßt. Falls jedoch die VMSS-Komponente
nicht im Speicher gespeichert ist, erhält der Prozessor die der VMSS-Komponente zugeordneten
VMSS-Daten aus dem prozessorinternen Speicher in 460. Auf
diese Weise verwendet der Prozessor den Komponenten-Kennzeichner, um
die Leseaufforderung auf den VMSS-Komponentenspeicher abzubilden,
wenn sie sich im Speicher oder im prozessorinternen Speicher befindet.
-
In 470 wird
eine Überprüfung durch
den Prozessor durchgeführt,
um zu bestimmen, ob ein Umformatieren der VMSS-Daten erforderlich
ist, bevor die VMSS-Daten an den VMM zurückgegeben werden. Falls die
VMSS-Daten im Format gespeichert sind (entweder im VMSS-Bereich
oder in prozessorinternen Ressourcen), das sich vom architektonisch definierten
Datenformat für
die VMSS-Komponente unterscheidet (d. h. die VMSS-Komponente ist
in einem für
die Implementierung spezifischen Datenformat gespeichert, das sich
vom architektonisch definierten Format unterscheidet), wird in 480 auf
eine Umformatierungsfunktion zugegriffen, um die für die Implementierung
spezifischen VMSS-Daten in ein architektonisch definiertes Datenformat
zu übertragen. Falls
die VMSS-Daten im architektonisch definierten Datenformat für die VMSS-Komponente
gespeichert sind (entweder im VMSS-Bereich oder in prozessorinternen
Ressourcen), ist keine Umformatierungsfunktion oder Übersetzung
für die
VMSS-Daten erforderlich. Schließlich
werden in 490 die VMSS-Daten (die sich nunmehr im architektonisch
definierten Datenformat befinden) zum VMM zurückgegeben.
-
5 ist
ein Ablaufdiagramm eines Verfahrens 500 zur Ausführung eines
VMSS-Schreib-Befehls
gemäß einer
Ausführungsform
der vorliegenden Erfindung. In 505 erhält ein Prozessor eine VMSS-Schreibaufforderung
(write request) von einem VMM. Der Prozessor ermittelt als einen
der Operanden der Schreibaufforderung den Komponenten-Kennzeichner,
wie in 510 dargestellt ist. Darüber hinaus ermittelt der Prozessor
in 515 als einen weiteren Operanden die Schreibdaten, die
in die VMSS geschrieben werden sollen. Diesen Schreibdaten lie gen
in einem architektonisch definierten Datenformat für die geschriebene
VMSS-Komponente
vor.
-
In 520 wird
eine Überprüfung durchgeführt, um
zu bestimmen, ob die VMSS-Komponente in einem architektonisch definierten
Datenformat vom Prozessor gespeichert wird (im VMSS-Bereich oder in prozessorinternen
Ressourcen). Dementsprechend wird, falls die VMSS-Komponente nicht
im architektonisch definierten Datenformat gespeichert ist, in 520 die
geeignete Umformatierung der Daten ausgeführt, so daß die Daten im geeigneten für die Implementierung
spezifischen Datenformat vorliegen, das der VMSS-Komponente, auf
die zugegriffen wird, zugeordnet ist. Das Format, in dem die Daten
gespeichert werden, kann identisch zum architektonisch definierten
Format sein oder sich davon bezüglich
der Größe oder
der Organisation unterscheiden.
-
Als
nächstes
wird in 530 eine weitere Überprüfung durchgeführt, um
den Ort zu bestimmen, an dem die VMSS-Komponente vom Prozessor gespeichert
wird. Unter Verwendung des Komponenten-Kennzeichners bestimmt der
Prozessor, wo sich der Speicher für die VMSS-Komponente befindet. Falls sich der
Speicherort im Speicher befindet, wird in 535 die Speicheradresse
berechnet und werden in 540 die Schreibdaten an den Speicherort
geschrieben. Falls sich jedoch der Speicherort nicht im Speicher
befindet, wird in 545 der richtige Ort im prozessorinternen
Speicher bestimmt und werden die Schreibdaten in den prozessorinternen
Speicher geschrieben. Die in den Speicher geschriebenen Daten liegen
im für
die Implementierung spezifischen Datenformat vor, bei dem es sich
abhängig
von der fraglichen VMSS-Komponente,
der Prozessorimplementierung und bei einigen Ausführungsformen
abhängig davon,
ob die fragliche Komponente momentan in prozessorinternen Ressourcen
oder im VMSS-Bereich gespeichert ist, um dasselbe oder ein anderes als
das architektonisch definierte Format handeln kann.
-
Der
in den Prozessen 400 und 500 verwendete Mechanismus
zur Bestimmung des Speicherortes für eine bestimmte VMSS-Komponente
und zur Bestimmung, ob die VMSS-Komponente im architektonisch definierten
Datenformat vom Prozessor gespeichert wurde, sind für die Implementierung
spezifisch. Bei einer Ausführungsform
wird vom Prozessor eine Lookup-Tabelle
verwendet, die mittels des Komponenten-Kennzeichners indiziert ist.
Zusätzlich
ist zu beachten, daß,
falls mehrere VMSS-Zeiger gleichzeitig aktiv sind, diese Bestimmungen
davon abhängen
können,
auf welche VMSS zugegriffen wird.
-
Der
Fachmann wird nach dem Lesen und Begreifen dieser Offenbarung verstehen,
wie die Erfindung in einem auf einem Computer basierenden System
implementiert werden kann, um die hier offenbarten Verfahren durchzuführen. Die
Erfindung kann unter Verwendung von Software (wie sie auf einem
allgemein verwendbaren Computersystem oder einer zweckbestimmten
Maschine verwendet wird), Hardware (Schaltungsanordnungen, zweckbestimmter
Logik, programmierbarer Logik, Mikrocode, etc.) oder einer Kombination
aus Hardware und Software implementiert sein.
-
Es
ist zu beachten, daß die
oben angegebene Beschreibung der Veranschaulichung dient und nicht
als Beschränkung
anzusehen ist. Dem Fachmann ergeben sich bei der Durchsicht der
oben angegebenen Beschreibung viele andere Ausführungsformen. Der Umfang der
erfindungsgemäßen Ausführungsformen
sollte daher unter Bezugnahme auf die beigefügten Ansprüche zusammen mit dem gesamten
Umfang der Äquivalente,
der durch diese Ansprüche
berechtigt ist, bestimmt werden.
-
Es
wird betont, daß die
Zusammenfassung den 37 C.F.R. § 1.72(b)
erfüllt,
der eine Zusammenfassung erfordert, die es dem Leser ermöglicht,
rasch die Natur und das Wesentliche der technischen Offenbarung
bestimmen zu können.
Sie sollte jedoch nicht zur Auslegung oder Beschränkung des
Umfangs oder der Bedeutung der Ansprüche verwendet werden.
-
Bei
der vorhergehenden Beschreibung der Ausführungsformen sind verschiedene
Merkmale in einer einzelnen Ausführungsform
zur Rationalisierung der Offenbarung gruppiert. Diese Art der Offenbarung
sollte nicht dahingehend interpretiert werden, daß dadurch
beabsichtigt wird, daß die
beanspruchten Ausführungsformen
der Erfindung mehr Merkmale erfordern als im jeweiligen Anspruch
ausdrücklich genannt
sind. Vielmehr liegt der Gegenstand der Erfindung, wie durch die
folgenden Ansprüche
wiedergegeben wird, in weniger als allen Merkmalen einer einzelnen
offenbarten Ausführungsform.
Somit werden die folgenden Ansprüche
hiermit in die Beschreibung der Ausführungsformen miteinbezogen,
wobei jeder Anspruch für
sich als eine getrennte beispielhafte Ausführungsform anzusehen ist.