DE112015006934T5

DE112015006934T5 - Verschachtelte Virtualisierung für virtuelle Maschinenexits

Info

Publication number: DE112015006934T5
Application number: DE112015006934.8T
Authority: DE
Inventors: Kai Wang; Bing Zhu; Peng Zou; Manohar R. Castelino
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-09-25
Filing date: 2015-09-25
Publication date: 2018-06-14
Also published as: US20190108051A1; CN107924321A; US10146570B2; CN107924321B; US10963281B2; WO2017049584A1; US20170262306A1

Abstract

Es werden Speichersicherheitstechnologien beschrieben. Eine beispielhafte Verarbeitungsvorrichtung beinhaltet einen Prozessorkern und eine Speichersteuervorrichtung, die mit dem Prozessorkern und einem Speicher verbunden ist. Der Prozessorkern kann feststellen, dass eine Exit-Bedingung zum Übertragen der Steuerung einer Ressource für einen Prozessorkern von einem ersten virtuellen Maschinenmonitor (VMM) zu einem zweiten VMM aufgetreten ist. Der Prozessorkern kann auch feststellen, ob ein Steuerverbindungszeiger einer virtuellen Maschine Steuerstruktur (Virtual Machine Control Structure; VMCS) gültig ist. Der Prozessorkern kann auch feststellen, ob ein Grund-Wert, der dem Steuer-VMCS-Verbindungszeiger entspricht, gesetzt ist. Der Prozessorkern kann auch feststellen, ob der Grund-Wert auf Null gesetzt ist. Der Prozessorkern kann auch feststellen, ob ein Ausnahme-Bit, das einem spezifischen Ausnahmetyp eines Grund-Werts entspricht, gesetzt ist. Der Prozessorkern kann auch eine Steuerung der Ressource von dem ersten VMM zu dem zweiten VMM übertragen.

Description

HINTERGRUND
Eine Rechenvorrichtung führt typischerweise ein einzelnes Betriebssystem (OS) aus, das auf Hardwareressourcen der Verarbeitungsvorrichtung zugreifen kann. Virtualisierung ermöglicht es jedoch, dass mehrere virtuelle Maschinen (VMs) auf der Rechenvorrichtung ausgeführt werden. Eine VM kann eine Softwareinstanziierung einer Rechenumgebung oder eines OS sein. Bei der Virtualisierung werden mehrere VMs instanziiert und jede VM führt ihre eigene Instanz eines OS aus. Das OS jeder VM kann unabhängig von anderen VMs ausgeführt werden. Zum Beispiel kann ein erstes OS nicht darüber in Kenntnis sein, dass es innerhalb einer VM ausgeführt wird, und dass andere OSs auf anderen VMs für die gleiche Rechenvorrichtung ausgeführt werden. Ein Hypervisor oder ein virtuelle Maschine Monitor (VMM) kann Hardwareressourcen der Rechenvorrichtung virtualisieren, um Zugriff auf die Hardwareressourcen für die VMs bereitzustellen. Ein Satz von Virtualisierungsanweisungen kann es dem Hypervisor ermöglichen, in einem Root-Modus zu arbeiten, während Gast-OSs und Anwendungssoftware in Nicht-Root-Modi laufen können.
Figurenliste

1 veranschaulicht eine virtuelle Maschinenumgebung zum Verbinden von Gast-Software mit einer Verarbeitungsvorrichtung gemäß einer Ausführungsform.
2 veranschaulicht Virtualisierungsanweisungen für einen virtuelle Maschine Monitor (VMM) für den Betrieb in einer virtuellen Maschinenumgebung gemäß einer Ausführungsform.
3 zeigt ein System für verschachtelte Virtualisierungstechnologie (VT) gemäß einer Ausführungsform.
4A veranschaulicht eine Konfiguration eines VT-Systems gemäß einer Ausführungsform.
4B veranschaulicht eine Tabelle von virtuelle Maschinen (VM) Exitereignissen, die von der VT-Architektur für unterschiedliche Daten in einer verschachtelten VT-Umgebung ausgeführt werden, gemäß einer Ausführungsform.
5A veranschaulicht ein VM-Exitrelais zwischen VMMs, das in einem VT-System gemäß einer Ausführungsform ausgeführt wird.
5B veranschaulicht einen VM-Exit, der direkt von eine VMM in dem VT-System ausgeführt wird, gemäß einer Ausführungsform.
6 zeigt ein Flussdiagramm eines Verfahrens zum Übertragen von Ressourcensteuerung von einem Level 1 (L1) L1-VMM auf einen Level 2 (L2) Gast gemäß einer Ausführungsform.
7 veranschaulicht die virtuelle Maschine Steuerstruktur (VMCS) vor dem Übertragen der Ressourcensteuerung auf den L2 Gast gemäß einer Ausführungsform.
8 zeigt ein Flussdiagramm eines Verfahrens zum Schalten der Ressourcensteuerung von dem L2 Gast zu dem L1-VMM oder dem L0-VMM gemäß einer Ausführungsform.
9 veranschaulicht das Schalten einer aktuellen VMCS zu der VMCS, wenn das Übertragen der Ressourcensteuerung von dem L2 Gast auf den L1-VMM erfolgt ist, gemäß einer Ausführungsform.
10 veranschaulicht schematisch ein Blockdiagramm eines Systems nach einer beispielhaften Implementierung.
11 veranschaulicht schematisch ein Blockdiagramm eines Prozessors nach einer beispielhaften Implementierung.
12 veranschaulicht schematisch ein Blockdiagramm eines beispielhaften Verarbeitungssystems gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung.
13 veranschaulicht schematisch ein beispielhaftes Verfahren zur Befähigung eines virtuellen Systems zum Durchführen gewisser privilegierter Operationen ohne den VMM zu verlassen gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung.
14 veranschaulicht schematisch ein Blockdiagramm eines beispielhaften Verarbeitungssystems gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung.
15 veranschaulicht schematisch eine beispielhafte Implementierung einer virtuellen Adressenumsetzung gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung.
16 veranschaulicht schematisch beispielhafte Formate von Paging-Struktureinträgen, die von einem Verarbeitungssystem, das gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung arbeitet, verwendet werden können.
17 veranschaulicht schematisch eine beispielhafte funktionale Beziehung zwischen externen Host-Interrupts und virtuellen, externen Gast-Interrupts, die von einem Verarbeitungssystem implementiert werden, das gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung arbeitet.
18 veranschaulicht schematisch ein beispielhaftes Verfahren zum Implementieren von Speichervirtualisierung unter Verwendung eines TLB gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung.

BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Virtuelle Maschinen (VMs) können eine Architektur oder Funktionen einer physischen Rechenvorrichtung emulieren. Die VM ist zum Beispiel eine Betriebsumgebung, die auf Rechenhardware der physischen Rechenmaschine mit ihrem eigenen Betriebssystem (OS) ausgeführt wird. Eine VM kann Anwendungen ausführen, die innerhalb der Grenzen ihres jeweiligen OS laufen. Zusätzlich können mehrere VMs auf der physischen Rechenvorrichtung ausgeführt werden, wobei jeder VM-Handhabungsaufwand einer Ausführung auf seiner eigenen Hardware zugeordnet ist. Dieser Aufwand stellt den ordnungsgemäßen unabhängigen Betrieb jeder VM sicher. Ein Hypervisor oder ein virtuelle Maschine Monitor (VMM) kann Hardwareressourcen der physischen Rechenvorrichtung virtualisieren, um Zugriff auf die Hardwareressourcen für die VMs bereitzustellen.
Verschachtelte Visualisierung erlaubt es einem Root-VMM Gast-VMMs zu unterstützen. Es werden zum Beispiel Hardwareressourcen virtualisiert, um einen Root-Modus-VMM zu befähigen, einen Nicht-Root-Modus-VMM als einen Gast effizient auszuführen. In einer Ausführungsform kann eine Verarbeitungsvorrichtung verschachtelte Virtualisierung unter Verwendung einer Trap-and-Emulate-Technik durchführen, wobei Hardware individuelle Virtualisierungsanweisungen, die von einem Gast-VMM ausgegeben werden, auffängt und ein Root-Modus-Hypervisor die individuellen Virtualisierungsanweisungen emuliert. Eine hohe Frequenz von Virtualisierungsanweisungen an kritischen Codepfaden der Verarbeitungsvorrichtung verlangsamt die Trap-and-Emulate-Technik jedoch in einem nicht akzeptablen Rahmen. Wenn ein VMM zum Beispiel die VM verlassen muss, um Adressenumsetzungen durchzuführen und dann nach der Adressenumsetzung wieder zu der VM zurückkehren muss, reduziert die Aufgabe zum Beenden und Zurückkehren die Leistung der Verarbeitungsvorrichtung. In einer anderen Ausführungsform kann eine Verarbeitungsvorrichtung verschachtelte Virtualisierung unter Verwendung einer dynamischen Umsetzungstechnik verwenden, wobei privilegierte Codesequenzen von einem Gast-VMM in Anweisungen umgesetzt werden, die sicher innerhalb einer Gast-VM eingegrenzt sind. Die dynamische Umsetzungstechnik ist jedoch kompliziert und hat äußerst negative Leistungsauswirkungen auf die Arbeitslasten der Verarbeitungsvorrichtung.
Das Ausführen bestimmter Anweisungen auf einer VM kann einen Exit aus der VM (hierin als VM-Exit bezeichnet) erforderlich machen, damit die Anweisungen ordnungsgemäß gehandhabt werden können. Der VM-Exit ist ein Übergang von einer derzeit laufenden VM und der Ausübung von Kontrolle über Ressourcen der Rechenvorrichtung zu einem VMM der VM, die die Kontrolle über die Ressourcen ausübt. Der VM-Exit erfolgt in Reaktion auf bestimmte Anweisungen oder Ereignisse in dem Virtualisierungssystem und bewirkt eine signifikante Leistungsverschlechterung. Herkömmlich schaltet eine Verarbeitungsvorrichtung, wenn eine VM in einem Virtualisierungssystem beendet wird, von einem Nicht-Root-Modus zu einem Root-Modus. Das Schalten von dem Nicht-Root-Modus in den Root-Modus veranlasst virtuelle Maschinenverlängerungs (VMX) Übergänge, die CPU-Zyklen verschwenden und den Leistungsaufwand erhöhen. Wenn zum Beispiel ein VM-Exit eintritt, speichert eine Verarbeitungsvorrichtung eine Momentaufnahme des Zustands der VM, wie sie zum Zeitpunkt des Exits gelaufen ist.
Der VM-Exit kann bei Anweisungen eintreten, die Deskriptor-Tabellen handhaben. Anweisungen, wie ein Load Global Deskriptortabellen (LGDT) Register und eine Load Interrupt Deskriptortabelle (LIDT), machen VM-Exits erforderlich, um die Anforderungen im Zusammenhang mit den Anweisungen innerhalb des VM-Kontexts ordnungsgemäß bearbeiten zu können. Der Verarbeitungszeitaufwand des VM-Exits ist jedoch signifikant und reduziert eine Leistung der VM. Ein VM-Exit macht zum Beispiel das Speichern des Verarbeitungszustands, das Neukodieren von Informationen über den VM-Exit-Vorgang, das Speichern der aktuellen Zustände der Deskriptortabellen usw. erforderlich.
Hierin beschriebene Ausführungsformen gehen auf die vorstehend angeführten Defizite eines Virtualisierungssystems, das einen VMM in einer virtuellen Maschinenerweiterungs (VMX) Root-Operation zum Steuern, welcher VM-Exit von der Verarbeitungsvorrichtung in einem Nicht-Root-Modus direkt ohne VMX-Übergänge gehandhabt werden kann, befähigt, ein. Ein Vorteil des Steuerns, welcher VM-Exit von der Verarbeitungsvorrichtung in einem Nicht-Root-Modus direkt ohne VMX-Übergänge gehandhabt werden kann, ist die Reduzierung des Aufwands für den VM-Exit. Die reduzierten VM-Exits erhöhen die Effizienz durch Reduzierung der Virtualisierungslatenz.
1 veranschaulicht eine virtuelle Maschinenumgebung 100 zum Verbinden von Gast-Software 108, 110, 112 und 114 mit einer Verarbeitungsvorrichtung 102 gemäß einer Ausführungsform. Die Verarbeitungsvorrichtung 102, die die virtuelle Maschinenumgebung 100 ausführt, kann Hardware-unterstützte Unterstützung für Virtualisierung bereitstellen. Ein VMM 116 kann VMs 104 und 106 mit der Verarbeitungsvorrichtung 102 verbinden. Die Software, die innerhalb der VM 104 ausgeführt wird, kann ein Gast-OS 110 und diverse Softwareanwendungen 108 umfassen. Die Software, die innerhalb der VM 106 ausgeführt wird, kann ein Gast-OS 114 und diverse Softwareanwendungen 112 umfassen. Die virtuelle Maschinenumgebung 100 kann VMX-Anweisungen verwenden, die es ermöglichen, dass die Softwareprogramme 108 und 112 und die OSs 110 und 114 die gleiche Verarbeitungsvorrichtung und andere Hardwareressourcen der Verarbeitungsvorrichtung 102 nutzen, indem sie Hardwareressourcen den Softwareprogrammen 108 und 112 und den OSs 110 und 114 zuweisen.
Zum Verbinden der VMs 104 und 106 mit Ressourcen der Rechenvorrichtung 102 werden Zustands- und Steuerinformationen modifiziert und anderweitig über einen Satz von Feldern innerhalb einer virtuelle Maschine Steuerstruktur (VMCS) 122 verfolgt. Die Ressourcen der Verarbeitungsvorrichtung 102 können Verarbeitungshardware 118, Register, einen Speicher 120, Eingangs/Ausgangs („I/O“) Ressourcen usw. enthalten. Die VMCS 122 kann von der Verarbeitungsvorrichtung 102 dazu verwendet werden, die Steuerung von und den Zugriff auf Ressourcen der Verarbeitungsvorrichtung 102 zwischen dem VMM 116 und den VMs 104 und 106 zu übertragen.
In einer Ausführungsform kann VMM 116 Gast-Software 108-114 durchlaufen, indem er ein Steuerfeld oder -Bit in der VMCS 122 festlegt. Das Steuerfeld oder -Bit kann eine Monitor Trap Flag (MTF) sein. Nachdem das MTF-Bit in der VMCS 122 gesetzt wurde, kann der VMM 116 eine Übertragung des Zugriffs auf oder der Steuerung der Ressourcen der Verarbeitungsvorrichtung 102 auf die Gast-Software 108-114 anfordern. Der VMM 116 kann durch Ausgeben einer Anweisung Zugriff auf oder Steuerung der Ressourcen 102 anfordern.
2 veranschaulicht Virtualisierungsanweisungen für einen VMM 116 (in 1 veranschaulicht) zum Betrieb in einer virtuellen Maschinenumgebung 100 gemäß einer Ausführungsform. Die Virtualisierungsanweisung der virtuellen Maschinenumgebung 100 liest oder schreibt Daten in eine Steuerstruktur, die von dem VMM 116 verwendet wird, um Zustände der VMs 104 und 106 zu erhalten. Die Zustände der VMs 104 und 106 können Übergänge zwischen einer Root-Modus-Operation einer Verarbeitungsvorrichtung unterstützen, in der der VMM 116 ausführt, und einen Nicht-Root-Modus der Verarbeitungsvorrichtung, in dem VMs 104 und 106 ausführen.
Es können VMX-Anweisungen verwendet werden, um Gast-Software-Routine/n zu durchlaufen. Die VMX-Anweisungen können eine VMX-On Anweisung (VMXON) 202 enthalten, die VMX-Operationen für den VMM 116 ermöglichen. Die VMXON 202 veranlasst zum Beispiel, dass die Verarbeitungsvorrichtung in VMX-Root-Operation geht und einen Speicher verwendet, auf den durch den Operand Bezug genommen wird, um VMX-Operationen zu unterstützen. Die VMX-Anweisungen können eine VMX-Off Anweisung (VMXOFF) 204 enthalten, die VMX-Operationen für den VMM 116 deaktiviert. Die VMXOFF 204 veranlasst beispielsweise die Verarbeitungsvorrichtung abzuschalten und die virtuelle Maschinenumgebung 100 zu verlassen.
Die VMX-Anweisungen können ein VM-Eintrittsereignis (VMENTRY) 206 enthalten, das eine VM 104 oder 106 startet, von der VMCS 116 verwaltet wird (in 1 veranschaulicht) und die Steuerung von Ressourcen der Verarbeitungsvorrichtung auf die VM 104 oder 106 überträgt. In einem Beispiel kann VMENTRY 206 ein VM-Startereignis (VMLAUNCH) zum Starten einer virtuellen Maschine, die von der VMCS 116 verwaltet wird, sein. In einem anderen Beispiel kann die VMENTRY 206 ein VM-Wiederaufnahmeereignis (VMRESUME) zum Wiederaufnehmen einer VM, die von der VMCS 116 verwaltet wird, sein. Zum Beispiel tritt Software einer Verarbeitungsvorrichtung in eine VMX-Operation durch Ausführen einer VMXON ein. Der VMM 116 kann unter Verwendung von VM-Einträgen Ressourcen- oder Prozessorsteuerung auf VMs 104 oder 106 übertragen. Die VMLAUNCH kann zum Beispiel ausgeführt werden, um eine Gastanwendung der VM 104 zum ersten Mal auszuführen. Die VMRESUME kann verwendet werden, um die gleiche Funktion nach dem anfänglichen Start durchzuführen.
Die VMX-Anweisungen können ein VMEXIT-Ereignis (VMEXIT) 208 enthalten, das die Steuerung von Ressourcen der Verarbeitungsvorrichtung von der VM 104 oder 106 auf den VMM 116 überträgt. Der VMEXIT 208 kann ein beliebiges Ereignis sein, das die Verarbeitungsvorrichtung veranlasst, die Ausführung der VM 104 oder 106 zu stoppen und die Steuerung an die VMM 116 zurückzugeben. Die Ereignisse können Fehler, Ausnahmen, Interrupts, Speicherzugriffe, Steuerregisterzugriffe, spezielle Virtualisierungsanweisungen usw. umfassen. Die VMX-Anweisungen können zum Beispiel für ein Versagen anfällig sein, wenn ein Ereignis, wie etwa eine Ausnahme, während der Ausführung der Gast-Software eintritt. Wenn ein Versagen eintritt, kann die VMEXIT 208 durch die Verarbeitungsvorrichtung ausgegeben werden, um die Steuerung der Ressourcen der Verarbeitungsvorrichtung von der VM 104 oder 106 an den VMM 116 zurückzugeben. In einem anderen Beispiel kann, bei erfolgreicher Ausführung aller Anweisungen für eine Routine innerhalb einer Anwendung 108 oder 112 (in 1 veranschaulicht) der VM 104 oder 106, ein VMEXIT-Ereignis eintreten und die Steuerung der Ressourcen der Verarbeitungsvorrichtung wird von der VM 104 oder 106 an den VMM 116 zurückgegeben. In einem Beispiel kann das VMEXIT-Ereignis auftreten, wenn der VMM 116 von einem VM-Handler der Verarbeitungsvorrichtung eine Anforderung empfängt.
In einer Ausführungsform kann eine „natürliche“ VMEXIT ein Ereignis sein, das einen VMEXIT 208 verursacht, der kein expliziter VMEXIT 208 von Software ist, die auf der VM 104 oder 106 läuft. Der natürliche VMEXIT ist zum Beispiel ein VMEXIT 208, der nicht von einer Anweisung veranlasst wird, die speziell für das Veranlassen eines Exits der VM 104 oder 106 vorgesehen ist. In einem Beispiel überträgt VMEXIT 208 die Steuerung auf einen Eintrittspunkt, der von dem VMM 116 spezifiziert wird. Die VMEXIT 208 kann eine VMX-Übergangsanweisung für einen Übergang von einem Nicht-Root-Modus in einen Root-Modus sein. Die VMX-Anweisungen können auch enthalten: eine VMPTRLD-Anweisung; eine VMPTRST-Anweisung; eine VMCLEAR-Anweisung; eine VMREAD-Anweisung; eine VMWRITE-Anweisung; und eine VMCALL-Anweisung.
3 zeigt ein System für verschachtelte Virtualisierungstechnologie (VT) System 300 gemäß einer Ausführungsform. Die verschachtelte VT-Architektur 300 kann enthalten: einen Level 2 (L2) Gast 302, eine VMCS 304, einen Level 1 (L1) VMM 306, eine VMCS 308, eine VMCS 310, einen Level 0 (L0) VMM 312 und Hardware 314. In einem Beispiel kann die Hardware 314 Hardware einer Verarbeitungsvorrichtung 102 sein, wie etwa ein Prozessor, Direktzugriffsspeicher (RAM) usw. In einem anderen Beispiel kann die Hardware 314 Hardware sein, die mit der Verarbeitungsvorrichtung 102 verbunden ist (in 1 veranschaulicht).
Virtualisierung für eine virtuelle Maschinenumgebung 100 (in 1 veranschaulicht) kann zwei Modi enthalten, die unter Virtualisierung ausgeführt werden: einen Root-Modus 318 und einen Nicht-Root-Modus 316. Der L0 VMM 312 ist ein VMM, der in dem Root-Modus 318 ausgeführt wird. Der L1 VMM 306 ist ein VMM, der auf dem L0 VMM 312 in dem Nicht-Root-Modus 316 ausgeführt wird. In einer Ausführungsform läuft der L1 VMM 306 in dem Nicht-Root-Modus 316 als Virtualisierungssteuerungssoftware. Nicht-Root-Operationen können von dem L1 VMM 306 gesteuert werden. Operationen in dem L2 Gast 302 können zum Beispiel von dem L1 VMM 306 gesteuert werden. Nicht-Root-Operationen können VMENTRY-Ereignisse und VMEXIT-Ereignisse enthalten.
In einer anderen Ausführungsform wird der L1 VMM 306 als ein Gast von L0 VMM 312 ausgeführt.
Der L2 Gast 302 ist Gast-Software, einschließlich Anwendungen 108 und 112 und OSs 110 und 114 (in 1 veranschaulicht), die auf dem L1 VMM 306 ausgeführt wird. Die Gast-Software kann zum Beispiel ein OS, wie etwa Window®, Linux® oder Unix® sein. Die VMCS 308 wird von dem L0 VMM 312 erzeugt und verwendet, um L1 VMM 306 oder den L2 Gast 302 auszuführen.
Die VMCS 304 wird von L1 VMM 306 erzeugt und verwendet, um den L2 Gast 302 auszuführen. In einem anderen Beispiel wird die VMCS 304 von dem L1 VMM 306 als Speicher verwendet. In diesem Beispiel wird die VMCS 304 möglicherweise nicht von einer VMPTRLD-Anweisung geladen. VMCS 310 ist ein VMCS, der von L0 VMM 312 zusammengeführt wurde, um den L2 Gast 302 auszuführen. Zu der VMCS 310 können von der L0 VMM 312 die Daten von der VMCS 308 und der VMCS 304 in die VMCS 310 zusammengeführt werden. Die VMCS 310 kann den L2 Gast 302 unter Verwendung der VMCS 310 starten. In einer anderen Ausführungsform kann die VMCS 310 den L1 VMM 306 starten und der L1 VMM 306 kann den L2 Gast 302 starten. Wenn der L1 VMM 306 den L2 Gast 302 starten soll, kann der L1 VMM 306 eine VMRESUME abrufen. In dieser Ausführungsform kann L0 VMM 312 die VMRESUME abfangen. Wenn der L0 VMM 312 die VMRESUME abfängt, kann L0 VMM 312 Daten an der VMCS 310 mit Daten an der VMCS 304 und der VMCS 308 aktualisieren und dann den L2 Gast 302 für den L1 VMM 306 starten.
In einer anderen Ausführungsform veranlasst, wenn ein VMEXIT-Ereignis an dem L2 auftritt, das VMEXIT-Ereignis, dass eine Verarbeitungsvorrichtung von einem Nicht-Root-Modus zum Ausführen von Gast-Software in den Root-Modus schaltet. Das Steuern von Hardwareressourcen der Rechenvorrichtung kann direkt von dem L0 VMM 312 gehandhabt werden. In einem Beispiel kann das VMEXIT-Ereignis für das Schalten der Hardwareressourcensteuerung von dem L2 Gast 302 zu dem L0 VMM umfassen: Schalten der aktuellen VMCS der verschachtelten VT-Architektur 300 von VMCS 310 zu VMCS 308; Kopieren eines Gastfeldes der VMCS 310 zu einem Gastfeld der VMCS 304; Kopieren von VMEXIT-Feldern der VMCS 310 zu VMEXIT-Feldern VMCS 304; Kopieren von Hostfeldern der VMCS 304 zu Gastfeldern der VMCS 308; und Abrufen eines VMRESUME-Ereignisses zum Zurückschalten in den Nicht-Root-Modus. In diesem Beispiel wird, wenn die Gastfelder der VMCS 308 von den Gastfeldern der VMCS 304 kopiert werden, ein VMEXIT-Handler der L1 VMM 306 ausgeführt als wäre das VMEXIT-Ereignis als vom L2 Gast 302 empfangen aufgetreten.
4A veranschaulicht eine Konfiguration eines VT-Systems 300 (veranschaulicht in 3) gemäß einer Ausführungsform. Die VT-Architektur 300 enthält: einen L2 Gast 402, der in einem Nicht-Root-Modus arbeitet, wie etwa einem Windows® Betriebssystem; einen L1 VMM 404, der in einem Nicht-Root-Modus arbeitet, wie etwa ein VMWare® VMM oder Hypervisor; einen L1 Gast 406, der in einem Nicht-Root-Modus arbeitet, wie etwa einem Windows® Betriebssystem; einen L0 VMM mit verschachtelter Unterstützung, der in einem Root-Modus arbeitet, wie etwa eine Intel® Kernel-Schutztechnologie (IKGT); und Hardware einer Verarbeitungsvorrichtung, wie etwa einen Prozessor, Direktzugriffsspeicher (RAM) usw.
4B veranschaulicht eine Tabelle des VMEXIT-Ereignisses, das von der VT-Architektur 300 (in 4A veranschaulicht) für unterschiedliche Daten in einer verschachtelten VT-Umgebung ausgelöst wird, gemäß einer Ausführungsform. Die Tabelle 420 enthält: eine Spalte VMEXIT-Grund 412, die Ursachen für das Ausgeben von VMEXITs angibt; eine Spalte VMEXIT L1 oder L2 414, die angibt, ob die VMEXITs von dem L2 Gast 402, dem L1 Gast 406 oder dem L1 VMM 404 (in 4A veranschaulicht) ausgegeben werden; eine Spalte Zählung pro Sekunde (#/s) 416, die eine Anzahl von VMEXITs angibt, die pro Sekunde für den jeweiligen VMEXIT-Grund des L2 Gast 402 oder dem L1 Gast 406 auftreten; und eine Spalte Prozentsatz 418, die einen Prozentsatz der VMEXIT-Ereignisse für die unterschiedlichen VMEXIT-Ereignisse aus einem Gesamtprozentsatz der VMEXIT-Gründe für den L2 Gast 402 und den L1 Gast 406 angibt. In einem Beispiel ist ein Gesamtprozentsatz der VMEXIT-Ereignisse, die von dem L2 Gast 402 gesendet werden, 36,74 % und der Gesamtprozentsatz der VMEXIT-Ereignisse, die vom L1 Gast 406 gesendet werden, 63,26 %.
5A veranschaulicht einen VMEXIT, der über L0 VMM 512 an L1 VMM 506 weitergeleitet und in einem VT-System 500 ausgeführt wird, gemäß einer Ausführungsform. In einem Beispiel kann, wenn ein VMEXIT-Ereignis 520 für L2 Gast 502 auftritt, L0 VMM 512 aufgerufen werden, um die Ressourcen, die für den L2 Gast 502 zugewiesen sind, zu steuern. In diesem Beispiel kann, wenn L0 VMM 512 aufgerufen wird, der L0 VMM 512 das Steuern der Ressourcen an L1 VMM 506 unter Verwendung einer VMENTRY 522 zum Simulieren eines VMEXIT-Ereignisses an L1 VMM 506 weiterleiten. Wenn L1 VMM 506 das Bearbeiten dieser VMEXIT abgeschlossen hat, kann der L1 VMM 506 eine VMEXIT 524 an L0 VMM 512 senden. L0 VMM 502 kann das Steuern der Ressourcen an L2 Gast 502 unter Verwendung der VMRESUME 526 weiterleiten. Mit der VMRESUME an L2 Gast 502 kann das Steuern von Hardware 514 gesteuert werden, die Ausführung fortzusetzen.
5B veranschaulicht einen VMEXIT, der direkt von L1 VMM 506 in dem VT-System 500 ausgelöst wird, gemäß einer Ausführungsform. In einem Beispiel kann, wenn ein VMEXIT-Ereignis 520 für L2 Gast 502 auftritt, L1 VMM 506 aufgerufen werden, um die Ressourcen, die für den L2 Gast 502 zugewiesen sind, zu steuern. In diesem Beispiel kann, wenn L0 VMM 512 aufgerufen wird, der L0 VMM 512 das Steuern der Ressourcen direkt zu L1 VMM 506 unter Verwendung einer VMEXIT 528 schalten. Wenn L1 VMM 506 das Bearbeiten dieser VMEXIT abgeschlossen hat, kann L1 VMM 506 eine VMRESUME 530 an L0 VMM 512 senden und dann kann L0 VMM 502 das Steuern der Ressourcen an L2 Gast 502 unter Verwendung der VMRESUME 526 weiterleiten. Wenn die VMRESUME 526 an L2 Gast 502 gesendet wird, kann das Steuern der Hardware 514 von L2 Gast 502 gesteuert werden, um die Ausführung einer Anwendung oder eines OS des L2 Gastes 502 fortzusetzen. Ein Vorteil dessen, dass die VMEXIT direkt in dem VT-System 500 ausgeführt wird, ist das Reduzieren einer VMX-Übergangszeit für VMEXITs in dem VT-System 500 durch Reduzieren der Anzahl von VMEXITs und VMRESUMEs, die für das Übertragen des Steuerns der Ressourcen verwendet werden.
6 zeigt ein Flussdiagramm eines Verfahrens 600 zum Übertragen von Ressourcensteuerung von dem L1 VMM 306 auf den L2 Gast 302 (in 3 veranschaulicht) gemäß einer Ausführungsform. Verfahren 600 kann von einem Computersystem oder einer Softwarebibliothek (wie etwa einer Runtime-Bibliothek) von einem Prozessor des Rechensystems ausgeführt werden. Verfahren 600 und/oder dessen Funktionen, Routinen, Unterroutinen oder Operationen können von einem oder mehreren physischen Prozessoren des Computersystems, das das Verfahren ausführt, durchgeführt werden. Zwei oder mehr Funktionen, Routinen, Unterroutinen oder Operationen des Verfahrens 600 können parallel ausgeführt werden oder in einer Reihenfolge, die sich von der vorstehend beschriebenen Reihenfolge unterscheidet. In bestimmten Implementierungen kann Verfahren 600 von einem einzelnen Verarbeitungs-Thread ausgeführt werden. Alternativ kann Verfahren 600 von zwei oder mehr Verarbeitungs-Threads ausgeführt werden, wobei jeder Thread eine oder mehrere individuelle Funktion/en, Routine/n, Unterroutine/n oder Operation/en des Verfahrens ausführt. In einem veranschaulichenden Beispiel können die Verarbeitungs-Threads, die Verfahren 600 implementieren, synchronisiert sein (z. B. unter Verwendung von Semaphoren, kritischen Abschnitten und/oder anderen Thread-Synchronisierungsmechanismen). Alternativ können die Verarbeitungs-Threads, die Verfahren 600 implementieren, asynchron relativ zueinander ausgeführt werden.
Unter Bezugnahme auf 6 kann das Verfahren 600 mit einem Prozessor oder einer Software-Bibliothek (wie etwa einer Runtime-Bibliothek), die von dem Prozessor, der ein VMRESUME-Ereignis an dem L1 VMM 306 (in 3 veranschaulicht) beginnen, um ein Steuern von Hardwareressourcen auf den L2 Gast 302 zu übertragen (610). Das Verfahren kann das Vorbereiten durch L0 VMM 312 der VMCS 310 zum Übertragen der Ressourcensteuerung auf den L2 Gast 302 enthalten (620).
In einem Beispiel kann der L0 VMM 312 die VMCS 310 vorbereiten, indem er die Datenfelder der aktuellen VMCS 310 für L2 Gast 302, wie in den weiteren Absätzen zu 7 ausführlicher diskutiert, festlegt.
Das Verfahren kann das Festlegen durch L0 VMM 312 von VMEXIT-Feld, wenn die VMCS02 vorbereitet wurde, umfassen (630). Das VMEXIT-Feld kann zum Beispiel festgelegt werden mit: einem Steuer-VMCS-Verbindungszeiger mit der Adresse von VMCS 308; einem Zustands-VMCS-Verbindungszeiger mit der Adresse von VMCS 304; und einem Grundbitmap. In einem Beispiel kann das Grundbitmap eine Speicheradresse aufweisen, die auf 128 Bits weist. In einem anderen Beispiel kann der Wert der 128 Bits 0×0FFFFFFF_FFFFFFFD sein, was angibt, dass L0 VMM 312 nur bearbeitet: externe Interrupts oder einen unbekannten Grund. In einem anderen Beispiel kann ein nicht maskierbarer Interrupt (Non-maskable Interrupt; NMI) VMEXIT durch einen VMEXIT-Ausnahmegrund zugestellt werden. In diesem Beispiel kann der VMEXIT-Ausnahmegrund auch Ausnahmen von einem Gast-OS von L2 Gast 302 angeben. In einer Ausführungsform wird, wenn L0 VMM 312 L1 VMM 306 designieren soll, eine Übertragung der Ressourcensteuerung von L2 Gast 302 direkt zu übertragen, ein Grundbit für den NMI VMEXIT Grund auf Eins gesetzt. In einer anderen Ausführungsform wird, wenn der L0 VMM 312 die Übertragung der Ressourcensteuerung von dem L2 Gast 302 übertragen soll, der NMI VMEXIT Grund-Wert auf Null gesetzt. Das VMEXIT-Feld kann auch mit einem VMEXIT-Ausnahmebitmap festgelegt werden, das auf 0xFFFFFFFB festgelegt ist. Das VMEXIT/Feld, das auf 0xFFFFFFFB festgelegt ist, gibt an, dass nur ein NMI VMEXIT von L2 Gast 302 eine Übertragung der Ressourcensteuerung auf L0 VMM auslöst und Ausnahmen eine Übertragung der Ressourcensteuerung auf L1 VMM 306 auslösen. Der VMEXIT-Grund 420 (in 4B veranschaulicht) für NMI ist beispielsweise Null. In diesem Beispiel kann, abgesehen von dem VMEXIT-Grund 420 für NMI, eine Null für den VMEXIT-Grund 420 eine VMEXIT aus einer Ausnahme, wie etwa einem Seitenfehler, sein. Wenn die VMEXIT-Gründe 420 Null sind, wird die VMEXIT von L0 VMM 512 (in 5A veranschaulicht) bearbeitet. Zusätzlich wird, für VMEXIT-Gründe 420, die nicht-Null sind, wenn ein entsprechendes Bit in dem Grundbitmap 714 (in 7 veranschaulicht) festgelegt wird, die VMEXIT von L1 VMM 506 (in 5A veranschaulicht) bearbeitet.
In einer Ausführungsform wird die VMEXIT, wenn die Null-Bit-Position in dem Grundbitmap 714 Null ist, von L0 VMM 512 bearbeitet. In einer anderen Ausführungsform wird, wenn die Null-Bit-Position in dem Grundbitmap 714 Eins ist, das Ausnahmebitmap 716 (in 7 veranschaulicht) geprüft. Wenn die Ausnahme ID NMI an Bitposition 2 der Ausnahmebitmap 716 Zwei ist, wird die VMEXIT von L1 VMM 506 bearbeitet. Wenn die Ausnahme ID NMI an Bitposition 2 der Ausnahmebitmap 716 nicht Zwei ist, wird die VMEXIT von L0 VMM 512 bearbeitet. In diesem Beispiel wird die NMI VMEXIT von L2 Gast 302 von L1 VMM 506 bearbeitet, wenn Bit 0 in Grundbitmap 714 und Bit 2 in Ausnahmebitmap 716 auf Null gesetzt sind.
Das Verfahren kann das Ausführen, durch den L0 VMM 312, einer VMRESUME (640) umfassen. Das Verfahren kann das Prüfen, durch den Prozessor oder die Software-Bibliothek, einer Gültigkeit der VMRESUME-Daten, die der VMRESUME (650) zugeordnet sind, umfassen. In einem Beispiel sind die VMRESUME-Daten gültig, wenn Felder 710, 712 und 714 (in 7 veranschaulicht) nicht 0xFFFFFFFF_FFFFFFFF gleich sind, und ungültig, wenn Felder 710, 712 und 714 0xFFFFFFFF_FFFFFFFF gleich sind. Wenn die VMRESUME-Datenprüfung fehlschlägt, schlägt VMRESUME fehl und das VMRESUME-Ereignis wird nicht ausgelöst und die Ressourcensteuerung verbleibt bei L0 VMM 312 (680). Wenn die VMRESUME-Datenprüfung besteht, kann der Prozessor oder die Software-Bibliothek die Gültigkeit der VMEXIT-Felder prüfen (660). Während des Auslösens des VMRESUME-Ereignisses kann der Prozessor zum Beispiel prüfen, ob der Zustands-VMCS-Verbindungszeiger, der Steuer-VMCS-Verbindungszeiger, das Grundbitmap und das Ausnahmebitmap jeweils gültig oder ungültig sind. In einem Beispiel war, wenn der Zustands-VMCS-Verbindungszeiger, der Steuer-VMCS-Verbindungszeiger, das Grundbitmap und das Ausnahmebitmap jeweils gültig sind, die VMRESUME erfolgreich und die Ressourcensteuerung wird auf L2 Gast 302 übertragen. In einem anderen Beispiel bearbeitet, wenn der Zustands-VMCS-Verbindungszeiger, der Steuer-VMCS-Verbindungszeiger und das Grundbitmap und das Ausnahmebitmap jeweils ungültig sind, L0 VMM 312 die Ausnahmen. Wenn der Zustands-VMCS-Verbindungszeiger, der Steuer-VMCS-Verbindungszeiger 712, das Grundbitmap 714 und/oder das VMEXIT-Ausnahmebitmap 616 gültig ist bzw. sind und mindestens eines davon ungültig ist, schlägt die Integritätsprüfung für die VMRESUME fehl (680). Wenn die VMEXIT-Felder bestehen, kann die Ressourcensteuerung zu dem L2 Gast 302 geschaltet werden (670).
7 veranschaulicht die VMCS 310 vor dem Übertragen der Ressourcensteuerung auf L2 Gast 302 (in 3 veranschaulicht) gemäß einer Ausführungsform. Die VMCS 310 kann Gastfeld/er 702, Hostfeld/der 704, Steuerfeld/er 706 und VMEXIT-Steuerfeld/er enthalten. In einem Beispiel können das oder die Steuerfeld/er ein Exit-Steuerungsfeld und ein Ausnahme-Steuerungsfeld enthalten. Die VMEXIT-Steuerungsfelder können enthalten: einen VMCS-Verbindungszeiger 708, einen Zustands-VMCS-Verbindungszeiger 710, einen Steuerungs-VMCS-Verbindungszeiger 712, ein Grundbitmap 714, ein Ausnahmebitmap 716, VMENTRY-Feld/er 718 und VMEXIT-Feld/er 720. Das bzw. die Gastfeld/er 702 können Daten enthalten, die von Gastfeldern der VMCS 304 kopiert wurden. Das bzw. die Hostfeld/er 704 können Daten enthalten, die von einem oder mehreren Hostfeld/ern der VMCS 308 kopiert wurden.
In einer Ausführungsform können die Steuerfelder 706 Daten enthalten, die von VMCS 308 und VMCS 304 zusammengeführt wurden. In einer anderen Ausführungsform können unterschiedliche VMMs, die in dem Nicht-Root-Modus arbeiten, Datenformate oder einen unterschiedlichen Algorithmus verwenden und der VMM 312 kann die unterschiedlichen VMMs zusammenführen.
Die Steuerfelder 706 können enthalten: VMCS-Verbindungszeiger 708, einen Zustands-VMCS-Verbindungszeiger 710, einen Steuer-VMCS-Verbindungszeiger 712, ein Grundbitmap 714 und ein Ausnahmebitmap 716. Der VMCS-Verbindungszeiger 708 kann eine Adresse zu einer VMCS-Verbindung enthalten. Die Adresse des VMCS-Verbindungszeigers 708 kann zum Beispiel 0xFFFFFFFF_FFFFFFFF sein, was angibt, dass der VMCS-Verbindungszeiger 708 ungültig ist. Der Zustands-VMCS-Verbindungszeiger 710 kann mit VMCS 304 verbunden sein, wenn L0 VMM 312 den L2 Gast 302 für L1 VMM 306 startet. Bei Wiederaufnahme eines L1 VMM 306 Zustands sollte der Zustands-VMCS-Verbindungszeiger 710 auf ungültig eingestellt sein, wie etwa (0xFFFFFFFF_FFFFFFFF). Der Steuer-VMCS-Verbindungszeiger 712 kann mit VMCS 308 verbunden sein, wenn L0 VMM 312 den L2 Gast 302 für L1 VMM 306 startet. Wenn die Ressourcensteuerung auf L1 VMM 306 übertragen wird, sollte dieses Feld auf ungültig festgelegt werden, wie etwa (0xFFFFFFFF_FFFFFFFF). Das Grundbitmap 714 kann auf eine Speicheradresse weisen, wenn die Ressourcensteuerung auf L2 Gast übertragen wird. In einem Beispiel kann der VMEXIT-Grund ein VMEXIT-Grund 412 (in 4B veranschaulicht) sein. In einem Beispiel kann die Speicheradresse 128 Bits sein. In einem anderen Beispiel kann die Größe der Speicheradresse erhöht werden, so dass sie die 128-Bit Feldgröße übersteigt, wenn eine Anzahl von VMEXIT-Gründen 127 übersteigt, wo das Grundbitmap 714 eine Adresse in dem Speicher für den VMEXIT-Grund speichert. In einem anderen Beispiel veranlasst, wenn das nth Bit des Grundbitmap 714 in dem Speicher festgelegt wird, der VMEXIT-Grund n (in 4B veranschaulicht) eine Übertragung der Ressourcen auf L1 VMM 306. Bei Wiederaufnahme von L1 VMM 306 wird das Grundbitmap 714 auf ungültig gesetzt, wie etwa 0xFFFFFFFF_FFFFFFFF.
Das Ausnahmebitmap 716 ist ein Bitfeld, das ein Bit für jede Ausnahme enthält, die ein VMEXIT verursachen kann. In einem Beispiel ist das Ausnahmebitmap 716 ein 32-Bit-Feld. In einem anderen Beispiel wird das VMEXIT-Ausnahmebitmap 716 nicht verwendet, wenn Bit 0 des Grundbitmap 714 frei ist. Wenn Bit 0 des Grundbitmap 714 zum Beispiel gesetzt ist und das nth Bit des Grundbitmaps 714 gesetzt ist, verursacht die Ausnahme mit Vektor n keine Übertragung von Ressourcen von L2 Gast 302 auf L0 VMM 312. In diesem Beispiel tritt eine Übertragung von Ressourcen von L2 Gast 302 auf L1 VMM 306 ein. In einem anderen Beispiel wird ein VMEXIT, wenn sowohl Bit 0 in dem Grundbitmap als auch Bit 2 in dem Ausnahmebitmap auf Eins festgelegt sind, von einem NMI ausgelöst und es tritt eine Übertragung von Ressourcen von L2 Gast 302 zu L1 VMM 306 ein. In einem anderen Beispiel ist das Grundbitmap 714, bei Wiederaufnahme des L1 VMM 306, auf Null gesetzt, was angibt, dass alle VMEXITs eine Übertragung von Ressourcen von L2 Gast 302 auf Lo VMM 312 veranlassen.
In einer Ausführungsform sind zum Befähigen einer Übertragung von Ressourcen von L2 Gast 302 auf L1 VMM 306 der Zustands-VMCS-Verbindungszeiger 710, der Steuer-VMCS-Verbindungszeiger 712 und das Grundbitmap 714 gültig bevor eine VMLAUNCH oder eine VMRESUME ausgeführt wird. Das bzw. die VMEXIT-Feld/er 720 werden möglicherweise nicht aktualisiert, weil das bzw. die VMEXIT-Feld/er 720 nicht in den VMENTER- oder VMRESUME-Ereignissen verwendet werden. In einem anderen Beispiel wird bzw. werden VMEXIT-Feld/er 720 in dem VMEXIT-Ereignis verwendet.
8 zeigt ein Flussdiagramm eines Verfahrens 800 zum Schalten von Ressourcensteuerung von dem L2 Gast 302 zu dem L1 VMM 306 oder dem L0 VMM 312 (in 3 veranschaulicht) gemäß einer Ausführungsform. Verfahren 800 kann von einem Computersystem oder einer Softwarebibliothek (wie etwa einer Runtime-Bibliothek) von einem Prozessor des Rechensystems ausgeführt werden. Verfahren 800 und/oder dessen Funktionen, Routinen, Unterroutinen oder Operationen können von einem oder mehreren physischen Prozessoren des Computersystems, das das Verfahren ausführt, durchgeführt werden. Zwei oder mehr Funktionen, Routinen, Unterroutinen oder Operationen des Verfahrens 800 können parallel ausgeführt werden oder in einer Reihenfolge, die sich von der vorstehend beschriebenen Reihenfolge unterscheidet. In bestimmten Implementierungen kann Verfahren 800 von einem einzelnen Verarbeitungs-Thread ausgeführt werden. Alternativ kann Verfahren 800 von zwei oder mehr Verarbeitungs-Threads ausgeführt werden, wobei jeder Thread eine oder mehrere individuelle Funktion/en, Routine/n, Unterroutine/n oder Operation/en des Verfahrens ausführt. In einem veranschaulichenden Beispiel können die Verarbeitungs-Threads, die Verfahren 800 implementieren, synchronisiert sein (z. B. unter Verwendung von Semaphoren, kritischen Abschnitten und/oder anderen Thread-Synchronisierungsmechanismen). Alternativ können die Verarbeitungs-Threads, die Verfahren 800 implementieren, asynchron relativ zueinander ausgeführt werden.
Unter Bezugnahme auf 8 kann das Verfahren 800 mit einem Prozessor oder einer Software-Bibliothek (wie etwa einer Runtime-Bibliothek), die von dem Prozessor ausgeführt wird, beginnen, der bzw. die feststellt, ob eine VMEXIT-Bedingung zum Übertragen von Ressourcensteuerung von L2 Gast 302 auf L1 VMM 306 oder L0 VMM 312 eingetreten ist (810). Das Verfahren kann das Feststellen beinhalten, ob der Steuer-VMCS-Verbindungszeiger einer derzeitigen VMCS gültig ist (820). In einem Beispiel ist der Steuer-VMCS-Verbindungszeiger ungültig, wenn er auf 0xFFFFFFFF_FFFFFFFF gesetzt ist, und ansonsten gültig. Das Verfahren kann das Übertragen von Ressourcensteuerung von L2 Gast 302 auf L0 VMM 312 beinhalten, wenn der Steuer-VMCS-Verbindungszeiger nicht gültig ist (870). Das Verfahren kann, wenn der Steuer-VMCS-Verbindungszeiger gültig ist, das Feststellen beinhalten, ob ein Grundbit, das einem derzeitigen VMEXIT-Grund für einen VMEXIT entspricht, festgelegt ist (830). Wenn zum Beispiel ein derzeitiger VMEXIT-Grund ein n-ter VMEXIT-Grund in der Tabelle von VMEXIT-Gründen 420 (in 4B veranschaulicht) ist, dann prüft die Verarbeitungsvorrichtung ein Bit in der n-ten Position im Speicher, auf das durch einen Grundbitmapzeiger Bezug genommen wird. Das Verfahren kann das Übertragen von Ressourcensteuerung von L2 Gast 302 auf L0 VMM 312 beinhalten, wenn das entsprechende Grund-Bit nicht gesetzt ist (870). Das Verfahren kann das Feststellen beinhalten, wenn der entsprechende VMEXIT-Grundwert festgelegt ist, ob der VMEXIT-Grundwert auf Null gesetzt ist (840). Wenn zum Beispiel der VMEXIT-Grundwert für die n-te Position Null ist, dann wird ein VMEXIT-Ereignis von einer der Ausnahmen in einer Gast-VM ausgelöst.
Das Verfahren kann das Übertragen von Ressourcensteuerung von L2 Gast 302 zu L1 VMM 306, wenn das Grundbit nicht auf 0 gesetzt ist, beinhalten (860). Das Verfahren kann ferner das Abrufen, wenn das Grundbit auf Null gesetzt ist, einer Ausnahme-ID für den n-ten VMEXIT-Grund aus VMEXIT-Informationen einer derzeitigen VMCS beinhalten (845). Das Verfahren kann das Feststellen beinhalten, ob ein Ausnahmebit, das dem Grundbit für die Ausnahme-ID entspricht, festgelegt ist (850). In einem Beispiel wird die VMEXIT, wenn ein Grund oder Auslöser einer VMEXIT eine Ausnahme oder NMI (ein grundsätzlicher Exitgrund ist beispielsweise 0) ist, von Grund Null ausgelöst wird. In diesem Beispiel ist die VMEXIT ein Ausnahmevektor (z. B. eine Zwei für den NMI) und wird mit dem Ausnahmebitmap 716 geprüft.
Das Verfahren kann das Übertragen von Ressourcensteuerung von L2 Gast 302 auf L0 VMM 312 beinhalten, wenn das entsprechende Ausnahme-Bit nicht gesetzt ist (870). Das Verfahren kann das Übertragen von Ressourcensteuerung von L2 Gast 302 auf L1 VMM 306 beinhalten, wenn das entsprechende Ausnahmebit gesetzt ist (860).
9 veranschaulicht Schalten einer derzeitigen VMCS zu der VMCS 304 (in 3 veranschaulicht), wenn das Übertragen der Ressourcensteuerung von dem L2 Gast 302 auf den L1 VMM 306 eingetreten ist, gemäß einer Ausführungsform. Die derzeitige VMCS 900 kann Gastfeld/er 902, Hostfeld/er 904, Steuerfeld/er 906, einen VMCS-Verbindungszeiger 908, einen Zustands-VMCS-Verbindungszeiger 910, einen Steuer-VMCS-Verbindungszeiger 912, ein Grundbitmap 914, ein Ausnahmebitmap 916, VMENTRY-Feld/er 918 und VMEXIT-Feld/er 920 enthalten.
In einer Ausführungsform können die Datenfelder der derzeitigen VMCS 900, wenn die Ressourcensteuerung von L2 Gast 302 auf L1 VMM 306 übertragen wird, geändert werden. In einem Beispiel werden Prozessorzustände in Gastfeld/ern 902 gespeichert, auf die durch den Zustands-VMCS-Verbindungs-Zeiger 908 (in 3 veranschaulicht) gewiesen wird. In einem Beispiel kann der Zustands-VMCS-Verbindungszeiger 908 auf VMCS 304 weisen. Wenn die Prozessorzustände von dem L2 Gast 302 in die Gastfelder 902 gespeichert werden, kann der L1 VMM 306 die Gastfelder dann wieder direkt aus der VMCS 304 abrufen. In einem anderen Beispiel können Prozessorzustände aus Prozessorzuständen der Verarbeitungsvorrichtung zu Hostfeldern 904 von Hostfeldern, auf die der Zustands-VMCS-Verbindungszeiger weist, geladen werden. In einem Beispiel ist der Prozessorzustand ein Kontext für einen Prozessor der Verarbeitungsvorrichtung, der ausführen ist. Der Prozessorzustand kann in einem Gastfeld gespeichert werden, um die Feldwerte von einem Host verfügbar zu machen. Wenn die Prozessorzustände aus Hostfeldern geladen werden, kann der Prozessor im Host-Modus laufen.
Die in Hostfelder 904 geladenen Prozessorzustände können verwendet werden, um einen Arbeitskontext für L1 VMM 306 einzurichten und um einen Handlercode für den L1 VMM 306, der nach der VMEXIT läuft, einzurichten. In einem Beispiel ist der Arbeitskontext eine Registerserie (wie etwa eax, ebx, ecx, edx, esp, ebp, CS, DS, ES, FS, SS oder modelspezifische Register) und Speicherkontexte, auf die durch diese Register gewiesen wird (wie etwa Interrupt-Deskriptortabellen auf die durch Interrupt-Deskriptortabellenregister hingewiesen wird oder globale Deskriptortabellen, auf die durch globale Deskriptortabellenregister hingewiesen wird).
In einer Ausführungsform kann/können das bzw. die Steuerfeld/der 906 Daten enthalten, die aus Steuerfeldern einer VMCS, auf die von dem Steuer-VMCS-Verbindungszeiger 908 gewiesen wird, kopiert wurden. Das bzw. die Steuerfeld/er 906 können für die derzeitige VMCS 900 durch Kopieren der Daten in den Steuerfeldern der VMCS, auf die von dem Steuer-VMCS-Verbindungszeiger 912 gewiesen wird, aktualisiert werden. In einem anderen Beispiel kann, wenn Ressourcen von dem L1 Gast 302 gesteuert werden, eine Bedingung zum Erzeugen einer VMEXIT von VMCS 308 konfiguriert werden. In einem anderen Beispiel können das bzw. die VMENTRY-Feld/er 908 mit den Prozessorzuständen durch Freisetzen eines höchsten Bit des VMENTRY-Interruptfeldes aktualisiert werden. Das/die VMEXIT-Feld/er können mit den Prozessorzuständen auf Basis unterschiedlicher VMEXIT-Gründe aktualisiert werden.
In einer anderen Ausführungsform können der VMCS-Verbindungszeiger 908 und der Steuer-VMCS-Verbindungszeiger 912 von dem Prozessor aktualisiert werden. In einem Beispiel wird der VMCS-Verbindungszeiger 908 der derzeitigen VMCS 900 mit dem Wert in dem Zustand des VMCS-Verbindungszeigers 910 festgelegt, wenn die Ressourcensteuerung auf L1 VMM übertragen wird. Wenn der VMCS-Verbindungszeiger 908 und der Steuer-VMCS-Verbindungszeiger 912 aktualisiert werden, kann der L1 VMM 306 den VMCS-Verbindungszeiger 908 und den Steuer-VMCS-Verbindungszeiger 912 abrufen.
In einer anderen Ausführungsform können der Zustands-VMCS-Verbindungszeiger 910, der Steuer-VMCS-Verbindungszeiger 912, das Grundbitmap 914 und das Ausnahmebitmap 916 durch Festlegen jedes dieser Datenfelder auf einen festen Wert festgelegt werden, wobei der feste Werte vordefiniert sein kann. Der Zustands-VMCS-Verbindungszeiger 910, der Steuer-VMCS-Verbindungszeiger 912 und das Grundbitmap 914 können zum Beispiel auf 0xFFFFFFFF_FFFFFFFF festgelegt werden und das Ausnahmebitmap kann auf Null festgelegt werden. Der Zustands-VMCS-Verbindungszeiger 910, der Steuer-VMCS-Verbindungszeiger 912, das Grundbitmap 914 und das Ausnahmebitmap 916 können deaktiviert werden, um ein Verschachteln zu vermeiden. In einer anderen Ausführungsform werden die VMENTRY-Felder 918 durch Kopieren von Daten, auf die durch Zustands-VMCS-Verbindungszeiger 910 gewiesen wird, aktualisiert werden. In einer anderen Ausführungsform können die VMENTRY-Felder 918 durch Freisetzen eines gültigen Bit in einem VMENTRY-Interruptinformationsfeld aktualisiert werden. Das Aktualisieren des VMENTRY-Felds 918 kann eine Veränderung in den VMENTRY-Feldern 918 während eines Übertragens der Ressourcensteuerung simulieren. Die VMCS 304 ist die VMCS 900 nachdem die VMCS 900 nach dem Übertragen der Ressourcensteuerung aktualisiert wurde.
In einem Beispiel kann der L1 VMM 306, nach dem Übertragen der Ressourcensteuerung, in einem Nicht-Root-Modus ausgeführt werden. Der L1 VMM 306 kann VMCS-Felder direkt lesen und schreiben. In einem anderen Beispiel kann, wenn ein Verstoß aufgetreten ist, ein Übertragen der Ressourcensteuerung von L0 VMM 312 auf L2 Gast 302 erfolgen. In einer Ausführungsform kann der Verstoß ein VMRESUME-Ereignis auslösen.
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, wie etwa Beispiele spezifischer Prozessortypen und Systemkonfigurationen, spezifische Hardwarestrukturen, spezifische Architektur- und Mikroarchitektur-Details, spezifische Registerkonfigurationen, spezifische Anweisungsarten, spezifische Systemkomponenten, spezifische Maße/Höhen, spezifische Prozessor-Pipeline-Phasen und Operationen usw., um ein genaues Verständnis der vorliegenden Offenbarung zu ermöglichen. Es wird dem Fachmann jedoch offensichtlich sein, dass diese spezifischen Einzelheiten nicht zum Ausführen der vorliegenden Offenbarung eingesetzt werden müssen. In anderen Fällen wurden weithin bekannte Komponenten oder Verfahren, wie spezifische und alternative Prozessorarchitekturen, spezifische Logikschaltungen/- code für beschriebene Algorithmen, spezifischer Firmwarecode, spezifische Verbindungsoperationen, spezifische Logikkonfigurationen, spezifische Fertigungstechniken und -materialien, spezifische Compilerimplementierungen, spezifische Ausdrücke von Algorithmen in Code, spezifische Abschalt- und Gatingtechnologien/-logik und andere spezifische operative Details des Computersystems nicht ausführlich beschrieben, um eine unnötige Verundeutlichung der vorliegenden Offenbarung zu vermeiden.
Obwohl die folgenden beispielhaften Implementierungen unter Bezugnahme auf Energieeinsparung und Energieeffizienz in spezifischen integrierten Schaltungen, wie etwa in Rechenplattformen oder Mikroprozessoren, beschrieben sein können, gelten für andere beispielhafte Implementierungen andere Arten von integrierten Schaltungen und Logikvorrichtungen. Ähnliche Techniken und Lehren hierin beschriebener beispielhafter Implementierungen können auf andere Arten von Schaltungen oder Halbleitervorrichtungen, die ebenfalls von einer besseren Energieeffizienz und Energieeinsparung profitieren können, angewendet werden. Die offenbarten beispielhaften Implementierungen sind zum Beispiel nicht auf Desktop-Computersysteme oder Ultrabooks™ beschränkt und können auch in anderen Vorrichtungen, wie etwa in Handgeräten, Tablets, anderen dünnen Notebooks, Systemen-auf-einem-Chip (SOC) Geräten und eingebetteten Anwendungen verwendet werden. Manche Beispiele von Handgeräten umfassen Mobiltelefone, Internet-Protocol-Geräte, Digitalkameras, persönliche digitale Assistenten (PDAs) und handgehaltene PCs. Eingebettete Anwendungen umfassen typischerweise einen Mikrocontroller, einen digitalen Signalprozessor (DSP), ein System auf einem Chip, Netzwerkcomputer (NetPC), Set-Top-Boxen, Netzwerkknoten, Wide Area Network (WAN) Vermittlungen oder jedwedes anderes System, das die nachfolgend angeführten Funktionen und Operationen ausführt. Weiterhin sind die hierin beschriebenen Vorrichtungen, Verfahren und Systeme nicht auf physische Rechenvorrichtungen beschränkt, sondern können sich auch auf Softwareoptimierungen zur Energieeinsparung und -effizienz beziehen. Wie sich der Beschreibung unten leicht entnehmen lässt, sind die hierin beschriebenen beispielhaften Implementierungen der Verfahren, Vorrichtungen und Systeme (ungeachtet dessen, ob in Bezug auf Hardware, Firmware, Software oder eine Kombination davon) für eine Zukunft mit „grüner Technologie“ in Balance mit Leistungserwägungen von entscheidender Bedeutung.
Obwohl die folgenden beispielhaften Implementierungen unter Bezugnahme auf einen Prozessor beschrieben werden, sind andere beispielhafte Implementierungen auf andere Arten von integrierten Schaltungen und Logikvorrichtungen anwendbar. Ähnliche Techniken und Lehren beispielhafter Implementierungen der vorliegenden Offenbarung lassen sich auf andere Arten von Schaltungen oder Halbleitervorrichtungen anwenden, die von einem höheren Pipeline-Durchsatz und verbesserter Leistung profitieren können. Die Lehren der beispielhaften Implementierungen der vorliegenden Offenbarung sind auf jedweden Prozessor oder jedwede Maschine anwendbar, auf dem/der Datenmanipulationen durchgeführt werden, anwendbar. Die vorliegende Offenbarung ist jedoch nicht auf Prozessoren oder Maschinen beschränkt, die 512-Bit, 256-Bit, 128-Bit, 64-Bit, 32-Bit oder 16-Bit Datenoperationen durchführen und kann auf jedweden Prozessor und jedwede Maschine angewendet werden, auf dem/der eine Manipulation oder Verwaltung von Daten durchgeführt wird.
Zusätzlich stellt die folgende Beschreibung Beispiele bereit und die beigefügten Zeichnungen zeigen diverse Beispiele zu Veranschaulichungszwecken. Diese Beispiele dürfen jedoch nicht auf einschränkende Weise ausgelegt werden, da sie lediglich als Beispiele beispielhafter Implementierungen der vorliegenden Offenbarung gedacht sind und nicht zum Bereitstellen einer erschöpfenden Liste aller möglichen Implementierungen der beispielhaften Implementierungen der vorliegenden Erfindung.
Obwohl die nachfolgenden Beispiele Anweisungsbearbeitung und -verteilung im Kontext von Ausführungseinheiten und Logikschaltungen beschreiben, können andere beispielhafte Implementierungen der vorliegenden Offenbarung über Daten oder Anweisungen erreicht werden, die auf einem maschinenlesbaren, greifbaren Medium gespeichert sind, die, wenn sie von einer Maschine durchgeführt werden, die Maschine veranlassen, Funktionen durchzuführen, die mindestens einer beispielhaften Implementierung der vorliegenden Offenbarung entsprechen. In einer beispielhaften Implementierung werden Funktionen, die beispielhaften Implementierungen der vorliegenden Offenbarung zugeordnet sind, in maschinenausführbaren Anweisungen verkörpert. Die Anweisungen können verwendet werden, um einen Allzweck- oder Spezialprozessor, der mit den Anweisungen programmiert ist, zu veranlassen, die Schritte der vorliegenden Offenbarung durchzuführen. Beispielhafte Implementierungen der vorliegenden Erfindung können als ein Computerprogrammprodukt oder Software bereitgestellt werden, was ein maschinen- oder computerlesbares Medium umfassen kann, auf dem Anweisungen gespeichert sind, die verwendet werden können, um einen Computer (oder andere elektronische Geräte) zu programmieren, um eine oder mehrere Operation/en gemäß den beispielhaften Implementierungen der vorliegenden Offenbarung durchzuführen. Alternativ können Schritte der beispielhaften Implementierungen der vorliegenden Offenbarung von spezifischen Hardwarekomponenten durchgeführt werden, die Festfunktionslogik zum Durchführen der Schritte enthalten, oder durch eine beliebige Kombination programmierter Computerkomponenten und von Festfunktionshardwarekomponenten.
Anweisungen, die zum Programmieren von Logik zum Durchführen beispielhafter Implementierungen der vorliegenden Offenbarung verwendet werden, können innerhalb eines Speichers in dem System gespeichert werden, wie etwa DRAM, Cache, Flash-Speicher oder einem anderen Speicher. Des Weiteren können die Anweisungen über ein Netzwerk oder über andere computerlesbare Medien verbreitet werden. Ein maschinenlesbares Medium kann somit jedweden Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) lesbar ist, umfassen, ist aber nicht beschränkt auf Floppy-Disketten, optische Disketten, Compact Disks, Nur-Lese-Speicher (CD-ROMs) und magnetoptische Platten, Nur-Lese-Speicher (ROMs), Direktzugriffsspeicher (RAM), löschbar programmierbare Nur-Lese-Speicher (EPROM), elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROM), magnetische oder optische Karten, Flash-Speicher oder einen greifbaren, maschinenlesbaren Speicher, der für das Übertragen von Informationen über das Internet über elektrische, optische, akustische oder andere Formen sich ausbreitender Signale (z. B. Trägerwellen, Infrarotsignale, digitale Signale usw.). Dementsprechend umfasst das computerlesbare Medium jedwede Art von maschinenlesbarem Medium, das geeignet ist elektronische Anweisungen oder Informationen in einer Form, die von einer Maschine (z. B. einem Computer) lesbar ist, zu speichern oder zu übertragen.
Ein Entwurf kann mehrere Phasen von Erzeugung zu Simulation zu Fabrikation durchlaufen. Daten, die einen Entwurf repräsentieren, können den Entwurf auf mehrere Weisen repräsentieren. Zunächst kann, wie es in Simulationen nützlich ist, die Hardware unter Verwendung einer Hardwarebeschreibungssprache oder einer anderen funktionalen Beschreibungssprache repräsentiert sein. Zusätzlich können ein Schaltungsniveaumodell mit Logik und/oder Transistor-Gates in manchen Phasen des Entwurfsprozesses produziert werden. Des Weiteren erreichen die meisten Entwürfe irgendwann ein Datenniveau, das das physische Platzieren diverser Vorrichtungen in dem Hardwaremodell repräsentiert. In dem Fall, in dem herkömmliche Halbleiterfabrikationstechniken verwendet werden, können die Daten, die das Hardwaremodell repräsentieren, die Daten sein, die das Vorhandensein oder das Fehlen diverser Merkmale auf unterschiedlichen Maskenschichten für Masken, die zum Herstellen der integrierten Schaltung verwendet werden, spezifizieren. In jeder Repräsentation des Entwurfs, können die Daten in jedweder Form eines maschinenlesbaren Mediums gespeichert werden. Ein Speicher oder ein magnetischer oder optischer Speicher, wie etwa eine Diskette, kann das maschinenlesbare Medium zum Speichern von Informationen sein, die über optische oder elektrische Wellen, die moduliert oder anderweitig zum Übertragen solcher Informationen erzeugt wurden, übertragen werden. Wenn eine elektrische Trägerwelle, die den Code oder Entwurf angibt oder trägt, übertragen wird, insoweit, als dass ein Kopieren, Puffern oder eine erneute Übertragung des elektrischen Signals durchgeführt wird, wird eine neue Kopie erstellt. Somit kann ein Kommunikationsanbieter oder ein Netzwerkanbieter einen Artikel, wie etwa Informationen, die in eine Trägerwelle kodiert sind und Techniken der beispielhaften Implementierungen der vorliegenden Offenbarung verkörpern, zumindest vorübergehend auf einem greifbaren, maschinenlesbaren Medium speichern.
In modernen Prozessoren werden eine Reihe unterschiedlicher Ausführungseinheiten verwendet, um eine Vielzahl von Code und Anweisungen zu verarbeiten und auszuführen. Nicht alle Anweisungen werden gleich erzeugt, da manche schneller fertiggestellt sind, während andere eine Reihe von Taktzyklen bis zum Abschluss benötigen. Je schneller der Durchsatz an Anweisungen, desto besser ist die Gesamtleistung des Prozessors. Es wäre somit vorteilhaft, dass so viele Anweisungen wie möglich so schnell wie möglich ausgeführt werden. Es gibt jedoch gewisse Anweisungen, die eine größere Komplexität aufweisen und in Hinblick auf die Ausführungszeit und Prozessorressourcen mehr benötigen. Es gibt zum Beispiel Gleitkommaanweisungen, Lade-/Speicheroperationen, Datenbewegungen usw.
Da mehr Computersysteme in Internet-, Text- und Multimediaanwendungen verwendet werden, wurde im Laufe der Zeit zusätzliche Prozessorunterstützung eingeführt. In einer beispielhaften Implementierung kann ein Anweisungssatz einer oder mehreren Computerarchitekturen zugeordnet werden, einschließlich Datentypen, Anweisungen, Registerarchitekturen, Adressierungsmodi, Speicherarchitektur, Interrupt- und Ausnahmebearbeitung und externe Eingabe und Ausgabe (I/O).
In einer beispielhaften Implementierung kann die Anweisungssatzarchitektur (ISA) von einer oder mehreren Mikroarchitektur/en implementiert werden, die Prozessorlogik und Schaltungen enthält bzw. enthalten, die verwendet werden, um ein oder mehrere Anweisungsset/s zu implementieren. Dementsprechend können Prozessoren mit unterschiedlichen Mikroarchitekturen zumindest einen Teil eines gemeinsamen Anweisungssatzes teilen. Intel® Pentium 4 Prozessoren, Intel® Core™ Prozessoren und Prozessoren von Advanced Micro Devices, Inc. of Sunnyvale CA implementieren zum Beispiel beinahe identische Versionen des x86 Anweisungssatzes (mit einigen Erweiterungen, die mit neueren Versionen hinzugefügt wurden), weisen aber unterschiedliche interne Entwürfe auf. Ebenso können Prozessoren, die von anderen Prozessorentwicklungsfirmen entworfen wurden, wie etwa ARM Holdings, Ltd., MIPS bzw. deren Lizenznehmer oder Übernehmer, zumindest einen Teil eines gemeinsamen Anweisungssatzes teilen, aber unterschiedliche Prozessorentwürfe aufweisen. Die gleiche ISA-Registerarchitektur kann zum Beispiel auf unterschiedliche Weisen in unterschiedlichen Mikroarchitekturen unter Verwendung neuer oder weithin bekannter Techniken, einschließlich dedizierter physischer Register, einem oder mehreren dynamisch zugewiesenen physischen Registern unter Verwendung eines Registerumbenennungsmechanismus (z. B. die Verwendung einer Register Alias Tabelle (RAT)), eines Reorder-Buffers (ROB) und einer Retirement-RegisterDatei implementiert werden. In einer beispielhaften Implementierung können Register ein oder mehrere Register, Registerarchitekturen, Registerdateien oder andere Registersätze enthalten, die durch einen Softwareprogrammierer adressierbar sein können oder nicht.
In einer beispielhaften Implementierung kann eine Anweisung ein oder mehrere Anweisungsformate enthalten. In einer beispielhaften Implementierung kann ein Anweisungsformat diverse Felder angeben (Anzahl von Bits, Position von Bits usw.), um unter anderem die durchzuführende Operation und den oder die Operand/en, mit denen die Operation durchzuführen ist, festzulegen. Manche Anweisungsformate können ferner von Anweisungsvorlagen (oder Unterformaten) definiert sein. Die Anweisungsvorlagen eines gegebenen Anweisungsformats können zum Beispiel definiert sein über unterschiedliche Untersets der Felder des Anweisungsformats zu verfügen und/oder definiert sein, dass ein gegebenes Feld unterschiedlich interpretiert wird. In einer beispielhaften Implementierung wird eine Anweisung unter Verwendung eines Anweisungsformats ausgedrückt (und, sofern definiert, ein einem gegebenen einen der Anweisungsvorlagen dieses Anweisungsformats) und die Operation und die Operanden spezifizieren oder angeben, zu denen die Operation arbeitet.
Wissenschaftliche, finanzielle, autovektorisierte Allzweck-, RMS (Erkennung, Mining und Synthese) und visuelle und Multimediaanwendungen (z. B. 2D/3D-Grafiken, Bildverarbeitung, Videokomprimierung/- dekomprimierung, Stimmerkennungsalgorithmen und Audiomanipulation) können erforderlich machen, dass die gleiche Operation für eine große Anzahl von Datenobjekten ausgeführt wird. In einer beispielhaften Implementierung bezieht sich Single Instruction Multiple Data (SIMD) auf eine Art von Anweisung, die einen Prozessor veranlasst, eine Operation für mehrere Datenelemente durchzuführen. SIMD-Technologie kann in Prozessoren verwendet werden, die die Bits in einem Register logisch in eine Anzahl von Datenelementen fester Größe oder variabler Größe aufteilen, von denen jedes einen separaten Wert repräsentiert. In einer beispielhaften Implementierung können zum Beispiel die Bits in einem 64-Bit-Register als ein Quelloperand organisiert werden, die vier separate 16-Bit-Datenelemente enthalten, von denen jeweils einer einen separaten 16-Bit-Wert repräsentiert. Dieser Typ von Daten lässt sich als „gepackter“ Datentyp oder „Vektor-"Datentyp bezeichnen und Operanden dieses Datentyps werden als gepackte Datenoperanden bzw. Vektoroperanden bezeichnet. In einer beispielhaften Implementierung kann ein gepacktes Datenobjekt oder Vektor eine Sequenz gepackter Datenelemente sein, die innerhalb eines einzelnen Registers gespeichert ist, und ein gepackter Datenoperand oder ein Vektoroperand können ein Quell- oder Zieloperand einer SIMD-Anweisung (oder „gepackte Datenanweisung“ oder eine „Vektoranweisung“) sein. In einer beispielhaften Implementierung spezifiziert eine SIMD-Anweisung eine einzelne Vektoroperation, die an zwei Quellvektoroperanden durchzuführen ist, um einen Zielvektoroperand (auch als ein Resultatvektoroperand bezeichnet) der gleichen oder unterschiedlicher Größe, mit der gleichen oder einer unterschiedlichen Anzahl von Datenelementen und in der gleichen oder einer unterschiedlichen Datenelementreihenfolge zu erzeugen.
SIMD-Technologie, wie etwa die, die von Intel® Core™ Prozessoren eingesetzt wird, mit einem Anweisungssatz einschließlich x86, MMX™, Streaming SIMD Extensions (SSE), SSE2, SSE3, SSE4.1 und SSE4.2 Anweisungen, ARM-Prozessoren, wie etwa die ARM Cortex® Prozessorfamilie mit einem Anweisungssatz, der die Vector Floating Point (VFP) und/oder NEON Anweisungen beinhaltet, und MIPS-Prozessoren, wie etwa die Loongson Prozessorfamilie, die von dem Institute of Computing Technology (ICT) der chinesischen Akademie der Wissenschaften entwickelt wurde, haben eine signifikante Verbesserung der Anwendungsleistung ermöglicht (Core™ und MMX™ sind eingetragene Warenzeichen oder Warenzeichen der Intel Corporation of Santa Clara, Kalifornien).
In einer beispielhaften Implementierung sind Ziel- und Quellregister/-daten generische Begriffe, um die Quelle und das Ziel der entsprechenden Daten oder Operation zu repräsentieren. In manchen Implementierungen können sie über Register, Speicher oder andere Speicherbereiche mit anderen Bezeichnungen oder Funktionen als die dargelegten implementiert werden. In einer beispielhaften Implementierung kann „DEST1“ zum Beispiel ein zeitweises Speicherregister oder ein anderer Speicherbereich sein, während „SRC1“ und „SRC2“ ein erstes und zweites Quellspeicherregister oder anderer Speicherbereich sein können usw. In anderen beispielhaften Implementierungen können zwei oder mehr der SRC- und DEST-Speicherbereiche unterschiedlichen Datenspeicherelementen innerhalb des gleichen Speicherbereichs entsprechen (z. B. einem SIMD-Register).
In einer beispielhaften Implementierung kann eines der Quellregister auch als ein Zielregister dienen, indem es beispielsweise das Resultat einer Operation, die für die ersten und zweiten Quelldaten durchgeführt wurde, in eines der beiden Quellregister, die als ein Zielregister dienen, zurückschreibt.
Unter Bezugnahme auf 10 wird ein Blockdiagramm eines beispielhaften Computersystems veranschaulicht, das mit einem Prozessor gebildet ist, der Ausführungseinheiten zum Ausführen einer Anweisung beinhaltet, wobei ein oder mehrere der Verbindungen ein oder mehrere Merkmale gemäß einer beispielhaften Implementierung der vorliegenden Offenbarung implementiert bzw. implementieren. System 1000 enthält eine Komponente, wie etwa einen Prozessor 1002, zum Einsatz von Ausführungseinheiten, einschließlich von Logik, zum Durchführen von Algorithmen zur Datenverarbeitung gemäß der vorliegenden Offenbarung, wie etwa in der hierin beschriebenen beispielhaften Implementierung. System 1000 ist repräsentativ für Verarbeitungssysteme auf Basis der PENTIUM III™, PENTIUM 4™, Xeon™, Itanium, XScale™ und/oder StrongARM™ Mikroprozessoren, die von Intel Corporation of Santa Clare, Kalifornien, erhältlich sind, obwohl auch andere Systeme (einschließlich PCs mit anderen Mikroprozessoren, Engineering-Workstations, Set-Top-Boxen usw.) verwendet werden können. In einer beispielhaften Implementierung führt das Beispielsystem 1000 eine Version des WINDOWS™ Betriebssystems, das von Microsoft Corporation of Redmond, Washington, erhältlich ist, aus, obwohl auch andere Betriebssysteme (UNIX und Linux zum Beispiel), eingebettete Software und/oder grafische Benutzerschnittstellen verwendet werden können. Beispielhafte Implementierungen der vorliegenden Offenbarung sind somit nicht auf eine konkrete Kombination von Hardwareschaltungsanordnungen und Software beschränkt.
Beispielhafte Implementierungen sind nicht auf Computersysteme beschränkt. Alternative beispielhafte Implementierungen der vorliegenden Offenbarung können in anderen Geräten, wie etwa Handgeräten und eingebetteten Anwendungen, verwendet werden. Manche Beispiele von Handgeräten umfassen Mobiltelefone, Internet-Protocol-Geräte, Digitalkameras, persönliche digitale Assistenten (PDAs) und handgehaltene PCs. Eingebettete Anwendungen können einen Mikrocontroller, einen digitalen Signalprozessor (DSP), System-auf-einem-Chip, Netzwerkcomputer (NetPC), Set-Top-Boxen, Netzwerkknoten, Wide Area Network (WAN) Vermittlungen oder andere Systeme beinhalten, die eine oder mehrere Anweisung/en gemäß mindestens einer beispielhaften Implementierung durchführen können.
In dieser veranschaulichten beispielhaften Implementierung enthält Prozessor 1002 eine oder mehrere Ausführungseinheit/en 1008 zum Implementieren eines Algorithmus, der mindestens eine Anweisung auszuführen hat. Eine beispielhafte Implementierung lässt sich im Kontext eines Desktop mit Einzelprozessor oder Serversystems beschreiben, aber alternative beispielhafte Implementierungen können in einem Multiprozessorsystem enthalten sein. System 1000 ist ein Beispiel für eine „Hub“-Systemarchitektur. Das Computersystem 1000 enthält einen Prozessor 1002 zum Verarbeiten von Datensignalen. Der Prozessor 1002 enthält, als ein veranschaulichendes Beispiel, einen Complex Instruction Set Computer (CISC) Mikroprozessor, einen Reduced Instruction Set (RISC) Mikroprozessor, einen Very Long Instruction Word (VLIW) Mikroprozessor, einen Prozessor, der eine Kombination aus Anweisungssätzen implementiert, oder eine andere Prozessorvorrichtung, wie etwa einen digitalen Signalprozessor zum Beispiel. Der Prozessor 1002 ist mit einem Prozessorbus 1010 verbunden, der Datensignale zwischen dem Prozessor 1002 und anderen Komponenten in dem System 1000 überträgt. Die Elemente des Systems 1000 (z. B. Grafikbeschleuniger 1012, Speichersteuerknoten 1016, Speicher 1020, I/O-Steuerknoten 1024, drahtloser Sendeempfänger 1026, Flash BIOS 1028, Netzwerksteuereinrichtung 1034, Audiosteuereinrichtung 1036, serieller Erweiterungsport 1038, I/O Steuereinrichtung 1040 usw.) führen ihre konventionellen Funktionen durch, die dem Fachmann wohlbekannt sind.
In einer beispielhaften Implementierung enthält der Prozessor 1002 einen internen Level 1 (L1) Cachespeicher 1004. Je nach Architektur kann der Prozessor 1002 über einen einzelnen internen Cache oder mehrere Ebenen interner Caches verfügen. Andere beispielhafte Implementierungen beinhalten eine Kombination aus internen und externen Caches in Abhängigkeit von der konkreten Implementierung und den Anforderungen. Registerdatei 1006 dient dem Speichern unterschiedlicher Datenarten in unterschiedlichen Registern, einschließlich Ganzzahlregistern, Gleitkommaregistern, Vektorregistern, Bankregistern, Schattenregistern, Prüfpunktregistern, Statusregistern und Anweisungszeigerregistern.
Ausführungseinheit 1008, einschließlich Logik zum Durchführen von Ganzzahl- und Gleitkommaoperationen, befinden sich ebenfalls in dem Prozessor 1002. Der Prozessor 1002 enthält in einer beispielhaften Implementierung einen Mikrocode (ucode) ROM zum Speichern von Mikrocode, der, wenn er ausgeführt wird, Algorithmen für bestimmte Makroanweisungen oder zum Bearbeiten komplexer Szenarien durchführt. Hier ist der Mikrocode potenziell aktualisierbar, um Logik-Bugs/Fixes für Prozessor 1002 zu handhaben. Für eine beispielhafte Implementierung enthält Ausführungseinheit 1008 Logik zum Bearbeiten eines gepackten Anweisungssatzes 1009. Durch Einbeziehung des gepackten Anweisungssatzes 1009 in den Anweisungssatz eines Allzweckprozessors 1002, zusammen mit der zugehörigen Schaltungsanordnung zum Ausführen der Anweisungen, können die Operationen, die von vielen Multimediaanwendungen verwendet werden, unter Verwendung gepackter Daten in einem Allzweckprozessor 1002 durchgeführt werden. Somit werden viele Multimediaanwendungen beschleunigt und effizienter ausgeführt, indem die volle Breite des Datenbus eines Prozessors zum Durchführen von Operationen an den gepackten Daten verwendet wird. Dies eliminiert potenziell die Notwendigkeit kleinere Dateneinheiten über den Datenbus des Prozessors, ein Datenelement nach dem anderen, zu übertragen, um eine oder mehrere Datenelemente zu bearbeiten.
Alternative beispielhafte Implementierungen einer Ausführungseinheit 1008 können auch in Mikrosteuereinrichtungen, eingebetteten Prozessoren, Grafikvorrichtungen, DSPs und anderen Arten von Logikschaltungsanordnungen verwendet werden. System 1000 enthält einen Speicher 1020. Speicher 1020 enthält eine dynamische Direktzugriffsspeicher (DRAM) Vorrichtung, eine statische Direktzugriffsspeicher (SRAM) Vorrichtung, Flash-Speichervorrichtung oder eine andere Speichervorrichtung. Speicher 1020 speichert Anweisungen und/oder Daten, die von Datensignalen repräsentiert werden, die von dem Prozessor 1002 auszuführen sind.
Ein Systemlogikchip 1016 ist mit dem Prozessorbus 1010 und Speicher 1020 verbunden. Der Systemlogikchip 106 in der veranschaulichten beispielhaften Implementierung ist ein Speichersteuerknoten (MCH). Der Prozessor 1002 kann mit dem MCH 1016 über einen Prozessorbus 1010 kommunizieren. Der MCH 1016 stellt dem Speicher 1020 einen Speicherpfad mit hoher Bandbreite 1018 für Anweisungs- und Datenspeicherung und für das Speichern von Grafikbefehlen, Daten und Texturen bereit. Der MCH 1016 soll Datensignale zwischen dem Prozessor 1002, Speicher 1020 und anderen Komponenten in dem System 1000 leiten und die Datensignale zwischen Prozessorbus 1010, Speicher 1020 und System I/O 1022 überbrücken. In manchen beispielhaften Implementierungen kann der Systemlogikchip 1016 einen Grafikport für das Verbinden einer Grafiksteuereinrichtung 1012 bereitstellen. Der MCH 1016 ist durch eine Speicherschnittstelle 1018 mit Speicher 1020 verbunden. Die Grafikkarte 1012 ist mit dem MCH 1016 durch eine beschleunigte Grafikport (AGP) Verbindung 1014 verbunden.
System 1000 verwendet einen proprietären Knotenschnittstellenbus 1022 zum Verbinden des MCH 1016 mit dem I/O-Steuereinrichtungsknoten (ICH) 1030. Der ICH 1030 stellt direkte Verbindungen mit manchen I/O-Vorrichtungen über einen lokalen I/O-Bus bereit. Der lokale I/O-Bus ist ein Hochgeschwindigkeits-I/O-Bus zum Verbinden von Peripheriegeräten mit dem Speicher 1020, Chipset und Prozessor 102. Einige Beispiele sind Audiosteuereinrichtungen, Firmwareknoten (Flash BIOS) 128, drahtloser Sendeempfänger 126, Datenspeicher 124, Legacy-I/O-Steuereinrichtung, die Benutzereingabe- und Tastaturschnittstellen enthält, ein serieller Erweiterungsport, wie etwa ein Universal Serial Bus (USB), und eine Netzwerksteuereinrichtung 134. Die Datenspeichervorrichtung 124 kann ein Festplattenlaufwerk, ein Diskettenlaufwerk, eine CD-ROM-Vorrichtung, eine Flash-Speicher-Vorrichtung oder eine andere Massenspeichervorrichtung umfassen.
Für eine andere beispielhafte Implementierung eines Systems kann eine Anweisung gemäß einer beispielhaften Implementierung mit einem System-auf-einem-Chip verwendet werden. Eine beispielhafte Implementierung eines Systems-auf-einem-Chip umfasst einen Prozessor und einen Speicher. Der Speicher für ein solches System ist ein Flash-Speicher. Der Flash-Speicher kann sich auf dem gleichen Chip wie der Prozessor und andere Systemkomponenten befinden. Zusätzlich können sich auch andere Logikblöcke, wie etwa eine Speichersteuereinrichtung oder Grafiksteuereinrichtung, auf einem System-auf-einem-Chip befinden.
11 ist ein Blockdiagramm der Mikroarchitektur für einen Prozessor 1100, der Logikschaltungen für das Ausführen von Anweisungen gemäß einer beispielhaften Implementierung der vorliegenden Offenbarung enthält. In manchen beispielhaften Implementierungen kann eine Anweisung gemäß einer beispielhaften Implementierung implementiert sein, um an Datenelement mit Größen Byte, Wort, Doppelwort, Vierwort usw. sowie Datentypen, wie Einzel- und Doppelpräzisions-Ganzzahl und Gleitkomma-Datentypen zu arbeiten. In einer beispielhaften Implementierung ist das In-Order-Frontend 1101 der Teil des Prozessors 1100, der Anweisungen, die auszuführen sind, einholt und sie zur späteren Verwendung in der Prozessor-Pipeline vorbereitet. Das Frontend 1101 kann mehrere Einheiten enthalten. In einer beispielhaften Implementierung ruft der Anweisungsvorabrufer 1126 Anweisungen aus dem Speicher ab und führt sie einem Anweisungsdecodierer 1128 zu, der sie wiederum decodiert und interpretiert. In einer beispielhaften Implementierung decodiert der Decodierer zum Beispiel eine erhaltene Anweisung in eine oder mehrere Operation/en, die „Mikroanweisungen“ oder „Mikrooperationen“ (auch Mikro oder Uops genannt) genannt werden, die die Maschine ausführen kann. In anderen beispielhaften Implementierungen analysiert der Decodierer die Anweisung in einen Opcode und entsprechende Daten- und Steuerfelder, die von der Mikroarchitektur verwendet werden, um Operationen gemäß einer beispielhaften Implementierung durchzuführen. In einer beispielhaften Implementierung verwendet der Ablaufverfolgungs-Cache 1130 decodierte Uops und fügt sie in programmgesteuerte Sequenzen oder Ablaufverfolgungen in der Uop-Warteschlange 1134 zur Ausführung zusammen. Wenn der Ablaufverfolgungs-Cache 1130 auf eine komplexe Anweisung trifft, stellt der Mikrocode-ROM 1132 die für den Abschluss der Operation benötigten Uops bereit.
Manche Anweisungen werden in einen einzelnen Mikroop gewandelt, während andere mehrere Mikroops bis zum Abschluss der vollständigen Operation benötigen. In einer beispielhaften Ausführungsform greift der Decodierer 1128, wenn mehr als vier Mikroops für den Abschluss einer Anweisung benötigt werden, auf den Mikrocode-ROM 1132 zu, um die Anweisung zu bearbeiten. Für eine beispielhafte Implementierung kann eine Anweisung in eine kleine Anzahl von Mikroops zum Verarbeiten an dem Anweisungsdecodierer 1128 decodiert werden. In einer anderen beispielhaften Implementierung kann eine Anweisung innerhalb des Mikrocode-ROM 1132 gespeichert werden, falls eine Anzahl von Mikroops zum Erreichen der Operation benötigt wird. Der Ablaufverfolgungs-Cache 1130 bezieht sich auf einen programmierbaren Logikarray (PLA) Eingangspunkt, um einen korrekten Mikroanweisungszeiger für das Lesen der Mikrocodesequenzen zum Abschließen einer oder mehrerer Anweisungen gemäß einer beispielhaften Implementierung aus dem Mikrocode-ROM 1132 zu ermitteln. Nachdem das Mikrocode-ROM 1132 das Sequenzieren von Mikroops für eine Anweisung abgeschlossen hat, nimmt das Frontend 1101 der Maschine das Abrufen von Mikroops aus dem Ablaufverfolgungs-Cache 1130 wieder auf.
In der Out-of-Order-Ausführungsengine 1103 werden die Anweisungen zur Ausführung vorbereitet. Die Out-of-Order-Ausführungslogik verfügt über eine Reihe von Puffern zum Glätten und Neuordnen des Anweisungsflusses zum Optimieren der Leistung, während sie die Pipeline durchlaufen und für die Ausführung eingeplant werden. Die Zuweisungslogik weist die Maschinenpuffer und Ressourcen, die jedes Uop benötigt, für die Ausführung zu. Die Registerumbenennungslogik benennt Logikregister auf Einträgen in einer Registerdatei um. Der Zuweiser weist auch einen Eintrag für jedes Uop in einer der beiden Uop-Warteschlangen, eine für Speicheroperationen und eine für Nicht-Speicheroperationen, vor den Anweisungsplanern zu: Speicherplaner, Schnellplaner 1102, langsamer/allgemeiner Gleitkommaplaner 1104 und einfacher Gleitkommaplaner 1106. Die Uop-Planer 1102, 1104, 1106 ermitteln, wenn ein Uop für die Ausführung bereit ist, auf Basis der Bereitschaft ihrer abhängigen Eingaberegisteroperandenquellen und der Verfügbarkeit der Ausführungsressourcen die Uops, die zum Abschließen ihrer Operation benötigt werden. Der Schnellplaner 1102 einer beispielhaften Implementierung kann für jede Hälfte des Haupttaktzyklus planen, während die anderen Planer nur einmal pro Hauptprozessortaktzyklus planen können. Die Planer arbitrieren für die Dispatchports, um Uops für die Ausführung zu planen.
Registerdateien 1108, 1110 liegen zwischen den Planern 1102, 1104, 1106 und den Ausführungseinheiten 1112, 1114, 1116, 1118, 1120, 1122, 1124 in dem Ausführungsblock 1111. Es gibt eine separate Registerdatei 1108, 1110 für Ganzzahl- bzw. Gleitkommaoperationen. Jede Registerdatei 1108, 1110 einer beispielhaften Implementierung enthält auch ein Bypassnetzwerk, das gerade abgeschlossene Resultate, die noch nicht in die Registerdatei geschrieben wurden, zu neuen abhängigen Uops um- oder weiterleiten kann. Die Ganzzahlregisterdatei 1108 und die Gleitkommaregisterdatei 1110 sind ebenfalls fähig, Daten mit der anderen zu kommunizieren. Bei einer beispielhaften Implementierung wird die Ganzzahlregisterdatei 1108 in zwei separate Registerdateien geteilt; eine Registerdatei für die 32-Bits Daten niedriger Ordnung und eine zweite Registerdatei für die 32-Bits Daten hoher Ordnung. Die Gleitkommaregisterdatei 1110 einer beispielhaften Implementierung hat 128-Bit breite Einträge, da Gleitkommaanweisungen typischerweise über Operanden von 64 bis 128 Bits in Breite verfügen.
Der Ausführungsblock 1111 enthält die Ausführungseinheiten 1112, 1114, 1116, 1118, 1120, 1122, 1124, wo die Anweisungen tatsächlich ausgeführt werden. Dieser Abschnitt enthält die Registerdateien 1108, 1110, die die Ganzzahl- und Gleitkommadatenoperandenwerte, die die Mikroanweisungen ausführen müssen, speichern. Der Prozessor 1100 einer beispielhaften Implementierung umfasst eine Anzahl von Ausführungseinheiten: Adressgenerierungseinheit (AGU) 1112, AGU 1114, Schnell-ALU 1116, Schnell-ALU 1118, Langsam-ALU 1120, Gleitkomma-ALU 1122, Gleitkommabewegungseinheit 1124. Bei einer beispielhaften Implementierung führen die Gleitkommausführungsblöcke 1122, 1124 Gleitkomma-, MMX-, SIMD- und SSE- oder andere Operationen aus. Die Gleitkomma-ALU 1122 einer beispielhaften Implementierung enthält einen 64-Bit mal 64-Bit Gleitkommateiler zum Ausführen von Divisions-, Wurzel- und Rest-Mikro-Ops. In Implementierungen der vorliegenden Offenbarung können zum Beispiel Anweisungen, die einen Gleitkommawert enthalten, mit der Gleitkommahardware bearbeitet werden. In einer beispielhaften Implementierung laufen die ALU-Operationen zu den Hochgeschwindigkeits-ALU-Ausführungseinheiten 1116, 1118. Die schnellen ALUs 1116, 1118 einer beispielhaften Implementierung können schnelle Operationen mit einer effektiven Latenz von einem halben Taktzyklus ausführen. Bei einer beispielhaften Implementierung laufen komplexeste Ganzzahloperationen zu der Langsam-ALU 1120, da die Langsam-ALU-1120 Ganzzahlausführungshardware für Operationen mit einem langen Latenztyp enthalten, wie etwa einen Multiplizierer, Verschiebungen, Flag-Logik und Verzweigungsverarbeitung. Speicher-Lade-/SpeicherOperationen werden von den AGUs 1112, 1114 ausgeführt. Bei einer beispielhaften Implementierung sind die Ganzzahl-ALUs 1116, 1118, 1120 im Kontext des Durchführens von Ganzzahloperationen an 64-Bit Datenoperanden beschrieben. In alternativen beispielhaften Implementierungen können die ALUs 1116, 1118, 1120 implementiert werden, um eine Vielzahl von Datenbits, einschließlich 16, 32, 128, 256 usw. zu unterstützen. Ebenso können die Gleitkommaeinheiten 1122, 1124 implementiert werden, um einen Bereich von Operanden mit Bits verschiedener Breite zu unterstützen. Bei einer beispielhaften Implementierung können die Gleitkommaeinheiten 1122, 1124 an 128-Bits breiten gepackten Datenoperanden zusammen mit SIMD- und Multimediaanweisungen arbeiten.
In einer beispielhaften Implementierung senden die Uops-Planer 1102, 1104, 1106 abhängige Operationen bevor die übergeordnete Ladung die Ausführung abgeschlossen hat. Da Uops im Prozessor 1100 spekulativ geplant und ausgeführt werden, enthält der Prozessor 1100 auch Logik zum Bearbeiten von Speicherfehlern. Falls eine Datenladung im Datencache fehlt, kann es abhängige in der Pipeline befindlichen Operationen geben, die den Planer mit vorübergehend inkorrekten Daten verlassen haben. Ein Wiederholungsmechanismus verfolgt Anweisungen, die inkorrekte Daten enthalten, und führt sie erneut aus. Nur abhängige Operationen müssen wiederholt werden und es ist unabhängigen Informationen erlaubt, abgeschlossen zu werden. Die Planer und der Wiederholungsmechanismus einer beispielhaften Implementierung eines Prozessors sind ebenfalls dafür entworfen, Anweisungssequenzen für Textstringvergleichsoperationen aufzufangen.
Der Begriff „Register“ kann sich auf interne Prozessorspeicherpositionen beziehen, die als Teil der Anweisungen zum Identifizieren von Operanden verwendet werden. Mit anderen Worten: Register können jene sein, die von außerhalb des Prozessors (aus einer Programmiererperspektive) verwendbar sind. Die Register einer beispielhaften Implementierung sollten jedoch nicht in Bedeutung auf einen bestimmten Schaltungstyp beschränkt sein. Vielmehr ist ein Register einer beispielhaften Implementierung zum Speichern und Bereitstellen von Daten und zum Durchführen der hierin beschriebenen Funktionen fähig. Die hierin beschriebenen Register können von einer Schaltungsanordnung innerhalb eines Prozessors unter Verwendung einer beliebigen Zahl unterschiedlicher Techniken implementiert werden, wie etwa dedizierte physische Register, dynamisch zugewiesene physische Register unter Verwendung von Registerumbenennung, Kombinationen aus dedizierten und dynamisch zugewiesenen physischen Registern usw. In einer beispielhaften Implementierung speichern Ganzzahlregister 32-Bit-Ganzzahldaten. Eine Registerdatei einer beispielhaften Implementierung enthält auch acht Multimedia-SIMD-Register für gepackte Daten. Für die nachfolgenden Diskussionen verstehen sich Register als Datenregister, die dafür entworfen wurden, gepackte Daten zu halten, wie etwa 64-Bits breite MMXTM-Register (in manchen Fällen auch als „mm“ Register bezeichnet) in Mikroprozessoren, die mit MMX-Technologie von Intel Corporation of Santa Clara, Kalifornien, befähigt sind. Diese MMX-Register, die sowohl in Ganzzahl- als auch Gleitkommaformen verfügbar sind, können mit gepackten Datenelementen arbeiten, die SIMD- und SSE-Anweisungen begleiten. Ebenso können auch 128-Bits breite XMM-Register in Bezug auf SSE2, SSE3, SSE4 oder darüber hinaus (generisch als „SSEx“ bezeichnet) Technologie verwendet werden, um solche gepackten Datenoperanden zu halten. In einer beispielhaften Implementierung müssen die Register beim Speichern gepackter Daten und von Ganzzahldaten nicht zwischen den beiden Datentypen differenzieren. In einer beispielhaften Implementierung sind Ganzzahl und Gleitpunkt entweder in der gleichen Registerdatei oder in unterschiedlichen Registerdateien enthalten. Des Weiteren können in einer beispielhaften Implementierung Gleitpunkt- und Ganzzahldaten in unterschiedlichen oder den gleichen Registern gespeichert sein.
Gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung kann ein Verarbeitungssystem, wie das Verarbeitungssystem, einen oder mehrere Verarbeitungskern/e umfassen, der/die mit einem architektonisch geschütztem Speicher verbunden sind. In gewissen Implementierungen kann das Verarbeitungssystem Software Guard Extensions (SGX) implementieren, die ein Satz von Erweiterungen der Intel®-Architektur sind, der es einer Anwendung erlaubt, einen geschützten Container, der als eine Enklave bezeichnet wird, zu instanziieren.
Unter Bezugnahme auf 12 wird ein Blockdiagramm eines beispielhaften Verarbeitungssystems gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung gezeigt. Wie in 12 gezeigt kann Verarbeitungssystem 1200 einen oder mehrere Verarbeitungskern/e 1211 enthalten, wobei jeder Verarbeitungskern 1211 einen lokalen ersten Level (L1) Cache 1215, der diesem zugeordnet ist, aufweist. L1 Cache 1215 kann kommunikativ mit einem gemeinsamen letzten Level-Cache (LLC) 1217 verbunden sein. In einem veranschaulichenden Beispiel kann die Cachehierarchie, die L1 Cache 1215 und LLC 1217 umfasst, als eine inklusive Cachehierarchie konfiguriert sein, so dass zumindest ein Teil der in L1 Cache 1215 gespeicherten Informationen auch in LLC 1217 gespeichert sein können.
Gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung kann ein Verarbeitungssystem 1200 einen architektonisch geschützten Speicher umfassen. Verarbeitungskern 1211 kann Verarbeitungslogik umfassen, die zum Implementieren einer sicheren Enklave durch Ausführen von Anweisungen, die sich in dem geschützten Speicher befinden, und Zugreifen auf Daten, die sich in dem geschützten Speicher befinden, während unautorisierter Zugriff auf den geschützten Speicher sogar durch privilegierte Anwendungen geschützt sind, konfiguriert ist, wie hierin nachfolgend ausführlicher beschrieben.
Eine aktive sichere Enklave kann in einen verschlüsselten Teil und einen entschlüsselten Teil aufgeteilt sein. Der verschlüsselte Teil kann sich in einem ungeschützten Speicher befinden (wie etwa Hauptspeicher oder Diskette). Der verschlüsselte Teil befindet sich in dem Enklavenseitencache (EPC) 1282. Der EPC ist ein geschützter Speicher, der von dem Verarbeitungssystem verwendet wird, um vorübergehend Enklavenseiten, wenn sie kryptografisch nicht geschützt sind, zu speichern.
Ein Verarbeitungssystem, das in einem kryptografisch geschützten Plattformspeicher SGX unterstützt und EPC implementiert, unterstützt die Fähigkeit für den BIOS, einen oder mehrere Speicherbereich/e, die als Processor Reserved Memory (PRM) bezeichnet werden, zu reservieren. Der BIOS weist den PRM durch Konfigurieren eines Satzes von Bereichsregistern, die kollektiv als PRMRR bezeichnet werden, zu. Der EPC wird innerhalb des PRM zugewiesen. CPU-Speicherschutzmechanismen blockieren physisch den Zugriff auf den PRM von allen externen Agenten (DMA, Grafikengine usw.), indem sie solche Zugriffe als Referenzen auf nichtexistierenden Speicher behandeln.
Der EPC kann in Seiten mit einer vordefinierten Größe aufgeteilt werden, die als EPC-Seiten bezeichnet werden können. Der EPC wird vor Zugriffen durch Software geschützt, die sich außerhalb der Enklave befindet. Des Weiteren sind nichtautorisierte Parteien nicht dazu in der Lage, Klartextdaten, die zu Enklaven gehören, die über direkte Hardwareangriffe in den EPC geladen werden, zu lesen oder zu modifizieren. Der EPC befindet sich innerhalb des physischen Adressraums des Verarbeitungssystems, auf ihn kann aber nur unter Verwendung privilegierter oder nichtprivilegierter Enklavenanweisungen, die zum Bauen und Befähigen einer Enklave, dem Eintritt in/Austritt aus der Enklave, EPC-Verwaltung und zum Durchführen diverser anderer Operationen verwendet werden, zugegriffen werden.
Es gibt mehrere Mechanismen zum Implementieren des EPC. Das EPC kann als ein On-Die statischer Direktzugriffsspeicher (SRAM) oder dynamischer Direktzugriffsspeicher (DRAM) implementiert werden. Alternativ kann der EPC durch Maskieren von Wegen des Cache der letzten Ebene des CPU konstruiert werden. Ein anderer Mechanismus zum Implementieren des EPC ist die Memory Encryption Engine (MEE). MEE bezieht sich hierin auf eine hardwareimplementierte Verarbeitungslogik, die den Verkehr zwischen dem Prozessorpaket und dem Plattform-DRAM verschlüsselt, wodurch ein Mechanismus des Erzeugens eines kryptografisch geschützten volatilen Speichers unter Verwendung des Plattform-DRAM bereitgestellt wird. MEE kann versuchte Speicherzugriffe abfangen und diese Zugriffe auf eine kryptografische Steuereinrichtung weiterleiten, die einen oder mehrere Speicherzugriffe auf den Plattform-DRAM generieren kann, um Cipher-Text abzurufen, den Cipher-Text zum Erzeugen von Klartext zu verarbeiten und die ursprüngliche Speicherzugriffsanforderung zu befriedigen.
Wiederum unter Bezugnahme auf 12 kann L1 Cache 1215 Daten zu und von dem LLC 1220 übertragen. Speichersteuereinrichtung 1250 kann mit mit dem Cache der letzten Ebene 1220 und dem MEE 1280 verbunden sein. Speichersteuereinrichtung 1250 kann EPC 1282, das sich auf Sicherungsspeichervorrichtung 1286 innerhalb des physischen Adressraums 1288 befindet, bewerten.
Eine Enclave Page Cache Map (EPCM) ist eine geschützte Struktur, die von dem Verarbeitungssystem dafür eingesetzt wird, die Inhalte des EPC zu verfolgen. EPCM 1284 kann eine Vielzahl von Einträgen umfassen, wobei jeder Eintrag einer Seite in dem EPC entspricht. Jeder EPCM-Eintrag kann in einem implementierungsabhängigen Format die folgenden Informationen enthalten: ob die EPC-Seite gültig oder ungültig ist; eine Kennung der Enklaveninstanz, die für die Seite zuständig ist; die Art der Seite (REG, TCS, VA, SECS); die virtuelle Adresse, über die es der Enklave erlaubt ist auf die Seite zuzugreifen; Lese-/Schreib-/Ausführungsberechtigungen für die Seite; ob die Seite zugänglich ist oder nicht (BLOCKED oder UNBLOCKED).
EPCM 1284 kann von dem Verarbeitungssystem in dem Adressübersetzungsfluss, um Zugriffssteuerung auf die Enklavenseiten, die in den EPC geladen werden, zu erzwingen. Logisch stellt sie eine zusätzliche sichere Ebene der Zugriffskontrolle zusätzlich zur „Legacy“-Segmentierung, Paging-Tabellen und erweiterte Pagingtabellenmechanismen bereit.
Das EPC, die EPCM und diverse andere implementierungsspezifische Datenstrukturen können in Positionen innerhalb des architektonisch geschützten Speichers abgebildet werden. Wenn eine Anforderung zum Zugriff auf das EPC erzeugt wird, kann Verarbeitungssystem 1200 die Anforderung zu der Sicherungsspeicherposition, die verschlüsselte EPC-Daten enthält, abbilden und die Daten abrufen.
Es können diverse enklavenbezogene Funktionen in dem Microcode implementiert werden, die von den Hardwareimplementierungen des MEE und der Verarbeitungslogik, die die Enklavenfunktionalität implementiert, unterstützt werden. In bestimmten Implementierungen kann die Verarbeitungslogik den Zugriff auf EPC 1282 über einen Übersetzungsnachschlagepuffer (TLB) 1264 und Seitenfehltreffer (PMH) 1268 steuern.
In einem veranschaulichenden Beispiel kann ein TLB als eine Tabelle implementiert sein, die virtuelle Adressen zu physischen Adressen abbildet. „TLB-Treffer“ bezieht sich auf eine Situation, wenn eine angeforderte virtuelle Adresse in dem TLB vorhanden ist. „TLB-Fehltreffer“ bezieht sich auf die entgegengesetzte Situation: Wenn die angeforderte virtuelle Adresse nicht im TLB vorhanden ist, kann die Adressübersetzung durch Nachschlagen in der Seitentabelle fortfahren. Nachdem die physische Adresse festgestellt wurde, kann das Abbilden der virtuellen Adresse zur physischen Adresse in das TLB eingegeben werden.
Jeder TLB-Eintrag kann ein oder mehrere Bits enthalten, die das Identifizieren der Enklave angibt, die für die Speicherposition, auf die sich durch den TLB-Eintrag bezogen wird. Alternativ ist, falls diese Bits nicht bereitgestellt werden, ein TLB-Flush bei Verlassen der sicheren Enklave erforderlich, um nichtautorisierten Zugriff auf das EPC zu verhindern. In einem veranschaulichenden Beispiel kann, falls ein TLB-Fehltreffer auftritt, ein zusätzliches Nachschlagen Daten aus der EPC-Karte bei mehreren Speicherreferenzen abrufen. Die PMH kann das Nachschlagen in der EPC-Karte durchführen.
13 veranschaulicht schematisch eine Verwendung von EPTP-Schalt-VM-Funktion (z. B. VMFUNC 0) zum Befähigen einer virtuellen Maschine zum Durchführen bestimmter privilegierter Operationen ohne Exit in den VMM (z. B. zum Zugreifen auf einen Host-Speicher, der einer anderen virtuellen Maschine für Exit-lose Kommunikationen mit der anderen virtuellen Maschine zugewiesen ist). Wie in 13 schematisch veranschaulicht kann der VMM mehrere Speicheransichten für die virtuelle Maschine erzeugen, so dass eine erste Speicheransicht („Standardansicht“ 1310) es der virtuellen Maschine erlauben würde, den Gastcode auszuführen und auf die Gastdaten zuzugreifen, während eine zweite Speicheransicht („alternative Ansicht“ 1320) es der virtuellen Maschine erlauben würde, bestimmten geschützten Code auszuführen (z. B. um auf einen Gastspeicher zuzugreifen, der einer anderen virtuellen Maschine für Exit-lose Kommunikationen mit der anderen virtuellen Maschine zugewiesen ist). Der VMM kann ferner mehrere Speicherseiten erzeugen, die den vorstehend erwähnten Ansichten entsprechen, so dass jede Speicherseite über mindestens eine Ausführungsberechtigung in der jeweiligen Ansicht verfügt. Eine erste Speicherseite 1330, die von der Standardansicht 1310 aus ausführbar ist, kann ungeschützten (d. h. durch den Gast modifizierbare/n) von dem Gast ausführbaren Code und Gastdaten umfassen. Eine zweite Speicherseite 1340, die von der alternativen Ansicht 1320 aus ausführbar ist, kann geschützten durch den Gast ausführbaren Code enthalten, der eingesetzt werden kann, um bestimmte Aufgaben durchzuführen (z. B. Exit-lose Kommunikation mit einer anderen virtuellen Maschine) durchzuführen.
Der erweiterte Seitentabellenmechanismus (EPT) ist ein Merkmal, das verwendet werden kann, um die Virtualisierung physischen Speichers zu unterstützen. Wenn EPT verwendet wird, werden bestimmte Adressen, die normalerweise als physische Adressen (und zum Zugriff auf den Speicher) verwendet werden würden, stattdessen als physische Gastadressen behandelt. Physische Gastadressen werden übersetzt, indem ein Satz von EPT-Paging-Strukturen zum Produzieren physischer Adressen, die zum Zugriff auf den Speicher verwendet werden, durchlaufen wird.
EPT wird verwendet, wenn die „Enable EPT“ VM-Ausführungssteuerung gesetzt ist. Sie übersetzt die physischen Gastadressen, die in der VMX-Nicht-Root-Operation verwendet werden, und jene, die von dem VM-Eingang verwendet werden, für eine Ereignisinjektion. Die Übersetzung von physischen Gastadressen zu physischen Adressen wird durch einen Satz von EPT-Paging-Strukturen festgelegt. Die EPT-Paging-Strukturen sind jenen ähnlich, die verwendet werden, um lineare Adressen zu übersetzen, während der Prozessor sich im IA-32e Modus befindet.
14 veranschaulicht schematisch ein Blockdiagramm eines beispielhaften Verarbeitungssystems 100 gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung. Wie in 14 gezeigt kann Verarbeitungssystem 1400 einen oder mehrere Verarbeitungskerne 1411 umfassen, die über eine gemeinsame Verbindung 1415, mit einem Speicher 1420 verbunden sind. Verarbeitungssystem 100 kann einen hardwareunterstützten Virtualisierungsmechanismus implementieren, um, unter Steuerung eines VMM 1417, der in dem privilegiertesten Ausführungsmodus arbeitet (auch als VMX-Root-Ausführungsmodus bezeichnet), ein oder mehrere virtuelle Maschinen in einem weniger privilegierten Ausführungsmodus (auch als VMX-Nicht-Root-Ausführungsmodus bezeichnet) auszuführen, wie nachfolgend hierin ausführlicher beschrieben. In einem veranschaulichenden Beispiel kann ein VMM konfiguriert werden, um eine oder mehrere virtuelle Maschine/n 1431 zu erzeugen und zu verwalten, die diverse Softwareanwendungen ausführen, die von dem jeweiligen Gast-Betriebssystem gesteuert werden. In gewissen Implementierungen kann Verarbeitungssystem 1400 auch diverse andere Komponenten enthalten, die in 14 nicht gezeigt werden.
Die Softwareanwendungen, die von virtuellen Maschinen 1431 ausgeführt werden, können sich auf Speicherposition unter Verwendung virtueller Gastadressen beziehen (z. B. durch lineare Gastadressen in dem linearen Adressenraum der jeweiligen virtuellen Maschine repräsentiert). In Reaktion auf das Empfangen einer Speicherzugriffsanforderung kann der Prozessor die virtuelle Gastadresse, auf die Bezug genommen wird, unter Verwendung einer Gast-OS-Seitentabelle (OS PT) 1433 zu einer physischen Gastadresse übersetzen. Verarbeitungssystem 100 kann dann die physische Gastadresse unter Verwendung einer erweiterten Seitentabelle (EPT) 1439 in eine entsprechende physische Hostadresse übersetzen.
In gewissen Implementierungen kann Verarbeitungssystem 100 einen Übersetzungsnachschlagepuffer (TLB) 1435 zum Zwischenspeichern einer Vielzahl jüngster Abbildunen der virtuellen Gastadressen zu entsprechenden physischen Hostadressen verwenden.
15 veranschaulicht schematisch eine beispielhafte Implementierung einer virtuellen Adressenumsetzung gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung. In Reaktion darauf, dass eine virtuelle Gastadresse nicht unter Verwendung des TLB aufgelöst werden kann, kann ein Seitenfehlbehandler (PMH) 1537 aufgerufen werden, um unter Verwendung von OS-PT 1533 einen Seitentabellenschritt zum Übersetzten der virtuellen Gastadresse zu der entsprechenden physischen Gastadresse durchzuführen und dann EPT 1539 zum Übersetzen der physischen Adresse zu der entsprechenden physischen Gastadresse zu verwenden.
Wenn die „Enable EPT“ VM-Ausführungssteuerung 1 ist, hängt die Identität der physischen Gastadressen von dem Wert von CR0.PG ab. Wenn CR0.PG = 0, wird jede lineare Adresse als eine physische Gastadresse behandelt. Wenn CR0.PG = 1, sind physische Gastadressen jene, die von den Inhalten des Steuerregisters CR3 und den Gast-Pagingstrukturen abgeleitet wurden. (Dies enthält die Werte der PDPTEs, deren logische Prozessoren in internen, nicht-architektonischen Registern speichern.) Das Letztgenannte enthält (in Seitentabelleneinträgen und in andern Pagingstruktureinträgen für, die Bit 7-PS- 1 ist) die Adressen zu denen lineare Adressen von den Gastpagingstrukturen übersetzt werden.
Wenn CR0.PG = 1, macht das Übersetzten einer linearen Adresse zu einer physischen Adresse mehrere Übersetzungen der physischen Gastadressen unter Verwendung von EPT erforderlich. Nehmen wir beispielsweise an, dass CR4.PAE = CR4.PSE = 0 ist. Das Übersetzten einer linearen 32-Bit-Adresse geht dann wie folgt:
Bits 31:22 der linearen Adresse wählen in dem Gastseitenverzeichnis, das sich an der physischen Gastadresse in CR3 befindet, einen Eintrag aus. Die physische Adresse des Gastseitenverzeichniseintrags (PDE) wird durch EPT übersetzt, um die physische Adresse der Gast-PDE zu ermitteln.
Bits 21:12 der linearen Adresse wählen in der Gastseitentabelle, die sich an der physischen Gastadresse in der Gast-PDE befindet, einen Eintrag aus. Die physische Adresse des Gastseitentabelleneintrags (PTE) wird durch EPT übersetzt, um die physische Adresse der Gast-PTE zu ermitteln.
Bits 11:0 der linearen Adresse ist der Versatz in dem Seitenframe, der sich an der physischen Gastadresse in der Gast-PTE befindet. Die physische Gastadresse, die durch diesen Versatz ermittelt wurde, wird durch EPT übersetzt, um die physische Adresse zu ermitteln, zu der die ursprüngliche lineare Adresse übersetzt.
16 veranschaulicht schematisch beispielhafte Formate von Paging-Struktureinträgen, die von einem Verarbeitungssystem verwendet werden können, das gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung arbeitet. Solche Pagingstruktureinträge können Seitentabelleneinträge enthalten, die sich auf Speicherseiten verschiedener Größen beziehen, sowie Seitenkartenebene 4 (PML4) Einträge, EPT-Seitenverzeichniszeiger-Tabelleneinträge und Seitenverzeichniseinträge, die sich auf das EPT beziehen. In 16 ist „M“ eine Abkürzung für die maximale physische Adresse, die von dem Prozessor (MAXPHYADDR) Wert unterstützt wird, „R“ gibt das Lesezugriffsprivileg für die Seite an, auf die sich durch den entsprechenden Eintrag bezogen wird, „W“ gibt das Schreibzugriffsprivileg für die Seite an, auf die sich durch den entsprechenden Eintrag bezogen wird, und „X“ gibt das Ausführungszugriffsprivileg für die Seite an, auf die sich durch den entsprechenden Eintrag bezogen wird.
In gewissen Implementierungen unterstützt ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, Zugriffs- und Dirty-Flags in gewöhnlichen Pagingstruktureinträgen. Manche Prozessoren unterstützen auch entsprechende Flags in EPT-Pagingstruktureinträgen. Für einen EPT-Pagingstruktureintrag, der während der Übersetzung der physischen Gastadresse verwendet wird, ist Bit 8 die Zugriffs-Flag. Für einen EPT-Pagingstruktureintrag, der eine Seite abbildet (im Gegensatz zu einer Bezugnahme auf eine andere EPT-Pagingstruktur) ist Bit 9 die Dirty-Flag. Wann immer der Prozessor eine EPT-Pagingstruktur im Rahmen der Übersetzung der physischen Gastadresse verwendet, legt er die Flag, auf die zugegriffen wurde, in diesem Eintrag fest (sofern noch nicht festgelegt). Wann immer in eine physische Gastadresse geschrieben wird, legt der Prozessor die Dirty-Flag (sofern noch nicht festgelegt) in dem EPT-Pagingstruktureintrag, der die endgültige physische Adresse für die physische Gastadresse identifiziert, fest (entweder ein EPT PTE oder ein EPT-Pagingstruktureintrag, bei dem Bit 7 1 ist).
Bei Zugriff und wenn Dirty-Flags für EPT aktiviert sind, greift der Prozessor auf Gast-Pagingstruktureinträge zu, die als Schreibevorgänge behandelt werden. Somit veranlasst solch ein Zugriff den Prozessor, die Dirty-Flag in dem EPT-Pagingstruktureintrag zu setzen, der die endgültige physische Adresse des Gast-Pagingstruktureintrags identifiziert. (Dies gilt nicht für Ladungen der PDPTE-Register für PAE-Paging von der MOV to CR Anweisung. Diese Ladungen von Gast-PDPTEs werden als Lesevorgänge behandelt und veranlassen den Prozessor nicht, die Dirty-Flag ein einem EPT-Pagingstruktureintrag festzulegen.) Diese Flags sind „sticky“. Das heißt, nachdem sie gesetzt wurden, gibt der Prozessor sie nicht wieder frei; nur Software kann sie freigeben.
Ein Prozessor kann Informationen aus den EPT-Pagingstruktureinträgen in TLBs und Pagingstrukturcaches zwischenspeichern. Diese Tatsache impliziert, dass, falls Software eine Flag, auf die zugegriffen wird, oder eine Dirty-Flag von 1 zu 0 ändert, der Prozessor das entsprechende Bit im Speicher bei einem späteren Zugriff unter Verwendung einer betroffenen physischen Gastadresse möglicherweise nicht setzt.
Wie vorstehend hierin erwähnt kann in gewissen Implementierungen ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung arbeitet, den Adressenübersetzungsprozess durch Zwischenspeichern der Prozessordaten aus den Strukturen im Speicher, die den Prozess steuern, beschleunigen. Die VPID- und EPT-Funktionen der Architektur für VMX-Betrieb vergrößern diese Caching-Architektur. EPT definiert den gastphysischen Adressenraum und definiert Übersetzungen zu diesem Adressenraum (aus dem Linearadressenraum) und aus dem Adressenraum (zu dem physischen Adressenraum).
Beide Funktionen steuern die Art und Weise, in der ein logischer Prozessor Informationen, die aus den Pagingstrukturen zwischengespeichert wurden, erzeugt und verwendet.
Ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, kann zwei Arten von übersetzungsbezogenen Informationen, die von einem logischen Prozessor zwischengespeichert werden können, unterstützen: Übersetzungen, die Abbildungen aus Linearseitenzahlen zu physischen Seitenframes sind, und Pagingstrukturcaches, die die oberen Bits einer linearen Seitenzahl zu Informationen aus den Pagingstruktureinträgen, die zum übersetzen linearer Adressen, die diesen oberen Bits entsprechen, verwendet werden, abbilden.
Die gleichen Arten von Informationen können zwischengespeichert werden, wenn VPIDS und EPT in Verwendung sind. Ein logischer Prozessor kann solche Informationen auf Grundlage ihrer Funktion zwischenspeichern und verwenden. Informationen mit unterschiedlicher Funktionalität werden wie folgt identifiziert:
Lineare Abbildungen enthalten lineare Übersetzungen (jede davon ist eine Abbildung aus einer linearen Seitenzahl zu dem physischen Seitenframe zu dem sie übersetzt, zusammen mit Informationen über Zugriffsprivilegien und Speicherschreiben) und lineare Pagingstrukturcacheeinträge (jeder davon ist eine Abbildung aus dem oberen Teil einer linearen Adresse zu der physischen Adresse der Pagingstruktur, die zum Übersetzten der entsprechenden Region des Linearadressenraums verwendet wird, zusammen mit Informationen über Zugriffsprivilegien). Bits 47:39 einer linearen Adresse würden zum Beispiel zu der Adresse der Verzeichniszeigertabelle der relevanten Seite abgebildet.
Physische Gastabbildungen enthalten physische Gastübersetzungen (jede davon ist eine Abbildung aus einer physischen Gastseitenzahl zu dem physischen Seitenframe zu dem sie übersetzt, zusammen mit Informationen über Zugriffsprivilegien und Speicherschreiben) und physische Gastpagingstrukturcacheeinträge (jeder davon ist eine Abbildung aus dem oberen Teil einer physischen Gastadresse zu der physischen Adresse der EPT-Pagingstruktur, die zum Übersetzten der entsprechenden Region des physischen Gastadressenraums verwendet wird, zusammen mit Informationen über Zugriffsprivilegien).
Wie hierin vorstehend erwähnt, kann in bestimmten Implementierungen ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, sowohl Host- als auch Gaststeuerung externer Interrupts unterstützen. Während eine Gaststeuerung externer Interrupts für partitionierte Verwendungen geeignet sein könnte (unterschiedliche CPU-Kerne/Threads und I/O-Vorrichtungen zu unabhängigen virtuellen Maschinen partitioniert), können manche VMMs, die auf VMX aufbauen, eine Hoststeuerung externer Interrupts nutzen. Mit Hoststeuerung externer Interrupts verwaltet der VMM (oder das Host-OS in einem gehosteten VMM-Modell) die physischen Interruptsteuereinrichtungen in der Plattform und die durch sie erzeugten Interrupts. Der VMM legt softwareemulierte virtuelle Interruptsteuereinrichtungsvorrichtungen (wie etwa PIC und APIC) für jede Instanz einer virtuellen Gastmaschine frei.
In gewissen Implementierungen verwendet ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, 8-Bit Vektoren von denen 224 (20H - FFH) für externe Interrupts verfügbar sind. Vektoren werden dazu verwendet, um den entsprechenden Eintrag in der Interrupt Descriptor Tabelle (IDT) auszuwählen. Die VMX-Operation ermöglicht es jedem Gast seine eigene IDT zu steuern. Hostvektoren bezieht sich sich auf Vektoren, die von der Plattform an den Prozessor während des Interruptanerkennungszyklus zugestellt werden. Gastvektoren bezieht sich auf Vektoren, die von einem Gast programmiert sind, um einen Eintrag in seiner Gast-IDT auszuwählen. In Abhängigkeit von den I/O-Ressourcenverwaltungsmodellen, die von dem VMM-Entwurf unterstützt werden, kann der Gastvektorraum sich mit dem zugrundeliegenden Hostvektorraum überschneiden oder nicht.
Interrupts von virtuellen Vorrichtungen: Gastvektorzahlen für virtuelle Interrupts, die im Auftrag emulierter virtueller Vorrichtungen an Gäste zugestellt werden, haben keinen direkten Bezug zu den Hostvektorzahlen der Interrupts aus physischen Vorrichtungen, auf denen sie emuliert werden. Ein Gastvektor, der von der gastbetriebenen Umgebung für eine virtuelle Vorrichtung zugestellt wird, wird von dem VMM gespeichert und verwendet, wenn virtuelle Interrupts im Auftrag der virtuellen Vorrichtung injiziert werden.
Interrupts von zugewiesenen physischen Vorrichtungen: Hardwareunterstützung für I/O-Vorrichtungszuweisung erlaubt es, dass physische I/O-Vorrichtungen in der Hostplattform an die VMs zugewiesen (direkt abgebildet) werden. Gastvektoren für Interrupts von direkt abgebildeten physischen Vorrichtungen benötigen äquivalenten Raum aus dem Hostvektorraum und sie machen es erforderlich, dass der VMM Hostvektor-zu-Gastvektor-Abbildung für Interrupts durchführt.
17 veranschaulicht schematisch eine beispielhafte funktionale Beziehung zwischen externen Host-Interrupts und virtuellen, externen Gast-Interrupts, die von einem Verarbeitungssystem implementiert werden, das gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung arbeitet. In dem veranschaulichenden Beispiel in 17 ist der Host zuständig für Vorrichtung 1710A und erzeugt externe Interrupts mit Hostvektor X. Der Host-IDT 1720 ist derart eingerichtet, dass die Interrupt Service Routine (ISR) für Vorrichtungstreiber 1730A mit Hostvektor X wie normal angeschlossen ist. VMM emuliert (über Vorrichtung 1710A) virtuelle Vorrichtung 1710C in Software, die virtuelle Interrupts zu der VM erzeugt mit gasterwartetem Vektor P. Vorrichtung 1710B wird einer VM 1740 zugewiesen und erzeugt externe Interrupts mit Hostvektor Y. Der Host-IDT 1720 ist programmiert, die VMM-Interruptserviceroutine (ISR) für zugewiesene Vorrichtungen für Vektor Y zu verbinden und der VMM-Handler injiziert virtuelle Interrupts mit Gastvektor Q zu der VM 1740. Das Gastbetriebssystem programmiert den Gast, so dass dieser entsprechende Gasttreiber-ISR mit Vektoren P und Q verbindet.
Zum Durchführen der Interruptvirtualisierung kann VMM die physischen Interrupts und die verschiedenen Interrupt-Steuereinrichtungen in der Plattform übernehmen. VMM-Steuerung von physischen Interrupts kann durch die Hoststeuereinstellungen der „externes Interrupt-Exiting“ VM-Ausführungssteuerung aktiviert werden. Zur Übernahme der Zuständigkeit über die Plattforminterruptsteuereinrichtungen kann der VMM die virtuellen Interrupsteuereinrichtungsvorrichtungen den virtuellen Maschinen gegenüber exponieren und Gastzugriff auf die Plattforminterruptsteuereinrichtunen einschränken.
In gewissen Implementierungen kann ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, eine oder mehrere der folgenden Arten externer Interruptsteuermechanismen unterstützen: Programmierbare Interruptsteutereinrichtungen (PIC), fortgeschrittene programmierbare Interruptsteuereinrichtungen (APIC) und meldungssignalisierte Interrupts (MSI).
Eine PIC-befähigte Plattformimplementierung kann duale 8259 Interruptsteuereinrichtungen, die als Master- und Slave-Steuereinrichtungen kaskadiert sind, unterstützen. Sie können bis zu 15 mögliche Interrupteingaben unterstützen. Die 8259 Steuereinrichtungen sind durch Initialisierungsbefehlswörter (ICWx) und Operationsbefehlswörter (OCWx), auf die über spezifische I/O-Ports zugegriffen wird, programmiert. Die diversen Interruptlinienzustände werden in dem PIC über Interruptanforderungen, Interruptserviceroutinen und Interruptmaskenregister erfasst. Gastzugriff auf die PIC I/O-Ports kann durch Aktivieren von I/O-Bitmaps in der gaststeuernden VMCS (activate-I/O-Bitmap Bit in VM-Ausführungssteuerfeld auf 1 gesetzt) eingeschränkt werten und auf die physischen I/O-Bitmapadressen auf gültige Bitmapregionen weisen. Bits, die den PIC I/O-Ports entsprechen, können freigegeben werden, um einen VM-Exit bei Gastzugriff auf diese Ports zu veranlassen.
Falls der VMM den direkten Zugriff auf I/O-Ports von einem Gast nicht unterstützt, kann er das unconditional-I/O-exiting in dem VM-Ausführungssteuerfeld stattdessen auf Aktivieren von I/O-Bitmaps setzen. Das Feld Exitgrund in den VM-Exitinformationen erlaubt die Identifikation von VM-Exits aufgrund von I/O-Zugriff und kann eine Exitqualifikation bereitstellen, um Details über die Gast-I/O-Operation, die den VM-Exit verursachte, zu identifizieren.
In diversen veranschaulichenden Beispielen kann die VMM-PIC-Virtualisierung die Plattform-PIC-Funktionalität emulieren, einschließlich Interruptpriorität, Maske, Anforderung und Servicezustände und spezifische gastprogrammierten Modi der PIC-Operation.
Während das Standard-PIC für Verwendung in Uniprozessorsystemen vorgesehen ist, kann APIC entweder in Uniprozessor- oder Multiprozessorsystemen verwendet werden. APIC-basierte Interruptsteuerung umfasst zwei physische Komponenten: die Interruptakzeptanzeinheit (Local APIC), die mit dem Prozessor integriert ist, und die Interruptzustelleinheit (I/O APIC), die Teil des I/O-Untersystems ist. APIC-Virtualisierung umfasst das Schützen der lokalen und I/O-APICs der Plattform und deren Emulieren für den Gast.
Die lokale APIC ist für die lokalen Interruptquellen, Interruptakzeptanz, Ausgeben von Interrupts an den logischen Prozessor und das Erzeugen von Interprozessorinterrupts verantwortlich. Software interagiert mit der lokalen APIC durch Lesen und Schreiben ihrer speicherabgebildeten Register, die sich innerhalb einer 4-KByte nicht zwischengespeicherten Speicherregion mit Basisadresse, die in dem IA32_APIC_BASE MSR gespeichert ist, befindet. Da die lokalen APIC-Register speicherabgebildet sind, kann der VMM Speichervirtualisierungstechniken (wie etwa Speichertabellenvirtualisierung) verwenden, um Gastzugriffe auf den Pageframe, der die virtuellen lokalen APIC-Register hostet, aufzufangen.
Lokale APIC-Virtualisierung in dem VMM kann die diversen lokalen APIC-Operationen und Register emulieren, wie etwa: APIC-Identifikation/Formatregister, die lokale Vektortabelle (LVT), das Interruptbefehlsregister (ICR), Interruptauffangregister (TMR, IRR und ISR), Aufgaben- und Prozessorprioritätsregister (TPR, PPR), das EOI-Register und das APIC-Timerregister. Da lokale APICs nicht dafür ausgelegt sind, mit nicht-spezifischen EOI zu arbeiten, kann lokale APIC-Emulation auch das Senden von EOI an die virtuellen I/O APICs des Gastes für Ebenen-ausgelöste virtuelle Interrupts emulieren.
Eine lokale APIC erlaubt Interruptmaskierung auf zwei Ebenen: Maskenbit in dem lokalen Vektortabelleneintrag für lokale Interrupts und Anheben der Prozessorpriorität durch die TPR-Register zum Maskieren externer Interrupts mit niedrigerer Priorität. Der VMM kann, zusätzlich zu dem Unterbrechbarkeitszustand (wenn APIC-geroutete externe virtuelle Interrupts an eine Gast-VM injiziert werden), diese virtuellen lokalen APIC-Maskeneinstellungen als von dem Gast programmiert verstehen.
VMX stellt mehrere Funktionen bereit, die dem VMM helfen, die lokale APIC zu virtualisieren. Diese folgenden Funktionen erlauben vielen Gast-TPR-Zugriffen (ausschließlich unter Verwendung von CR8) ohne VM-Exits zu dem VMM aufzutreten:
Die VMCS enthält ein „virtuelles APIC-Adressen“-Feld. Dieses 64-Bit-Feld ist die physische Adresse der virtuellen 4-KByte APIC-Seite (4-KByte ausgerichtet). Die virtuelle APIC-Seite enthält einen TPR-Schatten, auf den durch die MOV CR8 Anweisung zugegriffen wird. Der TPR-Schatten umfasst Bits 7:4 in Byte 80H der virtuellen APIC-Seite.
Der TPR-Schwellenwert: Bits 3:0 dieses 32-Bit-Feldes bestimmen den Schwellenwert unter den der TPR-Schatten nicht fallen kann. Nach einer Ausführung von MOV CR8, der den TPR-Schatten unter diesen Wert reduziert, tritt ein VM-Exit auf.
Das prozessorbasierte VM-Ausführungssteuerfeld enthält ein „use TPR shadow“ Bit und ein „CR8-store exiting“ Bit. Falls die „use TPR shadow“ VM-Ausführungssteuerung 1 ist und die „CR8-store exiting“ VM-Ausführungssteuerung 0 ist, dann liest ein MOV von CR8 von dem TPR-Schatten. Falls die „CR8-store exiting“ VM-Ausführungssteuerung 1 ist, dann veranlasst MOV von CR8 einen VM-Exit; die „use TPR shadow“ VM-Ausführungssteuerung wird in diesem Fall ignoriert.
Das prozessorbasierte VM-Ausführungssteuerfeld enthält ein „CR8-load exiting“ Bit. Falls die „use TPR shadow“ VM-Ausführungssteuerung festgelegt ist und die „CR8-load exiting“ VM-Ausführungssteuerung frei ist, dann schreibt MOV zu CR8 zu dem „TPR shadow“. Nach diesem Schreibvorgang tritt ein VM-Exit ein, falls der geschriebene Wert unter dem TPR-Schwellenwert liegt. Falls die „CR8-load exiting“ VM-Ausführungssteuerung festgelegt ist, dann veranlasst MOV zu CR8 einen VM-Exit; die „use TPR shadow“ VM-Ausführungssteuerung wird in diesem Fall ignoriert.
Wie hierin vorstehend erwähnt, kann in bestimmten Implementierungen ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, I/O-APIC-Virtualisierung unterstützen. Die I/O-APIC-Register können zu einer 1 MByte-Region abgebildet werden, wo jeder I/O-APIC einem 4K-Adressenfenster innerhalb dieses Bereichs zugewiesen ist. Der VMM kann physische Speichervirtualisierung nutzen, um Gastzugriffe zu den virtuellen I/O-APIC speicherabgebildeten Registern aufzufangen. Die I/O-APIC-Virtualisierung kann die diversen I/O-APIC-Operationen und Register, wie etwa Identifikations-/Versionsregister, indirekte I/O-Zugriffsregister, EOI-Register und die I/O-Umleitungstabelle, emulieren. I/O-APIC-Virtualisierung kann auch diverse Umleitungstabelleneintragseinstellungen emulieren, wie etwa Zustellmodus, Zielmodus, Zustellstatus, Polarität, Maskierung und von dem Gast programmierten Modus auslösen und den Fern-IRR-Zustand auf Gast-EOI-Schreibvorgängen zu verschiedenen virtuellen lokalen APICs verfolgen.
Wie hierin vorstehend erwähnt, kann in bestimmten Implementierungen ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, meldungssignalisierte Interrupt (MSI) Virtualisierung unterstützen.
Die PCI Local Bus Specification (Rev. 2.2) führt das Konzept meldungssignalisierter Interrupts (Message Signaled Interrupts; MSI) vor. MSI befähigt PCI-Vorrichtungen einen Dienst durch Schreiben einer systemspezifischen Meldung an eine systemspezifische Adresse anzufordern. Die Transaktionsadresse legt das Meldungsziel fest, während die Transaktionsdaten den Interruptvektor, den Auslösermodus und den Zustellmodus festlegen. Von Systemsoftware wird erwartet, dass sie die Meldungsdaten und Adresse während der MSI-Vorrichtungskonfiguration konfiguriert, wobei sie eine oder mehrere nicht-geteilte Meldungen an MSI-fähige Vorrichtungen zuweist. Obwohl MSI für herkömmliche PCI-Vorrichtungen optional ist, ist es der bevorzugte Interruptmechanismus für PCI-Express-Vorrichtungen.
Da die MSI-Adresse und -daten durch PCI-Konfigurationsraum konfiguriert werden kann der VMM zum Steuern dieser physischen Interrupts die Zuständigkeit des PCI-Konfigurationsraums übernehmen. Dies ermöglicht es dem VMM die Gastkonfiguration der Mitteilungsadresse und Daten für MSI-fähige virtuelle und zugewiesene Gastvorrichtungen zu erfassen. PCI-Konfigurationstransaktionen auf PC-kompatiblen Systemen werden von Software durch den Standard CONFIG_ADDRESS/CONFIG_DATA Registermechanismus (CFCH/CF8H Ports), wie in der PCI Local Bus Specification definiert, oder dem Enhanced Flat Memory-Mapped (MEMCFG) Konfigurationsmechanismus, wie in der PCI - Express Base Specification (Rev. 1.0a.) definiert, erzeugt.
In einem veranschaulichendem Beispiel ist der VMM (oder das Hosting-OS in einem gehosteten VMM) bei Host-zuständigen I/O-Vorrichtungen für die unterbrechende Vorrichtung zuständig. In diesem Modell wird die Interrupt-Dienstroutine von dem VMM/Host-Treiber aufgerufen und bei ISR-Abschluss werden die entsprechenden Schreibsequenzen (TPR-Aktualisierungen, EOI usw.) in die jeweiligen Interruptsteuereinrichtungen wie normal durchgeführt. Falls der Arbeitsabschluss, der von dem Treiber angegeben wird, virtuelle Vorrichtungsaktivität impliziert, läuft der VMM in der virtuellen Vorrichtungsemulation. In Abhängigkeit von der Vorrichtungsklasse könnte die physische Vorrichtungsaktivität Aktivität von mehreren virtuellen Vorrichtungen, die über die Vorrichtung abgebildet werden, implizieren. Der VMM injiziert für jede betroffene, virtuelle Vorrichtung ein virtuelles externes Interruptereignis an die jeweiligen virtuellen Gastmaschinen. Der Gasttreiber interagiert mit der emulierten virtuellen Vorrichtung, um den virtuellen Interrupt zu verarbeiten. Die Interruptsteuereinrichtungsemulation in dem VMM unterstützt diverse Gastzugriffe auf die virtuelle Interruptsteuereinrichtung des VMM.
In einem anderen veranschaulichendem Beispiel verwendet der VMM für Gast-zugewiesene I/O-Vorrichtungen einen Softwareproxy oder er kann die physische Vorrichtung direkt zu der zugewiesenen VM abbilden. In beiden Fällen wird das Bedienen der Interruptbedingung auf der physischen Vorrichtung von dem Treiber initiiert, der innerhalb des Gast-VM läuft. Bei Hoststeuerung externer Interrupts, Interrupts von zugewiesenen physischen Vorrichtungen, weil die VM einen Exit zu dem VMM und ein Vectoring durch die Host-IDT zu dem registrierten VMM-Interrupt-Handler vornimmt. Um eine Zustellung anderer Plattforminterrupts mit niedriger Priorität freizugeben kann der VMM-Interrupt-Handler die Interruptquelle (für Ebenen-ausgelöste Interrupts) maskieren und die entsprechenden EOI-Schreibsequenzen ausgeben.
Wie hierin vorstehend erwähnt kann in bestimmten Implementierungen ein Verarbeitungssystem, das gemäß einem oder mehreren Aspekten der vorliegenden Offenbarung arbeitet, diverse Verfahren der Speichervirtualisierung unterstützen. Der VMM steuert physischen Speicher, um eine VM-Isolation sicherzustellen und um physische Gastadressen im physischen Gastadressenraum für Virtualisierung neu abzubilden. Speichervirtualisierung erlaubt es dem VMM Steuerung des physischen Speichers zu erzwingen und doch die Erwartung des Gast-OS einer Verwaltung der Speicheradressenübersetzung zu unterstützen.
Speichervirtualisierung kann Gastausführung in diversen Prozessorbetriebsmodi ermöglichen. Dies beinhaltet: geschützter Modus mit Paging, geschützter Modus ohne Paging, Realmodus und jedwede andere transitorische Ausführungsmodi. VMX erlaubt Gastbetrieb im geschützten Modus mit aktiviertem Paging und im virtuellen 8086 Modus (mit aktiviertem Paging) zum Unterstützen von Gastausführung im Realmodus. Gastausführung in transitorischen Betriebsmodi (wie etwa in Realmodus mit einem oder mehreren Segmentlimits größer als 64-KByte) können von dem VMM emuliert werden.
Da VMX-Operation Prozessorausführung in geschütztem Modus mit Paging umfasst (durch feste CR0 und CR4 Bits), kann der VMM Pagingstrukturen nutzen, um Speichervirtualisierung zu unterstützen. Zum Unterstützen der Gast-Real-Modus-Ausführung, kann der VMM eine einfache Flat-Seiten-Tabelle für Gast-linear zu Host-physischer Adressenabbildung einrichten. Speichervirtualisierungsalgorithmen können auch andere Gastbetriebsbedingungen erfassen (wie etwa Gastdurchführung von A20M# Adressenmaskierung) erfassen, um die resultierenden, effektiven physischen 20-Bit Gastadressen abzubilden.
Speichervirtualisierung stellt Gastsoftware räumlich nahen physischen Gastadressenraum beginnend bei Null bereit und sich über die maximale Adresse erstreckend, die von der physischen Adressenbreite des virtuellen Gastprozessors unterstützt wird. Der VMM nutzt den physischen Gast, um physisches Adressenabbilden zum Lokalisieren aller oder von Teilen des physischen Gastadressenraums im Hostspeicher zu hosten. Der VMM ist für die Richtlinien und Algorithmen für dieses Abbilden verantwortlich, das die physische Speicherkarte des Hostsystems und die virtualisierte physische Speicherkarte, die einem Gast von dem VMM eröffnet wird, berücksichtigen kann. Der Speichervirtualisierungsalgorithmus muss diverse Gastspeicherverwendungen ermöglichen (wie etwa: DRAM-Zugriff, Zugriff auf speicherabgebildete Register virtueller Vorrichtungen oder Kernlogikfunktionen usw.).
In einem veranschaulichendem Beispiel muss der VMM, zum Unterstützen des Gast-DRAM-Zugriffs, DRAM-gesicherte physische Gastadressen zu Host-DRAM-Regionen abbilden. Der VMM macht es auch erforderlich, dass das Gast-zu-Host-Speicherabbilden auf Seitengranularität erfolgt.
In einem anderen veranschaulichendem Beispiel können virtuelle Vorrichtungen (I/O-Vorrichtungen oder Plattformkernlogik), die von dem VMM emuliert werden, spezifische Regionen in dem physischen Gastadressenraum beanspruchen, um speicherabgebildete Register zu lokalisieren. Gastzugriff auf diese virtuellen Register können konfiguriert sein, um Seitenfehler-induzierte VM-Exits durch Markieren dieser Regionen als immer nicht vorhanden verursachen. Der VMM kann diese VM-Exits durch Abrufen eines entsprechenden virtuellen Vorrichtungsemulationscodes abrufen.
In bestimmten Implementierungen kann es der Software erlaubt werden die Gastseitentabellenhierarchie ohne das Verursachen von Traps zu dem VMM frei zu modifizieren. Daher könnte die aktive Seitentabellenhierarchie nicht immer mit der Gasthierarchie übereinstimmen.
Um zuzulassen, dass die Gastsoftware frei auf Seitenverzeichnisse und Seitentabellen zugreift, können Traps festgelegt werden, so dass sie bei CR3 Zugriffen und Ausführungen von INVLPG auftreten. Sie treten wie notwendig auch auf, um sicherzustellen, dass Gastmodifikationen zu den Übersetzungsstrukturen tatsächlich wirksam werden. Die Softwaremechanismen zum Unterstützen dieses Ansatzes werden kollektiv als virtuelle TLB bezeichnet, da sie die Funktionalität des physischen TLB des Prozessors emulieren.
Obwohl die Seitentabellenhierarchie die Beziehung zwischen physischer und linearer Adresse definiert, steuert sie nicht direkt die Adressenübersetzung jedes Speicherzugriffs. Stattdessen kann die Übersetzung von dem TLB gesteuert werden, der gelegentlich von dem Prozessor mit Übersetzungen gefüllt wird, die aus der Seitentabellenhierarchie abgeleitet werden. Bei einem virtuellen TLB steuert die Seitentabellenhierarchie, die von der Gastsoftware (konkreter: dem Gastbetriebssystem) hergestellt wird, die Übersetzung weder direkt, noch indirekt. Stattdessen wird die Übersetzung von dem Prozessor (durch den TLB) und von dem VMM (durch eine Seitentabellenhierarchie, die dieser aufrecht erhält) gesteuert.
In einem veranschaulichendem Beispiel kann der VMM eine alternative Seitentabellenhierarchie aufrecht erhalten, die effektiv Übersetzungen, die von der Hierarchie, die von der Gastsoftware aufrecht erhalten wird, abgeleitet werden, zwischenspeichert. Die erstgenannte lässt sich als die aktive Seitentabellenhierarchie bezeichnen (da auf sie durch CR3 Bezug genommen wird und sie von dem Prozessor zum Laden seiner TLB verwendet werden kann) und die letztgenannte lässt sich als Gastseitentabellenhierarchie bezeichnen (da sie von der Gastsoftware aufrechterhalten wird). Die Einträge in der aktiven Hierarchie können die entsprechenden Einträge in der Gasthierarchie auf manche Weisen wiedergeben und sich auf andere unterscheiden.
18 veranschaulicht schematisch ein beispielhaftes Verfahren zum Implementieren von Speichervirtualisierung unter Verwendung eines TLB gemäß einem oder mehreren Aspekt/en der vorliegenden Offenbarung. Wie vorstehend hierin angesprochen erhält der VMM eine aktive Seitentabellenhierarchie 1810A für jede virtuelle Maschine, die sie unterstützt, aufrecht. Er erhält auch für jede Maschine Werte aufrecht, die die Maschine zum Steuern der Register CR0, CR2, CR3 und CR4 (sie steuern die Adressenübersetzung) erwartet. Diese Werte werden als Gaststeuerregister bezeichnet. Generell wählt der VMM den physischen Adressenraum aus, der der Gastsoftware zugewiesen wird. Der Begriff „Gastadresse“ bezieht sich auf eine Adresse, die von Gastsoftware in dem Gast CR3 1820B, in einem Gastseitenverzeichnis 1830B (als eine Seitentabellenbasisadresse oder eine Seitenbasisadresse) oder in einer Gastseitentabelle 1840B (als eine Seitenbasisadresse) installiert ist. Obwohl die Gastsoftware diese als spezifische physischen Adressen betrachtet, kann der VMM sie unterschiedlich abbilden. Wenn Gastsoftware Paging zuerst befähigt, erzeugt der VMM ein ausgerichtetes aktives 4-KByte Seitenverzeichnis, das ungültig ist (alle Einträge sind als nicht vorhanden markiert). Dieses ungültige Verzeichnis ist analog zu einem leeren TLB.
Seitenfehler können aus einer Vielzahl von Gründen auftreten. In manchen Fällen alarmiert der Seitenfehler den VMM über eine Inkonsistenz zwischen der aktiven Seitentabellenhierarchie 1810A und der Gastseitentabellenhierarchie 1810B. In solchen Fällen kann der VMM die aktive Seitentabellenhierarchie 1810A aktualisieren und die fehlerbewirkende Anweisung erneut ausführen. In anderen Fällen sind die Hierarchien bereits konsistent und der Fehler sollte von dem Gastbetriebssystem bearbeitet werden. Der VMM kann dies entdecken und einen etablierten Mechanismus zum Benachrichtigen der Gastsoftware über einen Seitenfehler verwenden.
Während die vorliegende Offenbarung in Hinblick auf eine beschränkte Anzahl beispielhafter Implementierungen beschrieben wurde, wird der Fachmann verstehen, dass zahlreiche Modifikationen und Variationen davon möglich sind. Es ist beabsichtigt, dass die beigefügten Ansprüche alle diese Modifikationen und Variationen, die in den wahren Geist und Umfang dieser vorliegenden Offenbarung fallen, abdecken.
Ein Entwurf kann mehrere Phasen von Erzeugung zu Simulation zu Fabrikation durchlaufen. Daten, die einen Entwurf repräsentieren, können den Entwurf auf mehrere Weisen repräsentieren. Zunächst kann, wie es in Simulationen nützlich ist, die Hardware unter Verwendung einer Hardwarebeschreibungssprache oder einer anderen funktionalen Beschreibungssprache repräsentiert sein. Zusätzlich können ein Schaltungsebenenmodell mit Logik und/oder Transistor-Gates in manchen Phasen des Entwurfsprozesses produziert werden. Des Weiteren erreichen die meisten Entwürfe irgendwann ein Datenniveau, das das physische Platzieren diverser Vorrichtungen in dem Hardwaremodell repräsentiert. In dem Fall, in dem herkömmliche Halbleiterfabrikationstechniken verwendet werden, können die Daten, die das Hardwaremodell repräsentieren, die Daten sein, die das Vorhandensein oder das Fehlen diverser Merkmale auf unterschiedlichen Maskenschichten für Masken, die zum Herstellen der integrierten Schaltung verwendet werden, spezifizieren. In jeder Repräsentation des Entwurfs, können die Daten in jedweder Form eines maschinenlesbaren Mediums gespeichert werden. Ein Speicher oder ein magnetischer oder optischer Speicher, wie etwa eine Diskette, kann das maschinenlesbare Medium zum Speichern von Informationen sein, die über optische oder elektrische Wellen, die moduliert oder anderweitig zum Übertragen solcher Informationen erzeugt wurden, übertragen werden. Wenn eine elektrische Trägerwelle, die den Code oder Entwurf angibt oder trägt, übertragen wird, insoweit, als dass ein Kopieren, Puffern oder eine erneute Übertragung des elektrischen Signals durchgeführt wird, wird einen neue Kopie erstellt. Somit kann ein Kommunikationsanbieter oder ein Netzwerkanbieter einen Artikel, wie etwa Informationen, die in eine Trägerwelle kodiert sind und Techniken der beispielhaften Implementierungen der vorliegenden Offenbarung verkörpern, zumindest vorübergehend auf einem greifbaren, maschinenlesbaren Medium speichern.
Ein Modul bezieht sich, wie hierin verwendet, auf eine Kombination aus Hardware, Software und/oder Firmware. Ein Modul beinhaltet beispielsweise Hardware, wie einen Mikrocontroller, der einem nichttransitorischem Medium zum Speichern von Code, der dafür ausgelegt ist von dem Mikrocontroller ausgeführt zu werden, zugeordnet ist. Eine Bezugnahme auf ein Modul in einer beispielhaften Implementierung bezieht sich daher auf die Hardware, die konkret konfiguriert ist, den Code, der auf einem nicht-transitorischen Medium gehalten wird, zu erkennen und/oder auszuführen. Des Weiteren bezieht sich die Verwendung eines Moduls in einer anderen beispielhaften Implementierung auf das nicht-transitorische Medium einschließlich des Codes, das konkret dafür ausgelegt ist, von dem Mikrocontroller zum Durchführen vorbestimmter Operationen ausgeführt zu werden. Und wie sich daraus folgern lässt kann sich der Begriff Modul in noch einer anderen beispielhaften Implementierung (in diesem Beispiel) auf die Kombination des Mikrocontrollers und des nicht-transitorischen Mediums beziehen. Modulgrenzen, die als separat veranschaulicht sind, variieren üblicherweise häufig und können sich potenziell überschneiden.
Ein erstes und ein zweites Modul können zum Beispiel Hardware, Software, Firmware oder eine Kombination davon teilen, während sie potenziell manche unabhängige Hardware, Software oder Firmware zurückhalten. In einer beispielhaften Implementierung beinhaltet die Verwendung des Begriffs Logik Hardware, wie etwa Transistoren, Register oder andere Hardware, wie etwa programmierbare Logikvorrichtungen.
Die Verwendung der Formulierung „konfiguriert für“ in einer beispielhaften Implementierung bezieht sich auf das Anordnen, Zusammensetzten, Herstellen, zum Verkauf anbieten, Importieren und/oder Entwerfen einer Vorrichtung, Hardware, Logik oder eines Elements zum Durchführen einer zugewiesenen oder festgelegten Aufgabe. In diesem Beispiel ist eine Vorrichtung oder ein Element davon, das nicht in Betrieb ist, immer noch „konfiguriertfür“ das Durchführen einer zugewiesenen Aufgaben, wenn sie zum Durchführen der zugewiesenen Aufgabe entworfen, gekoppelt und/oder verbunden ist. Als rein veranschaulichendes Beispiel könnte ein Logikgate eine 0 oder 1 während der Operation bereitstellen. Aber ein Logikgate, das „konfiguriert für“ das Bereitstellen eines Befähigungssignals an einen Taktgeber ist, beinhaltet nicht jedes potenzielle Logikgate, das eine 1 oder 0 bereitstellen kann. Stattdessen ist das Logikgate eines, das auf irgendeine Weise verbunden ist und während der Operation die 1 oder 0 Ausgabe den Taktgeber befähigt. Beachten Sie noch einmal, dass die Verwendung des Begriffs „konfiguriertfür“ keine Operation erforderlich macht; stattdessen gilt der Fokus dem latenten Zustand einer Vorrichtung, Hardware und/oder eines Elements, wenn die Vorrichtung, Hardware und/oder das Element in dem latenten Zustand dafür entworfen wurde, eine bestimmte Aufgabe durchzuführen, wenn die Vorrichtung, Hardware und/oder das Element sich in Betrieb befindet.
Des Weiteren bezieht sich die Verwendung der Formulierungen „zu“, „fähig/dazu in der Lage“ und oder „betreibbar für“ in einer beispielhaften Implementierung auf eine gewisse Vorrichtung, Logik, Hardware und/oder ein Element, das derart entworfen ist, dass die Verwendung der Vorrichtung, Logik, Hardware und/oder des Elements auf eine spezifizierte Weise befähigt ist. Beachten Sie wie vorstehend, dass die Verwendung von zu, fähig zu/in der Lage oder betreibbar für in einer beispielhaften Implementierung sich auf den latenten Zustand einer Vorrichtung, Logik, Hardware und/oder eines Elements bezieht, in dem die Vorrichtung, Logik, Hardware und/oder das Element sich nicht in Betrieb befinden, aber derart entworfen wurden, dass sie zur Verwendung einer Vorrichtung auf eine spezifizierte Weise befähigen.
Ein Wert, wie hierin verwendet, beinhaltet jedwede bekannte Repräsentation einer Zahl, eines Zustands, eines Logikzustands oder eines binären Logikzustands. Die Verwendung von Logikebenen, logischen Werten oder Logikwerten wird häufig auch als 1er und 0en bezeichnet, was einfach binäre Logikzustände repräsentiert. Eine 1 bezieht sich zum Beispiel auf eine hohe Logikebene und 0 bezieht sich auf eine niedrige Logikebene. In einer beispielhaften Implementierung kann eine Speicherzelle, wie ein Transistor oder eine Flashzelle, dazu fähig sein, einen einzelnen Logikwert oder mehrere Logikwerte zu halten. Andere Repräsentationen von Werten in Computersystemen wurden jedoch verwendet. Die Dezimalzahl Zehn kann zum Beispiel auch als ein binärer Wert von 1010 und ein hexadezimaler Buchstabe A repräsentiert sein. Ein Wert beinhaltet daher jedwede Repräsentation von Informationen, die fähig sind, in einem Computersystem gehalten zu werden.
Des Weiteren können Zustände von Werten oder Teilen von Werten repräsentiert sein. Ein erster Wert, wie etwa ein logischer, kann zum Beispiel einen Standard- oder Anfangszustand repräsentieren, während ein zweiter Wert, wie etwa eine logische Null, einen Nicht-Standard-Zustand repräsentieren kann. Zusätzlich können die Begriffe „zurücksetzen“ und „einstellen/festlegen/setzen“ sich in einer beispielhaften Implementierung auf einen Standard- und einen aktualisierten Wert bzw. Zustand beziehen. Ein Standardwert beinhaltet zum Beispiel potenziell einen hohen Logikwert, d. h. Zurücksetzen, während ein aktualisierter Wert potenziell einen niedrigen Logikwert, d. h. Festlegung, beinhaltet. Beachten Sie, dass jedwede Kombination von Werten zum Repräsentieren jedweder Anzahl von Zuständen verwendet werden kann.
Die beispielhaften Implementierungen von Verfahren, Hardware, Software, Firmware oder Code, die vorstehend dargelegt wurden, können über Anweisungen oder Code implementiert werden, die/der auf einem maschinenzugänglichem, maschinenlesbarem, computerzugänglichem oder computerlesbarem Medium gespeichert sind/ist, die/der von einem Verarbeitungselement ausführbar ist/sind, implementiert sein. Ein nicht-transitorisches maschinenzugängliches/- lesbares Medium beinhaltet jedweden Mechanismus, der Informationen in einer von einer Maschine, wie etwa einem Computer oder einem Elektroniksystem, lesbar ist, bereitstellt (d. h. speichert und/oder überträgt). Ein nicht-transitorisches, maschinenlesbares Medium beinhaltet zum Beispiel Direktzugriffsspeicher (RAM), wie etwa statischen RAM (SRAM) oder dynamischen RAM (DRAM); ROM; magnetische oder optische Speichermedien; Flashspeichervorrichtungen; elektrische Speichervorrichtungen; optische Speichervorrichtungen; akustische Speichervorrichtungen; andere Formen von Speichervorrichtungen zum Halten von Informationen, die von transitorischen (sich ausbreitenden) Signalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale); usw. empfangen werden, die von den nicht-transitorischen Medien, die möglicherweise Informationen davon empfangen, zu unterscheiden sind.
Anweisungen, die zum Programmieren von Logik zum Durchführen beispielhafter Implementierungen der vorliegenden Offenbarung verwendet werden, können innerhalb eines Speichers in dem System gespeichert werden, wie etwa DRAM, Cache, Flash-Speicher oder einem anderen Speicher. Des Weiteren können die Anweisungen über ein Netzwerk oder über andere computerlesbare Medien verbreitet werden. Ein maschinenlesbares Medium kann somit jedweden Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) lesbar ist, umfassen, ist aber nicht beschränkt auf Floppy-Disketten, optische Disketten, Compact Disks, Nur-Lese-Speicher (CD-ROMs) und magnetoptische Platten, Nur-Lese-Speicher (ROMs), Direktzugriffsspeicher (RAM), löschbar programmierbare Nur-Lese-Speicher (EPROM), elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROM), magnetische oder optische Karten, Flash-Speicher oder einen greifbaren, maschinenlesbaren Speicher, der für das Übertragen von Informationen über das Internet über elektrische, optische, akustische oder andere Formen sich ausbreitender Signale (z. B. Trägerwellen, Infrarotsignale, digitale Signale usw.). Dementsprechend umfasst das computerlesbare Medium jedwede Art von maschinenlesbarem Medium, das geeignet ist elektronische Anweisungen oder Informationen in einer Form, die von einer Maschine (z. B. einem Computer) lesbar ist, zu speichern oder zu übertragen.
Bezugnahmen in dieser Spezifikation auf „eine (einzelne) beispielhafte Implementierung“ oder „eine beispielhafte Implementierung“ bedeuten, dass ein bestimmtes Merkmal, eine Struktur oder Eigenschaft, das/die in Verbindung mit der beispielhaften Implementierung beschrieben wird, in mindestens einer beispielhaften Implementierung der vorliegenden Offenbarung enthalten ist. Somit bezieht sich das Auftreten der Formulierung „in einer beispielhaften Implementierung“ an unterschiedlichen Stellen in dieser Spezifikation nicht immer zwangsläufig auf die gleiche beispielhafte Implementierung. Des Weiteren können die bestimmten Merkmale, Strukturen oder Eigenschaften auf jedwede geeignete Weise in einer oder mehreren beispielhaften Implementierungen kombiniert werden.
In der vorstehenden Spezifikation wurde eine ausführliche Beschreibung unter Bezugnahme auf konkrete beispielhafte Beispielimplementierungen gegeben. Es ist jedoch offensichtlich, dass diverse Modifikationen und Veränderungen daran vorgenommen werden können, ohne dass von dem breiteren Geist und Umfang der vorliegenden Offenbarung, wie in den beigefügten Ansprüchen dargelegt, abgewichen werden würde. Die Spezifikation und Zeichnungen müssen dementsprechend in einem veranschaulichenden Sinne aufgefasst werden und nicht in einem einschränkenden Sinne. Des Weiteren bezieht sich die vorstehende Verwendung beispielhafter Implementierungen und einer anderweitig beispielhaften Sprache nicht zwangsläufig auf die gleichen beispielhaften Implementierungen oder das gleiche Beispiel, sondern sie können sich auf unterschiedliche und verschiedene beispielhafte Implementierungen sowie potenziell auch die gleiche beispielhafte Implementierung beziehen.

Claims

Verarbeitungsvorrichtung, umfassend: einen Prozessorkern; und eine Speichersteuereinrichtung, die zwischen dem Prozessorkern und einem Speicher verbunden ist, wobei der Prozessorkern das Folgende durchzuführen hat: Feststellen, dass eine Exit-Bedingung zum Übertragen von Ressourcensteuerung des Prozessorkerns von einem ersten virtuellen Maschinenmonitor (VMM) auf einen zweiten VMM aufgetreten ist; Feststellen, dass ein Steuerverbindungszeiger einer virtuellen Maschine Steuerstruktur (Virtual Machine Control Structure; VMCS) für den ersten VMM gültig ist; Feststellen, in Reaktion darauf, dass der Steuer-VMCS-Verbindungszeiger gültig ist, wenn ein Grund-Wert, der dem Steuer-VMCS-Verbindungszeiger entspricht, gesetzt ist; Feststellen, in Reaktion darauf, dass der Grund-Wert gesetzt ist, dass der Grund-Wert auf Null gesetzt ist; Feststellen, in Reaktion darauf, dass der Grund-Wert auf Null gesetzt ist, dass ein Ausnahme-Bit, das dem Grund-Wert entspricht, gesetzt ist; und Übertragen, in Reaktion darauf, dass das Ausnahme-Bit gesetzt ist, einer Steuerung einer Ressource von dem ersten VMM auf den zweiten VMM.
Verarbeitungsvorrichtung nach Anspruch 1, wobei der erste VMM in einem Nicht-Root-Modus arbeitet und der zweite VMM in dem Nicht-Root-Modus arbeitet.
Verarbeitungsvorrichtung nach Anspruch 1, wobei der Prozessorkern die Ressourcensteuerung von dem ersten VMM auf einen dritten VMM zu übertragen hat, in Reaktion darauf, dass: der Steuer-VMCS-Verbindungszeiger ungültig ist; der Grund-Wert nicht gesetzt ist; und/oder das Ausnahme-Bit nicht gesetzt ist.
Verarbeitungsvorrichtung nach Anspruch 3, wobei der erste VMM in einem Nicht-Root-Modus arbeitet und der dritte VMM in einem Root-Modus arbeitet.
Verarbeitungsvorrichtung nach Anspruch 1, wobei der Prozessorkern die Ressourcensteuerung, in Reaktion darauf, dass der Grund-Wert nicht auf Null gesetzt ist, von dem ersten VMM auf den zweiten VMM zu übertragen hat.
Verarbeitungsvorrichtung nach Anspruch 1, wobei die VMCS umfasst: ein Gastfeld; ein Hostfeld; Steuerfelder; ein VM-Eingangsfeld; und ein VM-Exitfeld, und die Steuerfelder umfassen: einen VMCS-Verbindungszeiger; einen Zustands-VMCS-Verbindungszeiger; einen Steuer-VMCS-Verbindungszeiger; eine Grund-Bitmap; und ein Ausnahme-Bitmap.
Verarbeitungsvorrichtung nach Anspruch 6, wobei der Prozessorkern: in das Gastfeld einen ersten Prozessorzustand zu speichern hat, auf den von dem Zustands-VMCS-Verbindungszeiger gewiesen wird; in das Hostfeld einen zweiten Prozessorzustand zu laden hat, auf den von dem Zustands-VMCS-Verbindungszeiger gewiesen wird; in die Steuerfelder Daten aus Steuerfeldern eines zweiten VMCS, auf den von dem Steuer-VMCS-Verbindungszeiger gewiesen wird, zu kopieren hat; und ein Gültigkeits-Bit an einem VM-Eingangs-Unterbrechungsinformationsfeld des VM-Eingangsfelds freizugeben hat.
Verarbeitungsvorrichtung nach Anspruch 6, wobei der Prozessorkern: den Zustands-VMCS-Verbindungszeiger auf einen ersten vordefinierten festen Wert festzulegen hat, um den Zustands-VMCS-Verbindungszeiger zu deaktivieren; den Steuer-VMCS-Verbindungszeiger auf einen zweiten vordefinierten festen Wert festzulegen hat, um den Steuer-VMCS-Verbindungszeiger zu deaktivieren; die Grund-Bitmap auf einen vordefinierten festen Wert festzulegen hat, um die Grund-Bitmap zu deaktivieren; und die Ausnahme-Bitmap auf Null zu setzen hat, um die Ausnahme-Bitmap zu deaktivieren.
Verarbeitungsvorrichtung nach Anspruch 1, wobei der Prozessorkern: festzustellen hat, dass der zweite VMM ein Ereignis, das der Exit-Bedingung zugeordnet ist, abgeschlossen hat; und die Ressourcensteuerung von dem ersten VMM auf einen dritten VMM, der in einem Root-Modus arbeitet, zu übertragen hat.
Verarbeitungsvorrichtung, umfassend: einen Prozessorkern; und eine Speichersteuereinrichtung, die zwischen dem Prozessorkern und einem Speicher verbunden ist, wobei der Prozessorkern das Folgende in Reaktion auf das Empfangen einer Wiederaufnahmeanweisung von einem ersten virtuellen Maschinenmonitor (VMM) durchzuführen hat: Festlegen von Datenfeldern für eine erste virtuelle Maschine Steuerstruktur (Virtual Machine Control Structure; VMCS) eines zweiten VMM; Festlegen, durch den zweiten VMM, eines virtuelle Maschine (VM) Exit-Felds der ersten VMCS; Ausführen, durch den zweiten VMM, der Wiederaufnahmeanweisung; Verifizieren, dass Daten, die der Wiederaufnahmeanweisung zugeordnet sind, gültig sind; Verifizieren, in Reaktion darauf, dass die Daten, die der Wiederaufnahmeanweisung zugeordnet sind, gültig sind, einer Gültigkeit des VM-Exitfelds; und Übertragen, in Reaktion darauf, dass das VM-Exitfeld gültig ist, einer Steuerung einer Ressource von dem ersten VMM auf einen dritten VMM.
Verarbeitungsvorrichtung nach Anspruch 10, wobei: die erste VMCS umfasst: ein Gastfeld; ein Hostfeld; Steuerfelder; ein VM-Eingangsfeld; und ein VM-Exitfeld, und die Steuerfelder umfassen: einen VMCS-Verbindungszeiger; einen Zustands-VMCS-Verbindungszeiger; einen Steuer-VMCS-Verbindungszeiger; eine Grund-Bitmap; und eine Ausnahme-Bitmap.
Verarbeitungsvorrichtung nach Anspruch 11, wobei der Prozessorkern zum Festlegen der Datenfelder ferner: Daten von einem Gastfeld einer zweiten VMCS zu dem Gastfeld der ersten VMCS zu kopieren hat; Daten von einem Hostfeld einer dritten VMCS zu dem Hostfeld der ersten VMCS zu kopieren hat; Daten von den Steuerfeldern der zweiten VMCS und der dritten VMCS zusammenzufügen hat; die zusammengefügten Daten zu den Steuerfeldern der ersten VMCS zu kopieren hat; und Daten von einem VM-Eingangsfeld der zweiten VMCS zu dem VM Eingangsfeld der ersten VMCS zu kopieren hat.
Verarbeitungsvorrichtung nach Anspruch 10, wobei der Prozessorkern zum Festlegen des VM-Exitfelds ferner das VM-Exitfeld mit einem Steuer-VMCS-Verbindungszeiger mit einer Adresse einer zweiten VMCS, einem Zustands-VMCS-Verbindungszeiger mit der Adresse einer dritten VMCS und eine Grund-Bitmap festzulegen hat.
Verarbeitungsvorrichtung nach Anspruch 10, wobei der Prozessorkern das Steuern der Ressource an dem ersten VMM in Reaktion darauf aufrecht zu erhalten hat, dass: Daten, die der Wiederaufnahmeanweisung zugeordnet sind, ungültig sind; und/oder das VM-Exitfeld ungültig ist.
Verarbeitungsvorrichtung nach Anspruch 10, wobei: der erste VMM in einem Nicht-Root-Modus arbeitet; der zweite VMM in einem Root-Modus arbeitet; und der dritte VMM in dem Nicht-Root-Modus arbeitet.
Verfahren, umfassend: Feststellen, dass eine Exit-Bedingung zum Übertragen der Steuerung einer Ressource für einen Prozessorkern von einem ersten virtuellen Maschinenmonitor (VMM) zu einem zweiten VMM aufgetreten ist; Feststellen, dass ein Steuerverbindungszeiger einer virtuellen Maschine Steuerstruktur (Virtual Machine Control Structure; VMCS) gültig ist; Feststellen, in Reaktion darauf, dass der Steuer-VMCS-Verbindungszeiger gültig ist, dass ein Grund-Wert, der dem Steuer-VMCS-Verbindungszeiger entspricht, gesetzt ist; Feststellen, in Reaktion darauf, dass der Grund-Wert gesetzt ist, dass der Grund-Wert auf Null gesetzt ist; Feststellen, in Reaktion darauf, dass der Grund-Wert auf Null gesetzt ist, dass ein Ausnahme-Bit, das einem Spezifikationsausnahmetyp eines Grund-Werts entspricht, gesetzt ist; und Übertragen, in Reaktion darauf, dass das Ausnahme-Bit gesetzt ist, einer Steuerung der Ressource von dem ersten VMM zu dem zweiten VMM.
Verfahren nach Anspruch 16, wobei der erste VMM in einem Nicht-Root-Modus arbeitet und der zweite VMM in dem Nicht-Root-Modus arbeitet.
Verfahren nach Anspruch 16, ferner das Übertragen der Steuerung der Ressource von dem ersten VMM auf einen dritten VMM umfassend, in Reaktion darauf, dass: der Steuer-VMCS-Verbindungszeiger ungültig ist; der Grund-Wert nicht gesetzt ist; und/oder das Ausnahme-Bit nicht gesetzt ist.
Verfahren nach Anspruch 18, wobei der erste VMM in einem Nicht-Root-Modus arbeitet und der dritte VMM in einem Root-Modus arbeitet.
Verfahren nach Anspruch 16, ferner umfassend das Übertragen, in Reaktion darauf, dass der Grund-Wert nicht auf Null gesetzt ist, der Steuerung der Ressource von dem ersten VMM auf den zweiten VMM.