DE112016004297T5 - Technologien für mehrstufige virtualisierung - Google Patents

Technologien für mehrstufige virtualisierung Download PDF

Info

Publication number
DE112016004297T5
DE112016004297T5 DE112016004297.3T DE112016004297T DE112016004297T5 DE 112016004297 T5 DE112016004297 T5 DE 112016004297T5 DE 112016004297 T DE112016004297 T DE 112016004297T DE 112016004297 T5 DE112016004297 T5 DE 112016004297T5
Authority
DE
Germany
Prior art keywords
root
virtualization
hypervisor
root hypervisor
computing device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112016004297.3T
Other languages
English (en)
Inventor
Jun Nakajima
Asit K. Mallick
Harshawardhan Vipat
Madhukar Tallam
Manohar R. Castelino
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112016004297T5 publication Critical patent/DE112016004297T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation

Abstract

Technologien für mehrstufige Virtualisierung beinhalten eine Rechenvorrichtung mit einem Prozessor, der einen Root-Virtualisierungsmodus und einen Non-Root-Virtualisierungsmodus unterstützt. Ein Non-Root-Hypervisor stellt fest, ob er unter der Kontrolle eines Root-Hypervisors ausgeführt wird; falls ja, registriert er beim Root-Hypervisor einen Callback-Handler und Auslösebedingungen. Der Non-Root-Hypervisor hostet eine oder mehrere virtuelle Maschinen. In Reaktion auf einen Ausgang einer virtuellen Maschine stellt der Root-Hypervisor fest, ob für den Grund des Ausgangs der virtuellen Maschine ein Callback-Handler registriert wurde; falls ja, überprüft er die Auslösebedingungen im Zusammenhang mit dem Callback-Handler. Wenn die Auslösebedingungen erfüllt sind, aktiviert der Root-Hypervisor den Callback-Handler. Der Callback-Handler kann ein virtuelles Virtualisierungsunterstützungsobjekt auf der Grundlage von Veränderungen aktualisieren, die vom Root-Hypervisor an einem Virtualisierungsunterstützungsobjekt vorgenommen wurden. Der Root-Hypervisor kann den Callback-Handler im Non-Root-Virtualisierungsmodus aktivieren. Weitere Ausführungsformen werden beschrieben und beansprucht.

Description

  • QUERVERWEIS AUF EINE VERWANDTE US-PATENTANMELDUNG
  • Die vorliegende Erfindung beansprucht Priorität gegenüber der US-Patentanmeldung mit der Seriennr. 14/866,187, Titel „TECHNOLOGIES FOR MULTI-LEVEL VIRTUALIZATION“, die am 25. September 2015 eingereicht wurde.
  • HINTERGRUND DER ERFINDUNG
  • Typische Computerprozessoren beinhalten Hardwareunterstützung für Virtualisierungsoperationen. Softwarevirtualisierung beinhaltet ein transparentes Ausführen eines oder mehrerer Gastbetriebssysteme aus dem Inneren eines Gastgeberbetriebssystems, eines Hypervisors oder eines Virtual-Machine-Monitors (VMM). Zu den Merkmalen von Hardwarevirtualisierung können ein Modell mit erweiterten Befugnisstufen, hardwareassistierte Unterstützung für das Adressieren virtueller Speicher, Unterstützung für erweiterte Speicherberechtigungen und weitere Virtualisierungsmerkmale gehören.
  • Bestimmte Rechenvorrichtungen beinhalten einen dünnen Hypervisor zur Überwachung oder Überprüfung der Integrität des Gastgeberbetriebssystems. Rechensysteme, die einen dünnen Hypervisor beinhalten, können jedoch Schwierigkeiten haben, zusätzliche Hypervisoren oder VMMs auszuführen, etwa VMMs, die vom Gastgeberbetriebssystem gehostet werden, während die Sicherheit aufrechterhalten bleibt. Beispielsweise haben gehostete VMMs in der Regel privilegierte Komponenten im Gastgeberbetriebssystem, die dessen Sicherheit potenziell beeinträchtigen können. Um die Sicherheitsassertionen des Gastgeberbetriebssystems zu schützen, kann ein dünner Hypervisor alternativ veranlassen, dass Hardware-Virtualisierungseigenschaften gehosteten VMMs nicht zur Verfügung stehen und/oder die Hardwareeigenschaften für den gehosteten VMM virtualisieren und den gehosteten VMM in einem genesteten und/oder deprivilegierten Modus ausführen.
  • In Systemen mit genesteter Virtualisierung virtualisiert der dünne Hypervisor jeden Ausgang einer virtuellen Maschine (VM), was dazu führen kann, dass zwischen dem dünnen Hypervisor und dem gehosteten VMM eine große Anzahl zusätzlicher VM existiert. Bestimmte von der Intel® Corporation hergestellte Prozessoren beinhalten Hardwareeigenschaften wie Virtual Machine Control Structure Shadowing (VMCS-Shadowing), die die Anzahl der VM-Ausgänge reduzieren kann. In diesen Ausführungsformen nimmt der dünne Hypervisor jedoch für jeden VM-Ausgang noch immer ein genestetes Verarbeiten des VM-Ausgangs vor.
  • Figurenliste
  • Die hierin beschriebenen Konzepte werden in den beiliegenden Figuren beispielhaft und nicht einschränkend abgebildet. Zur Einfachheit und Übersichtlichkeit der Darstellung sind die in den Figuren abgebildeten Elemente nicht notwendigerweise maßstäblich. Sofern dies als angemessen erachtet wurde, wurden Referenzbezeichnungen in den Figuren wiederholt, um korrespondierende oder analoge Elemente zu kennzeichnen.
    • 1 ist ein vereinfachtes Blockdiagramm von mindestens einer Ausführungsform einer Rechenvorrichtung für mehrstufige Virtualisierung;
    • 2 ist ein vereinfachtes Blockdiagramm von mindestens einer Ausführungsform einer Umgebung der Rechenvorrichtung aus 1;
    • 3 ist ein vereinfachtes Blockdiagramm von mindestens einer Ausführungsform einer Hypervisor-Umgebung, die von der Rechenvorrichtung aus den 1-2 gebildet werden kann;
    • 4 ist ein vereinfachtes Flussdiagramm von mindestens einer Ausführungsform eines Verfahrens zur Root-Virtualisierung, das von der Rechenvorrichtung aus den 1-3 ausgeführt werden kann;
    • 5 ist ein vereinfachtes Flussdiagramm mindestens einer Ausführungsform eines Verfahrens für das Verarbeiten des Ausgangs einer virtuellen Maschine, das von der Rechenvorrichtung aus den 1-3 ausgeführt werden kann;
    • 6 ist ein vereinfachtes Flussdiagramm von mindestens einer Ausführungsform eines Verfahrens zur Non-Root-Hypervisor-Paravirtualisierung, das von der Rechenvorrichtung aus den 1-3 ausgeführt werden kann; und
    • 7 ist ein vereinfachtes Flussdiagramm von mindestens einer Ausführungsform eines Verfahrens für Non-Root-Callback-Verarbeiten, das von der Rechenvorrichtung aus den 1-3 ausgeführt werden kann.
  • AUSFÜHRLICHE BESCHREIBUNG DER ZEICHNUNGEN
  • Während die Konzepte der vorliegenden Offenbarung verschiedenen Modifikationen und alternativen Formen unterliegen können, werden in den Zeichnungen konkrete Ausführungsformen davon beispielhaft gezeigt und hierin ausführlich beschrieben. Es versteht sich jedoch, dass nicht beabsichtigt wird, die Konzepte der vorliegenden Offenbarung auf die konkreten offenbarten Formen zu begrenzen; stattdessen soll die Erfindung im Gegenteil alle Modifikationen, Äquivalente und Alternativen abdecken, die konsistent mit der vorliegenden Offenbarung und den anhängenden Ansprüchen sind.
  • In der Beschreibung enthaltene Verweise auf „eine Ausführungsform“, „eine illustrative Ausführungsform“ usw. geben an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft beinhalten kann, doch jede Ausführungsform dieses bestimmte Merkmal, diese bestimmte Struktur oder diese bestimmte Eigenschaft zwar beinhalten kann, aber nicht notwendigerweise beinhalten muss. Darüber hinaus beziehen sich solche Ausdrücke nicht notwendigerweise auf dieselbe Ausführungsform. Wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft im Zusammenhang mit einer Ausführungsform beschrieben wird, wird ferner davon ausgegangen, dass es zum Wissen eines Fachmanns auf dem Gebiet gehört, ein solches Merkmal, eine solche Struktur oder eine solche Eigenschaft in Verbindung mit anderen Ausführungsformen zu erwirken, seien sie ausdrücklich beschrieben oder nicht. Darüber hinaus sollte es sich verstehen, dass in einer Liste in der Form von „mindestens ein A, B und C“ enthaltene Positionen (A); (B); (C); (A und B); (A und C); (B und C) oder (A, B und C) bedeuten können. Ähnlich können in einer Liste in der Form von „A, B und/oder C“ enthaltene Positionen (A); (B); (C); (A und B); (A und C); (B und C) oder (A, B und C) bedeuten.
  • Die offenbarten Ausführungsformen können in einigen Fällen in Hardware, Firmware, Software oder jeglichen Kombinationen davon umgesetzt werden. Die offenbarten Ausführungsformen können auch als Anweisungen umgesetzt werden, die auf einem flüchtigen oder nicht flüchtigen maschinenlesbaren (z. B. rechenmaschinenlesbaren) Speichermedium abgelegt oder gespeichert sind, das von einem oder mehreren Prozessoren gelesen und ausgeführt werden kann. Ein maschinenlesbares Speichermedium kann verkörpert sein als ein Speichergerät, Mechanismus oder eine andere physische Struktur zum Speichern oder Übertragen von Informationen in einer von einer Maschine lesbaren Form (z. B. ein flüchtiger oder nicht flüchtiger Speicher, eine Medienscheibe oder eine andere Medienvorrichtung).
  • In den Zeichnungen können einige strukturelle oder methodische Merkmale in bestimmten Anordnungen und/oder Reihenfolgen gezeigt werden. Es versteht sich jedoch, dass solche speziellen Anordnungen und/oder Reihenfolgen möglicherweise nicht erforderlich sind. Stattdessen können solche Merkmale in einigen Ausführungsformen in einer anderen Weise und/oder Reihenfolge angeordnet sein als in den illustrativen Figuren dargestellt. Darüber hinaus soll die Einbeziehung eines strukturellen oder methodischen Merkmals in eine bestimmte Figur nicht beinhalten, dass dieses Merkmal in allen Ausführungsformen erforderlich ist und in einigen Ausführungsformen möglicherweise nicht enthalten sein oder mit anderen Merkmalen kombiniert werden kann.
  • Nunmehr Bezug nehmend auf 1, beinhaltet eine illustrative Rechenvorrichtung 100 für die sichere Kommunikation zwischen virtuellen Maschinen über einen gemeinsamen Speicher einen Prozessor 120, der eine Ausführung in einem Root-Virtualisierungsmodus und in einem Non-Root-Virtualisierungsmodus unterstützt. Wie nachfolgend ausführlicher beschrieben, baut die Rechenvorrichtung 100 im Betrieb einen Root-Hypervisor, der im Root-Virtualisierungsmodus ausgeführt wird, und einen Non-Root-Hypervisor, der im Non-Root-Virtualisierungsmodus ausgeführt wird, auf. Der Root-Hypervisor kann sicherheits- und leistungsintensive Operationen ausführen, etwa generische Handler für Ausgänge virtueller Maschinen. Der Non-Root-Hypervisor kann beim Root-Hypervisor einen oder mehrere Callback-Handler und entsprechende Auslösebedingungen registrieren. In Reaktion auf einen Ausgang einer virtuellen Maschine kann der Root-Hypervisor, wenn die Auslösebedingung erfüllt ist, in den Non-Root-Virtualisierungsmodus schalten und den registrierten Callback-Handler ausführen. Folglich kann die Rechenvorrichtung 100 eine zweistufige Virtualisierung ohne genestete Virtualisierung oder Software-Emulation ermöglichen und damit die virtualisierte Leistung erheblich verbessern. Beispielsweise kann die die Rechenvorrichtung 100 durch Verarbeiten des Ausgangs der virtuellen Maschine im Root-Hypervisor und Evaluieren der Auslösebedingungen im Vergleich zu einer genesteten Virtualisierung ein Ausführen vieler Ausgänge der virtuellen Maschine verhindern. Darüber hinaus kann die Rechenvorrichtung 100 Virtualisierungsvorgänge stapeln oder anderweitig bündeln und Listen von Aktualisierungen für Virtualisierungsunterstützungsobjekte nutzen, um eine volle Virtualisierung aller zur Virtualisierungsunterstützungsobjekte zu vermeiden. Durch Einbeziehung einer höherstufigen Funktionalität in dem Non-Root-Hypervisor kann der Root-Hypervisor im Vergleich zu traditionellen Monitoren oder Hypervisoren für virtuelle Maschinen eine kleinere Codebasis haben, und folglich kann auch die Rechenvorrichtung 100 eine reduzierte vertrauenswürdige Codebasis haben.
  • Die Rechenvorrichtung 100 kann als jeglicher Typ einer Vorrichtung verkörpert sein, die in der Lage ist, mehrstufige Virtualisierung auszuführen und anderweitig die hierin beschriebenen Funktionen auszuführen. Beispielsweise kann die Rechenvorrichtung 100 ohne Einschränkung verkörpert sein als eine Workstation, ein Server-Rechner, ein verteiltes Rechensystem, ein Multiprozessorsystem, ein Schoßrechner, ein Notizbuchrechner, ein Flachrechner, ein intelligentes Mobiltelefon, eine mobile Rechenvorrichtung, eine tragbare Rechenvorrichtung, ein Rechner, ein Tischrechner, eine verbraucherelektronische Vorrichtung, ein intelligentes Gerät und/oder eine sonstige Rechenvorrichtung, die zu einer Kommunikation zwischen virtuellen Maschinen über einen gemeinsamen Speicher in der Lage sind. Wie in 1 gezeigt, beinhaltet die illustrative Rechenvorrichtung 100 den Prozessor 120, ein E/A-Subsystem 126, einen Speicher 128 und eine Datenspeichervorrichtung 130. Selbstverständlich kann die Rechenvorrichtung 100 in anderen Ausführungsformen andere oder zusätzliche Komponenten beinhalten wie etwa solche, die üblicherweise in einem Notizbuchrechner zu finden sind (z. B. verschiedene Eingabe/Ausgabevorrichtungen). Darüber hinaus können in einigen Ausführungsformen eine oder mehrere der illustrativen Komponenten in einer anderen Komponente enthalten sein oder anderweitig einen Teil einer anderen Komponente bilden. Beispielsweise kann in einigen Ausführungsformen der Speicher 128 oder Teile davon in dem Prozessor 120 enthalten sein.
  • Der Prozessor 120 kann als jeglicher Typ eines Prozessors verkörpert sein, der in der Lage ist, die hierin beschriebenen Funktionen auszuführen. Beispielsweise kann der Prozessor 120 als ein Einzel- oder Mehrfachkernprozessor(en), digitaler Signalprozessor, eine Mikrosteuerung oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerungsschaltung verkörpert sein. Darüber hinaus ist die Rechenvorrichtung 100 zwar so illustriert, dass sie einen Einzelprozessor 120 beinhaltet, doch sollte es sich verstehen, dass sie in einigen Ausführungsformen auch mehrere Prozessoren 120 beinhalten kann. Der Prozessor 120 beinhaltet eine hardwarebasierte, hardwareunterstützte oder hardwarebeschleunigte Unterstützung für Virtualisierung. Insbesondere beinhaltet der Prozessor 120 Unterstützung 122 für Erweiterungen virtueller Maschinen (Virtual Machine Extensions, VMX) und Unterstützung 124 für Extended Page Table (EPT). Die VMX-Unterstützung 122 unterstützt die virtualisierte Ausführung von Betriebssystemen und anderen Gästen durch Bereitstellung zweier Ausführungsmodi: den VMX-Root-Modus und den VMX-Non-Root-Modus. Der VMX-Root-Modus gestattet das Ausführen von Software, um eine breite Kontrolle über die Rechenvorrichtung 100 und ihre Hardwareressourcen zu haben. Dementsprechend kann ein Root-Hypervisor im VMX-Root-Modus ausgeführt werden. Der VMX-Non-Root-Modus beschränkt den Zugriff auf bestimmte Hardwarebefehle, während das gewöhnliche Ring-/Privilegsystem des Prozessors 120 noch immer ausgeführt wird. Folglich können ein Non-Root-Hypervisor und eine oder mehrere virtuelle Maschinen (VMs) und/oder Betriebssysteme (Operating Systems, OSs) als Gäste im VMX-Non-Root-Modus ausgeführt werden. Die Ausführung bestimmter Hardwareanweisungen und bestimmter anderer Systemereignisse kann hardwareunterstützte Übergänge in einen VMX-Root-Modus auslösen. Diese hardwareunterstützten Übergänge sind allgemein bekannt als Ausgänge virtueller Maschinen (Virtual Machine Exits, VMExits) oder Hypercalls. Bei Auftreten eines VMExit kann der Prozessor 120 Kontext von der Gast-VM oder dem Non-Root-Hypervisor zum Root-Hypervisor umschalten, um den VMExit zu verarbeiten. Folglich können VMExits in einigen Ausführungsformen zu Leistungsverschlechterungen von virtualisiertem Code führen. Die VMX-Unterstützung 122 kann beispielsweise als IntelⓇ VT-x Technologie verkörpert sein.
  • Die EPT-Unterstützung 124 unterstützt eine hardwareassistierte Page-Address-Translation der zweiten Stufe. Bei nicht virtualisierten Arbeitslasten (oder bei Betrieb im VMX-Root-Modus) kann der Prozessor 120 eine hardwareassistierte Übersetzung von virtuellen Speicheradressen (auch bekannt als lineare Adressen) in physische Speicheradressen bereitstellen. Der Prozessor 120 kann Speicheradressen unter Verwendung von einer oder mehreren Seitentabellenstrukturen übersetzen, die im Speicher 128 gespeichert sind und von einem Host-Betriebssystem, Hypervisor oder VMM verwaltet werden. Bei virtualisierten Arbeitslasten (oder bei Betrieb im VMX-Non-Root-Modus) unterstützt der Prozessor 120 eine hardwareassistierte Übersetzung von virtuellen Speicheradressen (die beispielsweise von Anwendungen verwendet werden, die innerhalb einer Gast-VM ausgeführt werden) in Adressen physischer Gastspeicher. Ein Gast-OS kann im Speicher 128 eine oder mehrere Seitentabellenstrukturen verwahren, um die Übersetzung in Adressen physischer Gastspeicher zu verwalten. Es ist jedoch möglich, dass die Adresse eines physischen Gastspeichers nicht mit der Adresse eines tatsächlichen physischen Speichers innerhalb des Speichers 128 korrespondiert. Die EPT-Unterstützung 124 stellt eine hardwareunterstützte Übersetzung von Adressen physischer Gastspeicher in Adressen physischer Speicher (auch bekannt als Adressen physischer Gastgeberspeicher) bereit. Die EPT-Unterstützung 124 kann Speicheradressen unter Verwendung von einer oder mehreren Extended-Page-Table-Strukturen übersetzen, die im Speicher 128 gespeichert sind und von dem Root-Hypervisor verwaltet werden. Ohne die EPT-Unterstützung 124 kann die Übersetzung von Adressen physischer Gastspeicher in Adressen physischer Speicher einen oder mehrere VMExits erfordern. Die EPT-Unterstützung 124 kann auch die Zuweisung von Zugriffsberechtigungen zu jeder physischen Gastseite und/oder physischen Seite (z. B. Lese-, Schreib- und/oder Ausführungsberechtigungen) unterstützen. Berechtigungsverstöße, die als EPT-Verstöße bekannt sein können, können VMExits generieren, die dem Root-Hypervisor ein Verarbeiten des EPT-Verstoßes ermöglichen. Die EPT-Unterstützung 124 kann beispielsweise als Intel® VT-x Technologie verkörpert sein.
  • Der Speicher 128 kann als jeglicher Typ eines flüchtigen oder nicht flüchtigen Speichers oder Datenspeichers verkörpert sein, der in der Lage ist, die hierin beschriebenen Funktionen auszuführen. Im Betrieb kann der Speicher 128 verschiedene Daten und Software speichern, die während des Betriebs der Rechenvorrichtung 100 verwendet werden, wie Betriebssysteme, Anwendungen, Programme, Bibliotheken und Treiber. Der Speicher 128 kann auch ein oder mehrere Virtualisierungsunterstützungsobjekte beinhalten, die zur Steuerung von Virtualisierungsfunktionen des Prozessors 120 genutzt werden können. Beispielsweise kann der Speicher 128 ein oder mehrere Strukturen zur Steuerung einer virtuellen Maschine (Virtual Machine Control Structures, VMCSs) beinhalten, die zum Konfigurieren und anderweitigen Steuern virtueller Maschinen genutzt werden können, die von der Rechenvorrichtung 100 ausgeführt werden. Als ein weiteres Beispiel kann der Speicher 128 eine oder mehrere Extended Page Tables (EPTs) beinhalten. Wie nachfolgend weiter beschrieben, kann der Speicher 128 auch ein oder mehrere virtuelle Virtualisierungsunterstützungsobjekte beinhalten, die von dem Non-Root-Hypervisor verwaltet werden.
  • Der Speicher 128 ist über das E/A-Subsystem 126 kommunikativ gekoppelt mit dem Prozessor 120, der als Schaltung und/oder Komponenten verkörpert sein kann, um Eingangs/Ausgangsoperationen mit dem Prozessor 120, dem Speicher 128 und anderen Komponenten der Rechenvorrichtung 100 zu ermöglichen. Beispielsweise kann das E/A-Subsystem 126 verkörpert sein als Speichersteuerungs-Hubs, Eingangs/Ausgangs-Steuerungs-Hubs, Firmware-Vorrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Untersysteme, welche Eingangs/Ausgangsoperationen ermöglichen, oder diese Komponenten anderweitig beinhalten. In einigen Ausführungsformen kann das E/A-Subsystem 126 einen Teil eines Ein-Chip-Systems (System-on-a-Chip, SoC) bilden und zusammen mit dem Prozessor 120, dem Speicher 128 und anderen Komponenten der Rechenvorrichtung 100 auf einem einzelnen Chip mit integrierter Schaltung enthalten sein.
  • Die Datenspeichervorrichtung 130 kann verkörpert sein als jeglicher Typ einer Vorrichtung oder von Vorrichtungen, die zur kurzfristigen oder langfristigen Speicherung von Daten konfiguriert sind, wie beispielsweise Speichervorrichtungen und Schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke und andere Datenspeichervorrichtungen. In einigen Ausführungsformen kann die Rechenvorrichtung 100 auch eine oder mehrere Peripherievorrichtungen 132 beinhalten. Die Peripherievorrichtungen 132 können eine beliebige Anzahl an zusätzlichen Eingangs/Ausgangsvorrichtungen, Schnittstellenvorrichtungen und/oder Peripherievorrichtungen beinhalten. Beispielsweise können die Peripherievorrichtungen 132 in einigen Ausführungsformen eine Anzeige, einen Berührungsbildschirm, eine Grafikschaltung, eine Tastatur, eine Maus, ein Sprechersystem, einen Netzwerkadapter, eine Kommunikationsschaltung und/oder andere Eingangs/Ausgangsvorrichtungen, Schnittstellenvorrichtungen und/oder Peripherievorrichtungen beinhalten.
  • Nunmehr Bezug nehmend auf 2, baut die Rechenvorrichtung 100 in der illustrativen Ausführungsform während des Betriebs eine Umgebung 200 auf. Die illustrative Ausführungsform 200 beinhaltet ein VMX-Root-Modul 202 und ein VMX-Non-Root-Modul 212. Wie gezeigt, beinhaltet das VMX-Root-Modul 202 ein Ausgangsmodul 204 einer virtuellen Maschine, ein Callback-Managementmodul 206, ein AktualisierungsManagementmodul 208 und ein Integritätsmodul 210. Das VMX-Non-Root-Modul 212 beinhaltet ein Callback-Modul 216 und ein Paravirtualisierungsmodul 218. Die verschiedenen Module der Umgebung 200 können als Hardware, Firmware, Software oder eine Kombination davon verkörpert sein. Beispielsweise können jedes der Module, die Logik und andere Komponenten der Umgebung 200 einen Teil des Prozessors 120 oder anderer Hardwarekomponenten der Rechenvorrichtung 100 bilden oder anderweitig durch sie gebildet werden. In einigen Ausführungsformen können ein oder mehrere der Module der Umgebung 200 als eine Schaltung oder eine Sammlung elektrischer Vorrichtungen verkörpert sein (z. B. eine Ausgangsschaltung 204 einer virtuellen Maschine, eine Callback-Schaltung 216 usw.).
  • Das Ausgangsmodul 204 der virtuellen Maschine ist dazu ausgelegt, durch einen Root-Hypervisor den Ausgang einer virtuellen Maschine zu empfangen, der von einer virtuellen Maschine der Rechenvorrichtung 100 erzeugt wurde. Wie nachfolgend weiter beschrieben, wird die virtuelle Maschine von einem Non-Root-Hypervisor der Rechenvorrichtung 100 gehostet. Das Ausgangsmodul 204 der virtuellen Maschine ist dazu ausgelegt, in einem Root-Virtualisierungsmodus des Prozessors 120, beispielsweise dem VMX-Root-Modus, zu arbeiten. Das Ausgangsmodul 204 der virtuellen Maschine kann ferner dazu ausgelegt sein, durch den Root-Hypervisor im Root-Virtualisierungsmodus den Ausgang der virtuellen Maschine zu verarbeiten, nachdem festgestellt wurde, dass für den Grund des Ausgangs der virtuellen Maschine kein Callback-Handler registriert wurde. Das Ausgangsmodul 204 der virtuellen Maschine kann ferner dazu ausgelegt sein, das Ausführen der virtuellen Maschine nach dem Verarbeiten des Ausgangs der virtuellen Maschine oder nachdem festgestellt wurde, dass eine Auslösebedingung im Zusammenhang mit dem Callback-Handler nicht erfüllt wurde, wiederaufzunehmen.
  • Das Callback-Managementmodul 206 ist dazu ausgelegt, durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob für den Grund des Ausgangs der virtuellen Maschine ein Callback-Handler des Non-Root-Hypervisors registriert ist. Das Callback-Managementmodul 206 ist ferner dazu ausgelegt, durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob eine Auslösebedingung in Verbindung mit dem Callback-Handler erfüllt ist, wenn festgestellt wurde, dass der Callback-Handler registriert ist.
  • Das Update-Managementmodul 208 ist dazu ausgelegt, durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob ein virtuelles Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors in Reaktion auf das Ausführen des Callback-Handlers verändert wurde. Das virtuelle Virtualisierungsunterstützungsobjekt kann beispielsweise als eine virtuelle Struktur zur Steuerung einer virtuellen Maschine (Virtual Machine Control Structure, VMCS) oder eine virtuelle Extended Page Table (EPT) verkörpert sein. Das Aktualisierungsmanagementmodul 208 ist ferner dazu ausgelegt, durch den Root-Hypervisor im Root-Virtualisierungsmodus ein Virtualisierungsunterstützungsobjekt der Rechenvorrichtung 100 zu aktualisieren, basierend auf dem virtuellen Virtualisierungsunterstützungsobjekt in Reaktion auf die Feststellung, dass das virtuelle Virtualisierungsunterstützungsobjekt verändert wurde. Ähnlich kann das Virtualisierungsunterstützungsobjekt als eine VMCS oder eine EPT verkörpert sein. Das Aktualisierungsmanagementmodul 208 ist ferner dazu ausgelegt, durch den Root-Hypervisor die Ausführung der virtuellen Maschine in Reaktion auf ein Aktualisieren des Virtualisierungsunterstützungsobjekts wiederaufzunehmen. In einigen Ausführungsformen kann ein Aktualisieren des Virtualisierungsunterstützungsobjekts beinhalten, dass durch den Root-Hypervisor die Gültigkeit des virtuellen Virtualisierungsunterstützungsobjekts überprüft wird. In einigen Ausführungsformen kann das Aktualisierungsmanagementmodul 208 ferner dazu ausgelegt sein, durch den Root-Hypervisor im Root-Virtualisierungsmodus nach dem Empfang des Ausgangs der virtuellen Maschine das Virtualisierungsunterstützungsobjekt zu verändern und durch den Root-Hypervisor im Root-Virtualisierungsmodus eine Liste von Veränderungen am Virtualisierungsunterstützungsobjekt zu erstellen, die dem Non-Root-Hypervisor bereitgestellt werden können.
  • Das Integritätsmodul 210 ist dazu ausgelegt, durch den Root-Hypervisor im Root-Virtualisierungsmodus die Ausführung des Non-Root-Hypervisors zu überwachen. In einigen Ausführungsformen kann das Integritätsmodul 210 ferner dazu ausgelegt sein, durch den Root-Hypervisor im Root-Virtualisierungsmodus die Ausführung eines Gastgeberbetriebssystems der Rechenvorrichtung 100 zu überwachen. Wie nachfolgend beschrieben, kann das Gastgeberbetriebssystem den Non-Root-Hypervisor hosten.
  • Das Callback-Modul 216 ist dazu ausgelegt, den Callback-Handler des Non-Root-Hypervisors auszuführen, wenn festgestellt wird, dass die Auslösebedingung erfüllt ist. In einigen Ausführungsformen kann das Callback-Modul 216 dazu ausgelegt sein, den Callback-Handler im Non-Root-Virtualisierungsmodus des Prozessors 120 auszuführen. Das Callback-Modul 216 kann ferner dazu ausgelegt sein, durch den Non-Root-Hypervisor auf der Grundlage des Virtualisierungsunterstützungsobjekts das virtuelle Virtualisierungsunterstützungsobjekt zu aktualisieren. Das Callback-Modul 216 kann dazu ausgelegt sein, die vom Root-Hypervisor bereitgestellte Liste von Veränderungen am Virtualisierungsunterstützungsobjekt zu nutzen. Das Callback-Modul 216 kann ferner dazu ausgelegt sein, durch den Non-Root-Hypervisor während des Ausführens des Callback-Handlers das virtuelle Virtualisierungsunterstützungsobjekt zu verändern und durch den Non-Root-Hypervisor eine Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt zu erstellen.
  • Das Paravirtualisierungsmodul 218 ist dazu ausgelegt, durch den Non-Root-Hypervisor festzustellen, ob der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird. Das Paravirtualisierungsmodul 218 ist ferner dazu ausgelegt, durch den Non-Root-Hypervisor den Callback-Handler und die zugehörige Auslösebedingung beim Root-Hypervisor zu registrieren, nachdem festgestellt wurde, dass der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird. Das Paravirtualisierungsmodul 218 kann ferner dazu ausgelegt sein, die virtuelle Maschine durch den Non-Root-Hypervisor im Root-Virtualisierungsmodus zu hosten, nachdem festgestellt wurde, dass der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus nicht ausgeführt wird.
  • Nunmehr Bezug nehmend auf 3, kann die Rechenvorrichtung 100 im Einsatz eine Hypervisor-Umgebung 300 aufbauen. Wie gezeigt, beinhaltet die illustrative Hypervisor-Umgebung 300 ein Gastgeberbetriebssystem 302, eine oder mehrere virtuelle Maschinen 304, einen Non-Root-Hypervisor 306 und einen Root-Hypervisor 320. Das Gastgeberbetriebssystem 302 kann als jegliches Betriebssystem oder eine andere Steuerungsstruktur der Rechenvorrichtung 100 verkörpert sein. Wie gezeigt, wird das Gastgeberbetriebssystem 302 im VMX-Non-Root-Modus ausgeführt.
  • Der Root-Hypervisor 320, auch bekannt als Hypervisor der Stufe 0 oder L0-Hypervisor, kann als ein Hypervisor, ein Virtual-Machine-Monitor (VMM) oder eine andere Steuerungsstruktur der Rechenvorrichtung 100 verkörpert sein, die im VMX-Root-Modus ausgeführt wird. Der Root-Hypervisor 320 kann „dünn“ sein; das heißt, der Root-Hypervisor 320 kann eine relativ kleine Codebasis haben. Beispielsweise kann der Root-Hypervisor 320 nur Hardware-Virtualisierungsabstraktionen und Isolation bereitstellen, ohne eine volle Virtualisierung von Gästen bereitzustellen. Wie gezeigt, kann der Root-Hypervisor 320 einen Integritätsprüfer 322 beinhalten, um das Gastgeberbetriebssystem 302 und/oder den Non-Root-Hypervisor 306 zu überwachen und/oder seine Integrität zu prüfen.
  • Der Non-Root-Hypervisor 306, auch bekannt als Hypervisor der Stufe 1 oder L1-Hypervisor, kann als ein gehosteter VMM, Hypervisor oder eine andere Steuerungsstruktur der Rechenvorrichtung 100 verkörpert sein, die im VMX-Non-Root-Modus ausgeführt wird. Der Non-Root-Hypervisor 306 kann eine vollständige Virtualisierung von Gästen (z. B. der virtuellen Maschinen 304) bereitstellen und folglich eine relativ große Codebasis haben. Da der Non-Root-Hypervisor 306 nicht im VMX-Root-Modus ausgeführt werden kann, muss der Non-Root-Hypervisor 306 nicht Teil der vertrauenswürdigen Codebasis der Rechenvorrichtung 100 sein.
  • Wie in 3 gezeigt und nachfolgend ausführlicher beschrieben, verwahrt der Root-Hypervisor 320 eine Sammlung von VMX-Objekten 326, einschließlich beispielsweise einer oder mehrerer Strukturen zur Steuerung einer virtuellen Maschine (VMCSs) 328 und/oder Extended Page Tables (EPTs) 330. Wie nachfolgend ausführlicher beschrieben, können die VMX-Objekte 326 eine jegliche speicherinterne Struktur beinhalten, die vom Prozessor 120 zur Steuerung der Ausführung von virtualisiertem Code genutzt wird. Ähnlich verwahrt der Non-Root-Hypervisor 306 eine Sammlung virtueller VMX-Objekte 308, einschließlich beispielsweise einer oder mehrerer virtueller VMCSs 310 und/oder virtueller EPTs 312. Wie nachfolgend ausführlicher beschrieben, können Aktualisierungen an den virtuellen VMX-Objekten 308 gegenüber den VMX-Objekten 326 und umgekehrt propagiert werden. Wie in 3 gezeigt, können Aktualisierungen unter Verwendung einer Non-Root-Hypervisor-Aktualisierungsliste 314 und einer Root-Hypervisor-Aktualisierungsliste 324 propagiert werden, die Änderungen angeben können, die von dem Non-Root-Hypervisor 306 an den virtuellen VMX-Objekten 308 vorgenommen wurden, bzw. Änderungen, die von dem Root-Hypervisor 320 an den VMX-Objekten 326 vorgenommen wurden.
  • Der Root-Hypervisor 320 baut ferner einen oder mehrere Ausgangs/Eingangs-Handler 332 für eine virtuelle Maschine (VM) auf. Die VM-Ausgangs/Eingangs-Handler 332 können als jegliche Funktion, jegliches Verfahren, jeglicher Vektor oder jegliche sonstige Routine verkörpert sein, die vom Prozessor 120 in Reaktion auf einen Ausgang einer virtuellen Maschine und/oder Eingang einer virtuellen Maschine aktiviert werden kann. Der Non-Root-Hypervisor 306 beinhaltet ferner einen oder mehrere Callback-Handler 316, die als jegliche Funktion, jegliches Verfahren, jeglicher Vektor oder jegliche sonstige Routine verkörpert sein können, die vom Root-Hypervisor 320 aktiviert werden kann, beispielsweise in Reaktion auf einen VM-Ausgang. Wie nachfolgend ausführlicher beschrieben, kann der Root-Hypervisor 320 eine oder mehrere Auslösebedingungen 334 bewerten, um festzustellen, ob ein Callback-Handler 316 zu aktivieren ist.
  • Wie gezeigt, beinhaltet die Rechenvorrichtung 100 ferner eine Schnittstelle zur Anwendungsprogrammierung (Application Programming Interface, API) 318 für den Root-Hypervisor, bereitgestellt durch den Root-Hypervisor 320. Die Root-Hypervisor-API 318 kann durch jegliche Funktionsaufrufe, Hypercalls, Ausgänge virtueller Maschinen, spezielle Prozessoranweisungen oder andere Schnittstellenelemente verkörpert werden, die von dem Non-Root-Hypervisor 306 für die Kommunikation mit dem Root-Hypervisor 320 genutzt werden können. Dementsprechend kann der Non-Root-Hypervisor 306 in einigen Ausführungsformen paravirtualisiert werden; das heißt, der Non-Root-Hypervisor 306 kann in der Lage sein festzustellen, dass er unter der Aufsicht eines Root-Hypervisors 320 ausgeführt wird, beispielsweise durch Zugriff auf die Root-Hypervisor-API 318.
  • Beispielsweise kann die Root-Hypervisor-API 318 Hypercalls beinhalten, um das Verarbeiten des VM-Ausgangs für jeden VM-Ausgangsgrund zu konfigurieren, beispielsweise einen VmExitHandle() Hypercall. Der VmExitHandle() Hypercall kann die Gründe für den VM-Ausgang, einen Pointer zu einem Callback-Handler 316, die (in Abhängigkeit vom Grund spezifischen) Auslösebedingungen 334, einen Pointer zu einem virtuellen VMX-Objekt 308 (z. B. eine virtuelle VMCS 310 oder eine virtuelle EPT 312), die Ll-Aktualisierungsliste 314, die LO-Aktualisierungsliste 324 und/oder andere Daten spezifizieren. Als anderes Beispiel kann die Root-Hypervisor-API 318 Hypercalls beinhalten, um die virtuelle VMCS 310 und/oder die virtuelle EPT 312 zu verarbeiten (z. B. ein Ungültigmachen oder andere Aufgaben auszuführen). Die Root-Hypervisor-API 318 kann einen UpdateVMCS() Hypercall beinhalten, um den Root-Hypervisor 320 aufzufordern, die VMCS 328 zu aktualisieren, eine virtuelle VMCS 310 und die Non-Root-Hypervisor-Updateliste 314 zu spezifizieren, und die Root-Hypervisor-API 318 kann einen UpdateEPT() Hypercall beinhalten, um den Root-Hypervisor 320 zum Aktualisieren der EPT 330 aufzufordern, wobei eine virtuelle EPT 312 und die Non-Root-Hypervisor-Updateliste 314 spezifiziert werden. In einigen Ausführungsformen kann die API 318 dem Non-Root-Hypervisor 306 gestatten, eine oder mehrere spezialisierte Prozessoranweisungen auszuführen, um auf Hardware-Virtualisierungsfunktionen des Prozessors 120 zuzugreifen, ohne einen Hypercall zu erzeugen. Beispielsweise kann der Non-Root-Hypervisor 306 in einigen Ausführungsformen die Prozessoranweisung VMFUNC ausführen, um auf die L0-Aktualisierungsliste 324, die VMX-Objekte 326 oder andere Daten zuzugreifen, die vom Root-Hypervisor 320 bezeichnet wurden.
  • Nunmehr Bezug nehmend auf 4 kann die Rechenvorrichtung 100 im Einsatz ein Verfahren 400 zur Root-Virtualisierung ausführen. Das Verfahren 400 kann von dem Root-Hypervisor 320 ausgeführt und folglich im VMX-Root-Modus mit vollem Zugriff auf die Rechenvorrichtung 100 ausgeführt werden. Das Verfahren 400 beginnt im Block 402, in dem die Rechenvorrichtung 100 die VMX-Objekte 326 auf eine virtualisierte Ausführung vorbereitet. Die VMX-Objekte 326 können eine jegliche speicherinterne Struktur beinhalten, die vom Prozessor 120 zur Steuerung der Ausführung von virtualisiertem Code genutzt wird. Beispielsweise können die VMX-Objekte 326 eine oder mehrere Strukturen zur Steuerung einer virtuellen Maschine (VMCSs) 328 und/oder eine oder mehrere Extended Page Tables (EPTs) 330 beinhalten. Welche konkreten VMX-Objekte 326 vorbereitet werden, kann von den Virtualisierungsfähigkeiten des Prozessors 120 sowie von der konkreten Virtualisierungsarbeitslast der Rechenvorrichtung 100 abhängen. Beispielsweise kann der Root-Hypervisor 320 eine VMCS 328 für jede virtuelle CPU und eine EPT 330 für jede virtuelle Maschine 304 vorbereiten.
  • Im Block 404 beginnt die Rechenvorrichtung 100 mit der Ausführung des Gastgeberbetriebssystems 302. Das Gastgeberbetriebssystem 302 kann im VMX-Non-Root-Modus ausgeführt werden. Beispielsweise kann der Root-Hypervisor 320 die Operation eines VM-Eintrags in das Gastgeberbetriebssystem 302 ausführen, um die Ausführung des Gastgeberbetriebssystems 302 zu starten. In einigen Ausführungsformen kann der Root-Hypervisor 320 im Block 406 das Gastgeberbetriebssystem 302 überwachen und/oder einer Integritätsprüfung unterziehen. Der Root-Hypervisor 320 kann bestimmte kritische ausführbare Bilder, Datenstrukturen oder andere Speicherorte ausführen und überwachen, beispielsweise durch Überprüfen von Prüfsummen der kritischen Speicherorte. Der Root-Hypervisor 320 kann jede geeignete Technik nutzen, um das Gastgeberbetriebssystem 302 zu überwachen oder einer Integritätsprüfung zu unterziehen, einschließlich der Nutzung von Virtualisierungsfunktionen des Prozessors 120. Beispielsweise kann der Root-Hypervisor 320 bestimmte Orte im Speicher durch Überwachung auf VM-Ausgänge auf Veränderungen überwachen, indem Genehmigungen für eine oder mehrere EPTs 330 gesetzt oder andere Virtualisierungsfunktionen genutzt werden.
  • Im Block 408 beginnt die Rechenvorrichtung 100 mit der Ausführung des Non-Root-Hypervisors 306. Der Non-Root-Hypervisor 306 kann im VMX-Non-Root-Modus ausgeführt werden. Das Gastgeberbetriebssystem 302 kann den Non-Root-Hypervisor 306 im VMX-Non-Root-Modus als einen gewöhnlichen Prozess ausführen. Zusätzlich oder alternativ kann der Root-Hypervisor 320 die Ausführung des Non-Root-Hypervisors 306 im VMX-Non-Root-Modus beginnen. In einigen Ausführungsformen kann der Root-Hypervisor 320 im Block 410 den Non-Root-Hypervisor 306 überwachen und/oder einer Integritätsprüfung unterziehen. Der Root-Hypervisor 320 kann bestimmte kritische ausführbare Bilder, Datenstrukturen oder andere Speicherorte identifizieren und überwachen, beispielsweise durch Überprüfen von Prüfsummen der kritischen Speicherorte. Der Root-Hypervisor 320 kann jede geeignete Technik nutzen, um den Non-Root-Hypervisor 306 zu überwachen oder einer Integritätsprüfung zu unterziehen, einschließlich der Nutzung von Virtualisierungsfunktionen des Prozessors 120. Beispielsweise kann der Root-Hypervisor 320 bestimmte Orte im Speicher durch Überwachung auf VM-Ausgänge auf Veränderungen überwachen, indem Genehmigungen für eine oder mehrere EPTs 330 gesetzt oder andere Virtualisierungsfunktionen genutzt werden.
  • Im Block 412 registriert der Root-Hypervisor 320 der Rechenvorrichtung 100 einen oder mehrere Callback-Handler 316 und zugehörige Auslösebedingungen 334, die vom Non-Root-Hypervisor 306 vorgelegt wurden. Jeder Callback-Handler 316 kann als eine Funktion, ein Verfahren, ein Vektor oder eine andere Routine des Non-Root-Hypervisors 306 verkörpert sein, die vom Root-Hypervisor 320 aktiviert werden können. Der Root-Hypervisor 320 kann einen Callback-Handler 316 für einen oder mehrere potenzielle Gründe für einen VM-Ausgang registrieren. Jede Auslösebedingung 334 kann als eine Strategie, ein Filter oder ein anderer konditionaler Test verkörpert sein, der von dem Root-Hypervisor 320 überprüft werden kann. Wie nachfolgend ausführlicher beschrieben, werden die Auslösebedingungen 334 überprüft um festzustellen, ob der zugeordnete Callback-Handler 316 aufgerufen werden soll. Der Root-Hypervisor 320 kann die Callback-Handler 316 und die Auslösebedingungen 334 in Reaktion auf einen oder mehrere Aufrufe an die Schnittstelle zur Anwendungsprogrammierung (API) 318 für den Root-Hypervisor registrieren. Beispielsweise kann der Non-Root-Hypervisor 306 einen oder mehrere Funktionsaufrufe, Hypercalls, Ausgänge einer virtuellen Maschine oder andere Schnittstellenelemente der API 318 aktivieren, um die Callback-Handler 316 und/oder Auslösebedingungen 334 zu registrieren. Beim Registrieren des Callback-Handlers 316 kann der Non-Root-Hypervisor 306 ebenfalls zusätzliche Informationen liefern, beispielsweise Pointer zu den virtuellen VMX-Objekten 308 oder Listen verlangter Feldaktualisierungen für die VMCS 328, die von dem Root-Hypervisor 320 auszuführen sind.
  • Im Block 414 überwacht der Root-Hypervisor 320 der Rechenvorrichtung 100 auf vom VMX-Non-Root-Modul erzeugte VM-Ausgänge. Die VM-Ausgänge können beispielsweise von dem Gastgeberbetriebssystem 302, den virtuellen Maschinen 304 und/oder dem Non-Root-Hypervisor 306 erzeugt werden. Der Root-Hypervisor 320 kann zur Überwachung der VM-Ausgänge jede Technik einsetzen. Beispielsweise kann der Root-Hypervisor 320 in einigen Ausführungsformen schlafen, nachgeben oder anderweitig die Verarbeitung stoppen und darauf warten, dass der Prozessor 120 einen VM-Ausgangs-Handler 332 in Reaktion auf einen VM-Ausgang aktiviert. Während der Root-Hypervisor 320 eine Überwachung auf VM-Ausgänge durchführt, wird das Verfahren 400 abgeschlossen, doch das Gastgeberbetriebssystem 302, die virtuellen Maschinen 304 und der Non-Root-Hypervisor 306 können das Ausführen auf der Rechenvorrichtung 100 fortsetzen.
  • Nunmehr Bezug nehmend auf die 5, kann die Rechenvorrichtung 100 im Einsatz ein Verfahren 500 für das Verarbeiten des Ausgangs einer virtuellen Maschine ausführen. Das Verfahren 500 kann von dem Root-Hypervisor 320 ausgeführt und folglich im VMX-Root-Modus mit vollem Zugriff auf die Rechenvorrichtung 100 ausgeführt werden. Das Verfahren 500 beginnt im Block 502, in dem die Rechenvorrichtung 100 einen Ausgang einer virtuellen Maschine verarbeitet. Wie oben beschrieben, kann die Virtualisierungsunterstützung des Prozessors 120 in Reaktion auf den VM-Ausgang einen VM-Ausgangs-Handler 332 des Root-Hypervisors 320 aktivieren. Der VM-Ausgangs-Handler 332 wird im VMX-Root-Modus ausgeführt.
  • Im Block 504 stellt die Rechenvorrichtung 100 fest, ob für den Grund des aktuellen VM-Ausgangs ein Callback-Handler 316 registriert wurde. Die Rechenvorrichtung 100 kann für viele Gründe VM-Ausgänge erzeugen, etwa für eine Unterbrechung, eine Störung, eine Softwareunterbrechung, eine EPT-Verletzung, einen ausdrücklichen VM-Ausgangs-Befehl oder einen anderen Grund für einen VM-Ausgang. Wie oben in Verbindung mit Block 412 beschrieben, kann der Non-Root-Hypervisor 306 beim Root-Hypervisor 320 Callback-Handler 316 für bestimmte Gründe für einen VM-Ausgang registrieren. Die Rechenvorrichtung 100 kann jede Technik nutzen, um den Ausgangsgrund des aktuellen VM-Ausgangs festzustellen. Beispielsweise kann die Rechenvorrichtung 100 ein oder mehrere Felder der VMCS 328 lesen. Im Block 506 prüft die Rechenvorrichtung 100, ob ein Callback-Handler 316 registriert ist. Ist dies der Fall, fährt das Verfahren 500 mit Block 510 fort, wie nachfolgend beschrieben. Wenn kein Callback-Handler 316 registriert ist, zweigt das Verfahren 500 zum Block 508 ab.
  • Im Block 508 verarbeitet der Root-Hypervisor 320 der Rechenvorrichtung 100 den VM-Ausgang. Der Root-Hypervisor 320 kann eine geeignete Verarbeitung des VM-Ausgangs ausführen, einschließlich einer Veränderung von VMX-Objekten 326 oder der Ausführung anderer Virtualisierungsaufgaben. In einigen Ausführungsformen kann der Root-Hypervisor 320 generische oder standardmäßige Operation für das Verarbeiten von VM-Ausgängen ausführen. Folglich kann der Root-Hypervisor 320 bestimmte VM-Ausgänge ohne Einbeziehung des Non-Root-Hypervisors 306 verarbeiten. Beispielsweise kann ein durch Ausführen der CPUID-Anweisung verursachter VM-Ausgang in einigen Ausführungsformen vom Root-Hypervisor 320 ohne Aktivieren des Non-Root-Hypervisors 306 verarbeitet werden. Nach dem Verarbeiten des VM-Ausgangs verzweigt sich das Verfahren 500 nach vorn zum Block 530, in dem der Root-Hypervisor 320 einen VM-Eingang zu dem VMX-Non-Root-Modus ausführt, beispielsweise das Ausführen des Gastgeberbetriebssystems 302, der virtuellen Maschine 304 und/oder des Non-Root-Hypervisors 306 wieder aufnimmt.
  • Erneut Bezug nehmend auf Block 506, fährt das Verfahren 500 mit Block 510 fort, in dem der Root-Hypervisor 320 den VM-Ausgang verarbeitet, wenn für den Ausgangsgrund des VM-Ausgangs ein Callback-Handler 316 registriert wird. Wie weiter oben beschrieben, kann der Root-Hypervisor 320 ein jegliches geeignetes Verarbeiten des VM-Ausgangs ausführen, einschließlich einer Verarbeitung eines generischen oder standardmäßigen VM-Ausgangs. In einigen Ausführungsformen kann der Root-Hypervisor 320 im Block 512 ein oder mehrere VMX-Objekte 326 verändern (z. B. die VMCS 328 und/oder die EPT 330) und eine Liste 324 von Aktualisierungen erstellen, die vom Root-Hypervisor 320 ausgeführt werden. Die Root-Hypervisor-Aktualisierungsliste 324 kann bestimmte VMX-Objekte 326, Felder oder andere Daten identifizieren, die vom Root-Hypervisor 320 geändert wurden. Beispielsweise kann die Liste 324 als eine Bitmap verkörpert sein, die bestimmte Felder der VMCS 328 und/oder der EPT 330 identifiziert, welche vom Root-Hypervisor 320 geändert wurden. Ähnlich kann der Root-Hypervisor 320 in einigen Ausführungsformen im Block 514 auf ein oder mehrere VMX-Objekte 326 zugreifen, für die vom Non-Root-Hypervisor 306 Aktualisierungen angefordert wurden. Wie vorstehend in Verbindung mit Block 412 von 4 beschrieben, kann der Non-Root-Hypervisor 306 Aktualisierungen für bestimmte VMX-Objekte 326, Felder oder andere VMX-Daten anfordern. Der Root-Hypervisor 320 kann die angeforderten VMX-Objekte 326, Felder oder sonstige Daten in der Root-Hypervisor-Aktualisierungsliste 324 beinhalten. Der Root-Hypervisor 320 kann ein oder mehrere Bits in Verbindung mit den angeforderten Daten setzen, die angeforderten Daten kopieren oder die angeforderten Daten dem Non-Root-Hypervisor 306 anderweitig verfügbar machen.
  • In Block 516 überprüft der Root-Hypervisor 320 der Rechenvorrichtung 100 eine oder mehrere Auslösebedingungen 334, die dem Callback-Handler 316 zugeordnet sind, der für den aktuellen VM-Ausgangsgrund registriert ist. Wie oben beschrieben, kann jede Auslösebedingung 334 als eine Strategie, ein Filter oder ein anderer konditionaler Test verkörpert sein, die bzw. der von dem Root-Hypervisor 320 überprüft werden kann. Da die Auslösebedingungen 334 von dem Non-Root-Hypervisor 306 spezifiziert, aber vom Root-Hypervisor 320 evaluiert wurden, gestatten die Auslösebedingungen 334 ein Delegieren der strategischen Entscheidungen vom Non-Root-Hypervisor 306 zum Root-Hypervisor 320. In Block 518 stellt der Root-Hypervisor 320 fest, ob die Auslösebedingung(en) 334 erfüllt wurde(n). Falls nicht, verzweigt sich das Verfahren 500 nach vorn zum Block 530, in dem der Root-Hypervisor 320 einen VM-Eingang zu dem VMX-Non-Root-Modus ausführt, beispielsweise das Ausführen des Gastgeberbetriebssystems 302, der virtuellen Maschine 304 und/oder des Non-Root-Hypervisors 306 wieder aufnimmt. Wenn die Auslösebedingung(en) 334 erfüllt wurde(n), wird das Verfahren 500 mit Block 520 fortgesetzt.
  • Im Block 520 schaltet die Rechenvorrichtung 100 in einigen Ausführungsformen in den VMX-Non-Root-Modus um. Beispielsweise kann der Root-Hypervisor 320 einen VM-Eintrag ausführen oder anderweitig in den VMX-Non-Root-Modus umschalten. Das Umschalten in den VMX-Non-Root-Modus kann dem Root-Hypervisor 320 gestatten, die Sicherheit und/oder Integrität der Rechenvorrichtung 100 zu wahren, gleichzeitig aber den Callback-Handler 316 auszuführen, wie nachfolgend beschrieben. Zusätzlich oder alternativ kann die Rechenvorrichtung 100 in einigen Ausführungsformen - wenn der Non-Root-Hypervisor 306 vom Root-Hypervisor 320 als vertrauenswürdig betrachtet wird - im VMX-Root-Modus bleiben, während der Callback-Handler 316 ausgeführt wird, was die Leistung verbessern kann. Im Block 522 führt die Rechenvorrichtung 100 den Callback-Handler 316 des Non-Root-Hypervisors 306 aus. Wenn der Callback-Handler 316 ausgeführt wird, kann der Callback-Handler 316 eine oder mehrere virtuelle VMX-Objekte 308 verändern. Eine potenzielle Ausführungsform eines Callback-Handlers 316 wird nachfolgend unter Bezugnahme auf 7 ausführlicher beschrieben.
  • Nachdem die Ausführung des Callback-Handlers 316 abgeschlossen ist, wird die Ausführung des Verfahrens 500 im Block 524 im VMX-Root-Modus wieder aufgenommen. Im Block 524 führt die Rechenvorrichtung 100 eine Überprüfung auf Aktualisierungen an den virtuellen VMX-Objekten 308 durch (z. B. der virtuellen VMCS 310 und/oder der virtuellen EPT 312), ausgeführt vom Non-Root-Hypervisor 306 während der Ausführung des Callback-Handlers 316. Die Rechenvorrichtung 100 kann jede Technik nutzen, um festzustellen, ob die virtuellen VMX-Objekte 308 aktualisiert wurden. Beispielsweise kann der Root-Hypervisor 320 vom Non-Root-Hypervisor 306 eine Non-Root-Hypervisor-Aktualisierungsliste 314 erhalten. Die Non-Root-Hypervisor-Aktualisierungsliste 314 identifiziert - ähnlich der Root-Hypervisor-Aktualisierungsliste 324 - virtuelle VMX-Objekte 308, Felder oder andere Daten der virtuellen VMX-Objekte 308, die vom Non-Root-Hypervisor 306 verändert wurden. Die Liste 314 kann als eine Bitmap verkörpert sein, die Felder der virtuellen VMCS 310 und/oder der virtuellen EPT 312 identifiziert, welche vom Non-Root-Hypervisor 306 geändert wurden. Im Block 526 stellt die Rechenvorrichtung 100 fest, ob die virtuellen VMX-Objekte 308 vom Non-Root-Hypervisor 306 geändert wurden. Falls nicht, verzweigt sich das Verfahren 500 nach vorn zum Block 530, in dem der Root-Hypervisor 320 einen VM-Eingang zu dem VMX-Non-Root-Modus ausführt, beispielsweise das Ausführen des Gastgeberbetriebssystems 302, der virtuellen Maschine 304 und/oder des Non-Root-Hypervisors 306 wieder aufnimmt. Wenn die virtuellen VMX-Objekte 308 geändert wurden, fährt das Verfahren 500 mit Block 528 fort.
  • Im Block 528 kopiert die Rechenvorrichtung 100 Aktualisierungen von den virtuellen VMX-Objekten 308 zu den VMX-Objekten 326. Die Rechenvorrichtung 100 kann nur jene virtuellen VMX-Objekte 308, Felder oder andere Daten kopieren, die verändert wurden, beispielsweise unter Verwendung der Non-Root-Hypervisor-Aktualisierungsliste 314. Wenn die Rechenvorrichtung 100 die aktualisierten Daten kopiert (oder noch vor dem Kopieren der aktualisierten Daten), kann der Root-Hypervisor 320 die Gültigkeit der Daten prüfen, die in den virtuellen VMX-Objekten 308 enthalten sind. Indem der Root-Hypervisor 320 nur gültige Daten kopiert, kann er somit die Sicherheit und Integrität der Virtualisierungsumgebung der Rechenvorrichtung 100 aufrechterhalten. Nach dem Kopieren der Aktualisierungen für die VMX-Objekte 326 fährt das Verfahren 500 mit Block 530 fort, in dem der Root-Hypervisor 320 einen VM-Eingang zu dem VMX-Non-Root-Modus ausführt, beispielsweise das Ausführen des Gastgeberbetriebssystems 302, der virtuellen Maschine 304 und/oder des Non-Root-Hypervisors 306 wieder aufnimmt. Nach dem Eintritt in den Non-Root-Modus wird das Verfahren 500 abgeschlossen.
  • Nunmehr Bezug nehmend auf 6, kann die Rechenvorrichtung 100 im Gebrauch ein Verfahren 600 zur Paravirtualisierung des Non-Root-Hypervisors ausführen. Das Verfahren 600 kann beispielsweise ausgeführt werden, wenn der Non-Root-Hypervisor 306 gestartet oder in Betrieb genommen wird oder anderweitig mit der Ausführung beginnt. Das Verfahren 600 beginnt im Block 602, in dem die Rechenvorrichtung 100 feststellt, ob der Non-Root-Hypervisor 306 im VMX-Non-Root-Modus unter der Kontrolle des Root-Hypervisors 320 ausgeführt wird. Beispielsweise wird der Non-Root-Hypervisor 306 in der Hypervisor-Umgebung 300 von 3 und im Verfahren 400 von 4 vom Gastgeberbetriebssystem 302 und/oder vom Root-Hypervisor 320 im VMX-Non-Root-Modus gestartet. In anderen Ausführungsformen kann der Non-Root-Hypervisor 306 jedoch ohne Präsenz des Root-Hypervisors 320 ausgeführt werden. Beispielsweise kann der Non-Root-Hypervisor 306 von einem Gastgeberbetriebssystem 302 gehostet werden, wenn der Root-Hypervisor 320 nicht aktiv ist, oder der Non-Root-Hypervisor 306 kann auf der Hardware der Rechenvorrichtung 100 als ein „Bare-Metal-Hypervisor“ ausgeführt werden. Der Non-Root-Hypervisor 306 kann jegliche Technik nutzen um festzustellen, ob der Non-Root-Hypervisor 306 im VMX-Non-Root-Modus unter der Kontrolle des Root-Hypervisors 320 ausgeführt wird. Beispielsweise kann der Non-Root-Hypervisor 306 feststellen, ob die Root-Hypervisor-API 318 verfügbar ist, oder der Non-Root-Hypervisor 306 kann eine oder mehrere Funktionen, Hypercalls, oder andere Routinen der Root-Hypervisor-API 318 aufrufen um festzustellen, ob der Root-Hypervisor 320 aktiv ist.
  • Im Block 604 prüft die Rechenvorrichtung 100, ob der Non-Root-Hypervisor 306 im VMX-Non-Root-Modus unter der Kontrolle des Root-Hypervisors 320 ausgeführt wird. Falls nicht, fährt das Verfahren 600 mit Block 606 fort, wo der Non-Root-Hypervisor 306 eine oder mehrere virtuelle Maschinen 304 im VMX-Root-Modus hosten kann. Folglich kann der Non-Root-Hypervisor 306 in bestimmten Ausführungsformen als älterer gehosteter Hypervisor agieren, der Teil der vertrauenswürdigen Rechenbasis der Rechenvorrichtung 100 ist. Erneut Bezug nehmend auf Block 604, fährt das Verfahren 600 mit Block 608 fort, wenn der Non-Root-Hypervisor 306 unter der Kontrolle des Root-Hypervisors 320 im VMX-Non-Root-Modus ausgeführt wird.
  • Im Block 608 bereitet die Rechenvorrichtung 100 die virtuellen VMX-Objekte 308 (z. B. die virtuelle VMCS 310 und/oder die virtuelle EPT 312) vor. Der Non-Root-Hypervisor 306 kann die virtuellen VMX-Objekte 308 vorbereiten, als seien sie tatsächliche VMX-Objekte 326, die durch die Virtualisierungsunterstützung des Prozessors 120 genutzt werden. Beispielsweise kann der Non-Root-Hypervisor 306 eine virtuelle VMCS 310 für jede virtuelle CPU und eine virtuelle EPT 312 für jede virtuelle Maschine 304 vorbereiten.
  • Im Block 610 registriert die Rechenvorrichtung 100 einen oder mehrere Callback-Handler 316 und Auslösebedingungen 334 beim Root-Hypervisor 320. Wie vorstehend beschrieben, kann jeder Callback-Handler 316 als eine Funktion, ein Verfahren, ein Vektor oder eine andere Routine des Non-Root-Hypervisors 306 verkörpert sein, die vom Root-Hypervisor 320 aktiviert werden können. Der Non-Root-Hypervisor 306 kann einen Callback-Handler 316 für einen oder mehrere potenzielle Gründe für einen VM-Ausgang registrieren. Jede Auslösebedingung 334 kann als eine Strategie, ein Filter oder ein anderer konditionaler Test verkörpert sein, der von dem Root-Hypervisor 320 überprüft werden kann. Wie nachfolgend ausführlicher beschrieben, werden die Auslösebedingungen 334 überprüft um festzustellen, ob der zugeordnete Callback-Handler 316 aufgerufen werden soll. Der Non-Root-Hypervisor 306 kann die Callback-Handler 316 und die Auslösebedingungen 334 durch einen oder mehrere Aufrufe an die Root-Hypervisor-API 318 registrieren. Beispielsweise kann der Non-Root-Hypervisor 306 einen oder mehrere Funktionsaufrufe, Hypercalls, Ausgänge einer virtuellen Maschine oder andere Schnittstellenelemente der API 318 aktivieren, um die Callback-Handler 316 und/oder Auslösebedingungen 334 zu registrieren, beispielsweise durch Vorlage eines Funktions-Pointers in Verbindung mit jedem Callback-Handler 316, von Pointern zu virtuellen VMX-Objekten 308 (z. B. Pointern zu einer virtuellen VMCS 310 und/oder virtuellen EPT 312) oder von anderen Daten.
  • Im Block 612 kann der Non-Root-Hypervisor 306 vom Root-Hypervisor 320 Aktualisierungen des VMX-Objekts 326 und/oder des VMX-Objektfeldes anfordern. Beispielsweise kann der Non-Root-Hypervisor 306 beim Registrieren des Callback-Handlers 316 ebenfalls zusätzliche Informationen liefern, wie Listen verlangter Feldaktualisierungen für die VMCS 328, die von dem Root-Hypervisor 320 auszuführen sind. Wie vorstehend in Verbindung mit 5 beschrieben, kann der Root-Hypervisor 320 während des Verarbeitens von VM-Ausgängen die angeforderten VMX-Objekte 326, Felder oder andere Daten kopieren oder dem Non-Root-Hypervisor 306 anderweitig verfügbar machen.
  • Im Block 614 hostet der Non-Root-Hypervisor 306 die virtuellen Maschinen 304 im VMX-Non-Root-Modus. Der Non-Root-Hypervisor 306 kann jede geeignete Technik nutzen, um die Ausführung der virtuellen Maschinen 304 zu starten. Beispielsweise kann der Non-Root-Hypervisor 306 einen VM-Eingang ausführen, der vom Root-Hypervisor 320 verarbeitet werden kann, um die virtuellen Maschinen 304 zu starten. Nach dem Starten der Ausführung der virtuellen Maschinen 304 ist das Verfahren 600 abgeschlossen. Wie vorstehend beschrieben, kann der Root-Hypervisor 320 während der Ausführung der virtuellen Maschinen 304 alle VM-Ausgänge verarbeiten, die von den virtuellen Maschinen 304 erzeugt wurden, und er kann wiederum ein oder mehrere Callback-Handler 316 aktivieren, wie nachfolgend ausführlicher in Verbindung mit 7 beschrieben wird.
  • Nunmehr Bezug nehmend auf 7, kann die Rechenvorrichtung 100 im Einsatz ein Verfahren 700 zum Non-Root-Callback-Verarbeiten ausführen. Das Verfahren 700 kann von dem Non-Root-Hypervisor 306 ausgeführt und im VMX-Non-Root-Modus mit beschränktem Zugriff auf die Rechenvorrichtung 100 ausgeführt werden. Das Verfahren 700 beginnt im Block 702, in dem die Rechenvorrichtung 100 den Callback-Handler 316 aktiviert. Wie oben in Verbindung mit den Blocks 520, 522 von 5 beschrieben, kann der Root-Hypervisor 320 in den VMX-Non-Root-Modus umschalten und dann den Callback-Handler 316 im VMX-Non-Root-Modus aktivieren.
  • Im Block 704 stellt die Rechenvorrichtung 100 fest, ob der Root-Hypervisor 320 Aktualisierungen für die VMX-Objekte 326 (z. B. die VMCS 328 und/oder die EPT 330) erzeugt hat. Die Rechenvorrichtung 100 kann jede Technik nutzen, um festzustellen, ob die VMX-Objekte 326 aktualisiert wurden. Beispielsweise kann der Non-Root-Hypervisor 306 die Root-Hypervisor-Aktualisierungsliste 324 vom Root-Hypervisor 320 erhalten oder anderweitig auf sie zugreifen. Wie vorstehend beschrieben, identifiziert die Root-Hypervisor-Aktualisierungsliste 324 VMX-Objekte 326, Felder oder andere Daten der VMX-Objekte 326, die vom Root-Hypervisor 320 verändert wurden. Die Liste 324 kann auch VMX-Objekte 326, Felder oder andere Daten identifizieren oder anderweitig beinhalten, zu deren Aktualisierung der Non-Root-Hypervisor 306 den Root-Hypervisor 320 aufgefordert hatte. Die Liste 324 kann als eine Bitmap verkörpert sein, die Felder der VMCS 328 und/oder der EPT 330 identifiziert, welche vom Root-Hypervisor 320 geändert wurden. Im Block 706 prüft die Rechenvorrichtung 100, ob VMX-Objekte 326 aktualisiert wurden. Falls nicht, fährt das Verfahren 700 mit Block 710 fort, wie nachfolgend beschrieben. Wenn die VMX-Objekte 326 aktualisiert wurden, wird das Verfahren 700 mit Block 708 fortgesetzt.
  • Im Block 708 kopiert die Rechenvorrichtung 100 Aktualisierungen von den VMX-Objekten 326 zu den virtuellen VMX-Objekten 308. Die Rechenvorrichtung 100 kann nur jene VMX-Objekte 326, Felder oder andere Daten kopieren, die verändert wurden, beispielsweise unter Verwendung der Root-Hypervisor-Aktualisierungsliste 324. In einigen Ausführungsformen kann der Non-Root-Hypervisor 306 durch einen oder mehrere Aufrufe an die Root-Hypervisor-API 318 Daten von den VMX-Objekten 326 kopieren. Zusätzlich oder alternativ kann dem Non-Root-Hypervisor 306 durch den Root-Hypervisor 320 Zugriff auf die VMX-Objekte 326 gewährt werden, beispielsweise durch Ausführung einer speziellen Prozessoranweisung wie VMFUNC.
  • In Block 710 führt die Rechenvorrichtung 100 ein Verarbeiten des VM-Ausgangs durch den Non-Root-Hypervisor 306 aus. Der Non-Root-Hypervisor 306 kann jedes geeignete Verarbeiten des VM-Ausgangs ausführen. Der Non-Root-Hypervisor 306 kann den VM-Ausgang unter Verwendung der virtuellen VMX-Objekte 308 so verarbeiten, als würde der Non-Root-Hypervisor 306 im VMX-Root-Modus ausgeführt. In einigen Ausführungsformen kann der Non-Root-Hypervisor 306 im Block 712 während des Verarbeitens des VM-Ausgangs ein oder mehrere virtuelle VMX-Objekte 308 verändern (z.B. die virtuelle VMCS 310 und/oder die virtuelle EPT 312).
  • Im Block 714, nach dem Verarbeiten des VM-Ausgangs, stellt die Rechenvorrichtung 100 fest, ob der Non-Root-Hypervisor 306 virtuelle VMX-Objekte 308 aktualisiert hat. Im Block 716 prüft die Rechenvorrichtung 100, ob die virtuellen VMX-Objekte 308 aktualisiert wurden. Falls nicht, verzweigt das Verfahren 700 vorwärts zum Block 720, in dem die Rechenvorrichtung 100 den Callback-Handler 316 verlässt und die Ausführung mit dem Root-Hypervisor 320 wieder aufnimmt; beispielsweise nimmt sie die Ausführung am Block 524 von 5 wieder auf. Erneut Bezug nehmend auf Block 716 - falls die virtuellen VMX-Objekte 308 aktualisiert wurden - fährt das Verfahren 700 mit Block 718 fort, in dem die Rechenvorrichtung 100 eine Non-Root-Hypervisor-Aktualisierungsliste 314 erstellt, die die virtuellen VMX-Objekte 308, Felder oder andere Daten identifiziert, die von dem Non-Root-Hypervisor 306 verändert wurden. Beispielsweise kann die Liste 314 als eine Bitmap verkörpert sein, die bestimmte Felder der virtuellen VMCS 310 und/oder der virtuellen EPT 312 identifiziert, welche vom Non-Root-Hypervisor 306 geändert wurden. Nach dem Erarbeiten der Liste 314 wird das Verfahren 700 bei Block 720 fortgesetzt, in dem die Rechenvorrichtung 100 den Callback-Handler 316 verlässt und die Ausführung mit dem Root-Hypervisor 320 wieder aufnimmt, wie oben beschrieben. Beispielsweise kann die Rechenvorrichtung 100 in einigen Ausführungsformen einen Eingang einer virtuellen Maschine ausführen, um den Callback-Handler 316 zu verlassen und im VMX-Root-Modus zum Root-Hypervisor 320 zurückzukehren. Nach der Wiederaufnahme der Ausführung mit dem Root-Hypervisor 320 ist das Verfahren 700 abgeschlossen.
  • BEISPIELE
  • Nachfolgend werden illustrative Beispiele der hierin offenbarten Technologien aufgeführt. Eine Ausführungsform der Technologien kann eines oder mehrere der nachfolgend beschriebenen Beispiele und jegliche Kombinationen von ihnen beinhalten.
  • Beispiel 1 beinhaltet eine Rechenvorrichtung für mehrstufige Virtualisierung, wobei die Rechenvorrichtung einen Prozessor beinhaltet, der Unterstützung im Root-Virtualisierungsmodus und Unterstützung im Non-Root-Virtualisierungsmodus bietet; und eine oder mehrere Speichervorrichtungen, in denen eine Vielzahl von Anweisungen gespeichert ist, die, wenn sie durch den Prozessor ausgeführt werden, veranlassen, dass die Rechenvorrichtung durch einem Root-Hypervisor der Rechenvorrichtung einen virtuellen Maschinenausgang empfängt, der von einer virtuellen Maschine der Rechenvorrichtung erzeugt wurde, wobei die virtuelle Maschine von einem Non-Root-Hypervisor der Rechenvorrichtung gehostet wird; durch den Root-Hypervisor im Root-Virtualisierungsmodus feststellt, ob ein Callback-Handler des Non-Root-Hypervisors für einen Ausgangsgrund des Ausgangs der virtuellen Maschine in Reaktion auf einen Empfang des Ausgangs der virtuellen Maschine registriert ist; in Reaktion auf eine Feststellung, dass der Callback-Handler registriert ist durch den Root-Hypervisor im Root-Virtualisierungsmodus feststellt, ob eine Auslösebedingung im Zusammenhang mit dem Callback-Handler erfüllt ist; und den Callback-Handler des Non-Root-Hypervisors in Reaktion auf eine Feststellung, dass die Auslösebedingung erfüllt ist, ausführt.
  • Beispiel 2 beinhaltet den Gegenstand von Beispiel 1, wobei die Vielzahl von Anweisungen, wenn sie durch den Prozessor ausgeführt werden, die Rechenvorrichtung ferner veranlassen, durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf eine Feststellung, dass ein Callback-Handler des Non-Root-Hypervisors für den Ausgangsgrund des Ausgangs der virtuellen Maschinen nicht registriert ist, den Ausgang der virtuellen Maschine zu verarbeiten; und die Ausführung der virtuellen Maschine in Reaktion auf das Verarbeiten des Ausgangs der virtuellen Maschine durch den Root-Hypervisor wieder aufzunehmen.
  • Beispiel 3 beinhaltet den Gegenstand von einem der Beispiele 1 und 2, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen, in Reaktion auf eine Feststellung, dass die Auslösebedingung nicht erfüllt ist, das Ausführen der virtuellen Maschine durch den Root-Hypervisor wieder aufzunehmen.
  • Beispiel 4 beinhaltet den Gegenstand von einem der Beispiele 1-3, wobei die mehreren Anweisungen, wenn sie durch den Prozessor ausgeführt werden, ferner die Rechenvorrichtung veranlassen, durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf den Empfang des Ausgangs der virtuellen Maschine das Virtualisierungsunterstützungsobjekt zu verändern; und in Reaktion auf eine Veränderung des Virtualisierungsunterstützungsobjekts eine Liste von Veränderungen am Virtualisierungsunterstützungsobjekt durch den Root-Hypervisor im Root-Virtualisierungsmodus zu erzeugen; wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors das Bereitstellen der Liste von Veränderungen am Virtualisierungsunterstützungsobjekt für den Non-Root-Hypervisor umfasst.
  • Beispiel 5 beinhaltet den Gegenstand von einem der Beispiele 1-4, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor ferner die Rechenvorrichtung veranlassen, durch den Non-Root-Hypervisor das virtuelle Virtualisierungsunterstützungsobjekt auf der Grundlage des Virtualisierungsunterstützungsobjekts durch die Liste von Veränderungen an dem Virtualisierungsunterstützungsobjekt zu aktualisieren.
  • Beispiel 6 beinhaltet den Gegenstand von einem der Beispiele 1-5, wobei das Virtualisierungsunterstützungsobjekt eine Struktur zur Steuerung einer virtuellen Maschine (VMCS) umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle VMCS umfasst.
  • Beispiel 7 beinhaltet den Gegenstand von einem der Beispiele 1-6, wobei das Virtualisierungsunterstützungsobjekt eine Extended Page Table umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle Extended Page Table umfasst.
  • Beispiel 8 beinhaltet den Gegenstand von einem der Beispiele 1-7, wobei die mehreren Answeisungen, wenn sie von dem Prozessor ausgeführt werden, ferner die Rechenvorrichtung veranlassen, durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob in Reaktion auf die Ausführung des Callback-Handlers ein virtuelles Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde; in Reaktion auf eine Feststellung, dass das virtuelle Virtualisierungsunterstützungsobjekt verändert wurde, ein Virtualisierungsunterstützungsobjekt der Rechenvorrichtung auf der Grundlage des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor im Root-Virtualisierungsmodus zu aktualisieren; und die Ausführung der virtuellen Maschine in Reaktion auf eine Aktualisierung des Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor wieder aufzunehmen.
  • Beispiel 9 beinhaltet den Gegenstand von einem der Beispiele 1-8, wobei das Aktualisieren des Virtualisierungsunterstützungsobjekts ferner das Überprüfen der Gültigkeit des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor umfasst.
  • Beispiel 10 beinhaltet den Gegenstand von einem der Beispiele 1-9, wobei die mehreren Anweisungen, wenn sie durch den Prozessor ausgeführt werden, ferner die Rechenvorrichtung veranlassen, durch den Non-Root-Hypervisor in Reaktion auf die Ausführung des Callback-Handlers das virtuelle Virtualisierungsunterstützungsobjekt zu verändern; und in Reaktion auf eine Veränderung des virtuellen Virtualisierungsunterstützungsobjekts eine Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt durch den Non-Root-Hypervisor zu erzeugen; wobei das Feststellen, ob das virtuelle Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde, die Feststellung durch den Root-Hypervisor umfasst, ob das virtuelle Virtualisierungsunterstützungsobjekt auf der Grundlage einer Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt verändert wurde.
  • Beispiel 11 beinhaltet den Gegenstand von einem der Beispiele 1-10, wobei das Virtualisierungsunterstützungsobjekt eine Struktur zur Steuerung einer virtuellen Maschine (VMCS) umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle VMCS umfasst.
  • Beispiel 12 beinhaltet den Gegenstand von einem der Beispiele 1-11, wobei das Virtualisierungsunterstützungsobjekt eine Extended Page Table umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle Extended Page Table umfasst.
  • Beispiel 13 beinhaltet den Gegenstand von einem der Beispiele 1-12, wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors das Ausführen des Callback-Handlers des Non-Root-Hypervisors im Non-Root-Virtualisierungsmodus des Prozessors umfasst.
  • Beispiel 14 beinhaltet den Gegenstand von einem der Beispiele 1-13, wobei die mehreren Answeisungen bei Ausführung durch den Prozessor ferner die Rechenvorrichtung veranlassen, durch den Non-Root-Hypervisor festzustellen, ob der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird; und durch den Non-Root-Hypervisor den Callback-Handler und die zugeordnete Auslösebedingung beim Root-Hypervisor zu registrieren, in Reaktion auf eine Feststellung, dass der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird.
  • Beispiel 15 beinhaltet den Gegenstand von einem der Beispiele 1-14, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor ferner die Rechenvorrichtung veranlassen, in Reaktion auf eine Feststellung, dass der Non-Root-Hypervisor nicht im Non-Root-Virtualisierungsmodus ausgeführt wird, die virtuelle Maschine durch den Non-Root-Hypervisor im Root-Virtualisierungsmodus zu hosten.
  • Beispiel 16 beinhaltet den Gegenstand von einem der Beispiele 1-15, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor ferner die Rechenvorrichtung veranlassen, durch den Root-Hypervisor im Root-Virtualisierungsmodus das Ausführen des Non-Root-Hypervisors zu überwachen.
  • Beispiel 17 beinhaltet den Gegenstand von einem der Beispiele 1-16, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor ferner die Rechenvorrichtung veranlassen, durch den Root-Hypervisor im Root-Virtualisierungsmodus das Ausführen eines Gastgeberbetriebssystems der Rechenvorrichtung zu überwachen, wobei das Gastgeberbetriebssystem den Non-Root-Hypervisor hostet.
  • Beispiel 18 beinhaltet ein Verfahren für mehrstufige Virtualisierung, wobei das Verfahren das Empfangen eines von einer virtuellen Maschine der Rechenvorrichtung erzeugten Ausgangs einer virtuellen Maschine durch einen Root-Hypervisor einer Rechenvorrichtung, wobei die virtuelle Maschine von einem Non-Root-Hypervisor der Rechenvorrichtung gehostet wird; das Feststellen =, durch den Root-Hypervisor in einem Root-Virtualisierungsmodus eines Prozessors der Rechenvorrichtung, ob ein Callback-Handler des Non-Root-Hypervisors für einen Ausgangsgrund des Ausgangs der virtuellen Maschine in Reaktion auf einen Empfang des Ausgangs der virtuellen Maschine registriert ist; in Reaktion auf eine Feststellung, dass der Callback-Handler registriert ist, das Feststellen, durch den Root-Hypervisor im Root-Virtualisierungsmodus, ob eine Auslösebedingung im Zusammenhang mit dem Callback-Handler erfüllt ist; und das Ausführen des Callback-Handlers des Non-Root-Hypervisors in Reaktion auf eine Feststellung, dass die Auslösebedingung erfüllt ist, durch die Rechenvorrichtung umfasst.
  • Beispiel 19 beinhaltet den Gegenstand von Beispiel 18, und durch den Root-Hypervisor im Root-Virtualisierungsmodus Ausgang der virtuellen Maschine in Reaktion auf eine Feststellung, dass ein Callback-Handler des Non-Root-Hypervisors für den Ausgangsgrund des Ausgangs der virtuellen Maschine nicht registriert ist; und Wiederaufnahme der Ausführung der virtuellen Maschine in Reaktion auf das Verarbeiten des Ausgangs der virtuellen Maschine durch den Root-Hypervisor.
  • Beispiel 20 beinhaltet den Gegenstand von einem der Beispiele 18 und 19, und beinhaltet ferner die Wiederaufnahme des Ausführens der virtuellen Maschine in Reaktion auf die Feststellung, dass die Auslösebedingung nicht erfüllt ist, durch den Root-Hypervisor.
  • Beispiel 21 beinhaltet den Gegenstand von einem der Beispiele 18-20 und beinhaltet ferner das Verändern eines Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf den Empfang des Ausgangs der virtuellen Maschine; und Erzeugen einer Liste von Veränderungen am Virtualisierungsunterstützungsobjekt durch den Root-Hypervisor im Root-Virtualisierungsmodus; wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors das Bereitstellen der Liste von Veränderungen am Virtualisierungsunterstützungsobjekt für den Non-Root-Hypervisor umfasst.
  • Beispiel 22 beinhaltet den Gegenstand von einem der Beispiele 18-21 und beinhaltet ferner das Aktualisieren eines virtuellen Virtualisierungsunterstützungsobjekts auf der Grundlage des Virtualisierungsunterstützungsobjekts unter Verwendung einer Liste von Veränderungen an dem Virtualisierungsunterstützungsobjekt durch den Non-Root-Hypervisor.
  • Beispiel 23 beinhaltet den Gegenstand von einem der Beispiele 18-22, wobei das Virtualisierungsunterstützungsobjekt eine Struktur zur Steuerung einer virtuellen Maschine (VMCS) umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle VMCS umfasst.
  • Beispiel 24 beinhaltet den Gegenstand von einem der Beispiele 18-23, wobei das Virtualisierungsunterstützungsobjekt eine Extended Page Table umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle Extended Page Table umfasst.
  • Beispiel 25 beinhaltet den Gegenstand von einem der Beispiele 18-24 und beinhaltet ferner die Feststellung durch den Root-Hypervisor im Root-Virtualisierungsmodus, ob in Reaktion auf die Ausführung des Callback-Handlers ein virtuelles Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde; in Reaktion auf eine Feststellung, dass das virtuelle Virtualisierungsunterstützungsobjekt verändert wurde, Aktualisieren eines Virtualisierungsunterstützungsobjekts der Rechenvorrichtung auf der Grundlage des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor im Root-Virtualisierungsmodus; und Wiederaufnahme der Ausführung der virtuellen Maschine in Reaktion auf eine Aktualisierung des Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor.
  • Beispiel 26 beinhaltet den Gegenstand von einem der Beispiele 18-25, wobei das Aktualisieren des Virtualisierungsunterstützungsobjekts ferner das Überprüfen der Gültigkeit des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor umfasst.
  • Beispiel 27 beinhaltet den Gegenstand von einem der Beispiele 18-26 und beinhaltet ferner, durch den Non-Root-Hypervisor in Reaktion auf die Ausführung des Callback-Handlers das Verändern des virtuellen Virtualisierungsunterstützungsobjekts; und in Reaktion auf eine Veränderung des virtuellen Virtualisierungsunterstützungsobjekts das Erzeugen einer Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt durch den Non-Root-Hypervisor; wobei das Feststellen, ob das virtuelle Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde, umfasst, durch den Root-Hypervisor festzustellen, ob das virtuelle Virtualisierungsunterstützungsobjekt auf der Grundlage der Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt verändert wurde.
  • Beispiel 28 beinhaltet den Gegenstand von einem der Beispiele 18-27, wobei das Virtualisierungsunterstützungsobjekt eine Struktur zur Steuerung einer virtuellen Maschine (VMCS) umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle VMCS umfasst.
  • Beispiel 29 beinhaltet den Gegenstand von einem der Beispiele 18-28, wobei das Virtualisierungsunterstützungsobjekt eine Extended Page Table umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle Extended Page Table umfasst.
  • Beispiel 30 beinhaltet den Gegenstand von einem der Beispiele 18-29, wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors das Ausführen des Callback-Handlers des Non-Root-Hypervisors in einem Non-Root-Virtualisierungsmodus des Prozessors der Rechenvorrichtung umfasst.
  • Beispiel 31 beinhaltet den Gegenstand von einem der Beispiele 18-30 und beinhaltet ferner, durch den Non-Root-Hypervisor festzustellen, ob der Non-Root-Hypervisor in einem Non-Root-Virtualisierungsmodus des Prozessors der Rechenvorrichtung ausgeführt wird; und durch den Non-Root-Hypervisor Registrieren des Callback-Handlers und der zugeordneten Auslösebedingung beim Root-Hypervisor in Reaktion auf eine Feststellung, dass der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird.
  • Beispiel 32 beinhaltet den Gegenstand von einem der Beispiele 18-31 und beinhaltet ferner ein Hosting der virtuellen Maschine durch den Non-Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf die Feststellung, dass der Non-Root-Hypervisor nicht im Non-Root-Virtualisierungsmodus ausgeführt wird.
  • Beispiel 33 beinhaltet den Gegenstand von einem der Beispiele 18-32 und beinhaltet ferner das Überwachen der Ausführung des Non-Root-Hypervisors durch den Root-Hypervisor im Root-Virtualisierungsmodus.
  • Beispiel 34 beinhaltet den Gegenstand von einem der Beispiele 18-33 und beinhaltet ferner das Überwachen der Ausführung eines Gastgeberbetriebssystems der Rechenvorrichtung durch den Root-Hypervisor im Root-Virtualisierungsmodus, wobei das Gastgeberbetriebssystem den Non-Root-Hypervisor hostet.
  • Beispiel 35 beinhaltet eine Rechenvorrichtung, die einen Prozessor; und einen Speicher umfasst, in dem mehrere Anweisungen gespeichert sind, die bei Ausführung durch den Prozessor die Rechenvorrichtung veranlassen, das Verfahren von einem der Beispiele 18-34 auszuführen.
  • Beispiel 36 beinhaltet ein oder mehrere maschinenlesbare Speichermedien, die mehrere Anweisungen umfassen, die auf ihnen gespeichert sind und die in Reaktion auf ihr Ausführen darin resultieren, dass eine Rechenvorrichtung das Verfahren aus einem der Beispiele 18-34 ausführt.
  • Beispiel 37 beinhaltet eine Rechenvorrichtung, die ein Mittel zum Ausführen des Verfahrens von einem der Beispiele 18-34 umfasst.
  • Beispiel 38 beinhaltet eine Rechenvorrichtung für mehrstufige Virtualisierung, wobei die Rechenvorrichtung Mittel zum Empfangen eines von einer virtuellen Maschine der Rechenvorrichtung erzeugten Ausgangs einer virtuellen Maschine durch einen Root-Hypervisor der Rechenvorrichtung, wobei die virtuelle Maschine von einem Non-Root-Hypervisor der Rechenvorrichtung gehostet wird; Mittel, um durch den Root-Hypervisor in einem Root-Virtualisierungsmodus eines Prozessors der Rechenvorrichtung festzustellen, ob ein Callback-Handler des Non-Root-Hypervisors für einen Ausgangsgrund des Ausgangs der virtuellen Maschine in Reaktion auf einen Empfang des Ausgangs der virtuellen Maschine registriert ist; Mittel, um in Reaktion auf eine Feststellung, dass der Callback-Handler registriert ist, durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob eine Auslösebedingung im Zusammenhang mit dem Callback-Handler erfüllt ist; und Mittel zum Ausführen des Callback-Handlers des Non-Root-Hypervisors in Reaktion auf eine Feststellung, dass die Auslösebedingung erfüllt ist, umfasst.
  • Beispiel 39 beinhaltet den Gegenstand von Beispiel 38 und beinhaltet ferner Mittel zum Verarbeiten des Ausgangs der virtuellen Maschine durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf eine Feststellung, dass ein Callback-Handler des Non-Root-Hypervisors für den Ausgangsgrund des Ausgangs der virtuellen Maschine nicht registriert ist; und Mittel zur Wiederaufnahme der Ausführung der virtuellen Maschine in Reaktion auf das Verarbeiten des Ausgangs der virtuellen Maschine durch den Root-Hypervisor.
  • Beispiel 40 beinhaltet den Gegenstand von einem der Beispiele 38 und 39, und beinhaltet ferner Mittel zum Wiederaufnehmen des Ausführens der virtuellen Maschine in Reaktion auf die Feststellung, dass die Auslösebedingung nicht erfüllt ist, durch den Root-Hypervisor.
  • Beispiel 41 beinhaltet den Gegenstand von einem der Beispiele 38-40 und beinhaltet ferner Mittel zum Verändern eines Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf den Empfang des Ausgangs der virtuellen Maschine; und Mittel zum Erzeugen einer Liste von Veränderungen am Virtualisierungsunterstützungsobjekt durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf eine Veränderung des Virtualisierungsunterstützungsobjekts; wobei das Mittel zum Ausführen des Callback-Handlers des Non-Root-Hypervisors Mittel zum Bereitstellen der Liste von Veränderungen am Virtualisierungsunterstützungsobjekt für den Non-Root-Hypervisor umfasst.
  • Beispiel 42 beinhaltet den Gegenstand von einem der Beispiele 38-41 und beinhaltet ferner Mittel zum Aktualisieren eines virtuellen Virtualisierungsunterstützungsobjekts auf der Grundlage des Virtualisierungsunterstützungsobjekts unter Verwendung einer Liste von Veränderungen an dem Virtualisierungsunterstützungsobjekt durch den Non-Root-Hypervisor.
  • Beispiel 43 beinhaltet den Gegenstand von einem der Beispiele 38-42, wobei das Virtualisierungsunterstützungsobjekt eine Struktur zur Steuerung einer virtuellen Maschine (VMCS) umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle VMCS umfasst.
  • Beispiel 44 beinhaltet den Gegenstand von einem der Beispiele 38-43, wobei das Virtualisierungsunterstützungsobjekt eine Extended Page Table umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle Extended Page Table umfasst.
  • Beispiel 45 beinhaltet den Gegenstand von einem der Beispiele 38-44 und beinhaltet ferner Mittel, um durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob in Reaktion auf die Ausführung des Callback-Handlers ein virtuelles Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde; Mittel, um in Reaktion auf eine Feststellung, dass das virtuelle Virtualisierungsunterstützungsobjekt verändert wurde, ein Virtualisierungsunterstützungsobjekt der Rechenvorrichtung auf der Grundlage des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor im Root-Virtualisierungsmodus zu aktualisieren; und Mittel für die Wiederaufnahme der Ausführung der virtuellen Maschine in Reaktion auf das Aktualisieren des Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor.
  • Beispiel 46 beinhaltet den Gegenstand von einem der Beispiele 38-45, wobei das Mittel zum Aktualisieren des Virtualisierungsunterstützungsobjekts ferner Mittel zum Überprüfen der Gültigkeit des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor umfasst.
  • Beispiel 47 beinhaltet den Gegenstand von einem der Beispiele 38-46 und beinhaltet ferner Mittel, um durch den Non-Root-Hypervisor in Reaktion auf die Ausführung des Callback-Handlers das virtuelle Virtualisierungsunterstützungsobjekt zu verändern; und Mittel, um in Reaktion auf eine Veränderung des virtuellen Virtualisierungsunterstützungsobjekts eine Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt durch den Non-Root-Hypervisor zu erzeugen; wobei das Mittel um festzustellen, ob das virtuelle Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde, Mittel umfasst, um durch den Root-Hypervisor festzustellen, ob das virtuelle Virtualisierungsunterstützungsobjekt auf der Grundlage der Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt verändert wurde.
  • Beispiel 48 beinhaltet den Gegenstand von einem der Beispiele 38-47, wobei das Virtualisierungsunterstützungsobjekt eine Struktur zur Steuerung einer virtuellen Maschine (VMCS) umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle VMCS umfasst.
  • Beispiel 49 beinhaltet den Gegenstand von einem der Beispiele 38-48, wobei das Virtualisierungsunterstützungsobjekt eine Extended Page Table umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle Extended Page Table umfasst.
  • Beispiel 50 beinhaltet den Gegenstand von einem der Beispiele 38-49, wobei das Mittel zum Ausführen des Callback-Handlers des Non-Root-Hypervisors Mittel zum Ausführen des Callback-Handlers des Non-Root-Hypervisors in einem Non-Root-Virtualisierungsmodus des Prozessors der Rechenvorrichtung umfasst.
  • Beispiel 51 beinhaltet den Gegenstand von einem der Beispiele 38-50 und beinhaltet ferner Mittel, um durch den Non-Root-Hypervisor festzustellen, ob der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus des Prozessors der Rechenvorrichtung ausgeführt wird; und Mittel zum Registrieren des Callback-Handlers und der zugeordneten Auslösebedingung beim Root-Hypervisor in Reaktion auf eine Feststellung, dass der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird, durch den Non-Root-Hypervisor.
  • Beispiel 52 beinhaltet den Gegenstand von einem der Beispiele 38-51 und beinhaltet ferner Mittel für ein Hosting der virtuellen Maschine durch den Non-Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf die Feststellung, dass der Non-Root-Hypervisor nicht im Non-Root-Virtualisierungsmodus ausgeführt wird.
  • Beispiel 53 beinhaltet den Gegenstand von einem der Beispiele 38-52 und beinhaltet ferner Mittel zum Überwachen der Ausführung des Non-Root-Hypervisors durch den Root-Hypervisor im Root-Virtualisierungsmodus.
  • Beispiel 54 beinhaltet den Gegenstand von einem der Beispiele 38-53 und beinhaltet ferner Mittel zum Überwachen der Ausführung eines Gastgeberbetriebssystems der Rechenvorrichtung durch den Root-Hypervisor im Root-Virtualisierungsmodus, wobei das Gastgeberbetriebssystem den Non-Root-Hypervisor hostet.

Claims (25)

  1. Rechenvorrichtung für mehrstufige Virtualisierung, wobei die Rechenvorrichtung Folgendes umfasst: einen Prozessor mit Unterstützung für den Root-Virtualisierungsmodus und Unterstützung für den Non-Root-Virtualisierungsmodus; und eine oder mehrere Speichervorrichtungen, in denen mehrere Anweisungen gespeichert sind, die bei Ausführung durch den Prozessor die Rechenvorrichtung veranlassen: durch einen Root-Hypervisor der Rechenvorrichtung einen Ausgang einer virtuellen Maschine zu empfangen, der erzeugt wurde durch eine virtuelle Maschine der Rechenvorrichtung, wobei die virtuelle Maschine von einem Non-Root-Hypervisor der Rechenvorrichtung gehostet wird; durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob ein Callback-Handler des Non-Root-Hypervisors für einen Ausgangsgrund des Ausgangs der virtuellen Maschine in Reaktion auf den Empfang des Ausgangs der virtuellen Maschine registriert ist; durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf eine Feststellung, dass der Callback-Handler registriert ist, festzustellen, ob eine Auslösebedingung in Verbindung mit dem Callback-Handler erfüllt ist; und den Callback-Handler des Non-Root-Hypervisors in Reaktion auf eine Feststellung, dass die Auslösebedingung erfüllt ist, auszuführen.
  2. Rechenvorrichtung nach Anspruch 1, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen: durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf eine Feststellung, dass ein Callback-Handler des Non-Root-Hypervisors für den Ausgangsgrund des Ausgangs der virtuellen Maschine nicht registriert ist, den Ausgang der virtuellen Maschine zu verarbeiten; und durch den Root-Hypervisor in Reaktion auf das Verarbeiten des Ausgangs der virtuellen Maschine das Ausführen der virtuellen Maschine wieder aufzunehmen.
  3. Rechenvorrichtung nach Anspruch 1, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen, in Reaktion auf eine Feststellung, dass die Auslösebedingung nicht erfüllt ist, das Ausführen der virtuellen Maschine durch den Root-Hypervisor wieder aufzunehmen.
  4. Rechenvorrichtung nach Anspruch 1, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen: durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf den Empfang des Ausgangs der virtuellen Maschine das Virtualisierungsunterstützungsobjekt zu verändern; und durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf ein Verändern des Virtualisierungsunterstützungsobjekts eine Liste von Veränderungen am Virtualisierungsunterstützungsobjekt zu erzeugen; wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors umfasst, dem Non-Root-Hypervisor die Liste von Veränderungen an dem Virtualisierungsunterstützungsobjekt zur Verfügung zu stellen.
  5. Rechenvorrichtung nach Anspruch 4, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen, durch den Non-Root-Hypervisor das virtuelle Virtualisierungsunterstützungsobjekt auf der Grundlage des Virtualisierungsunterstützungsobjekts durch die Liste von Veränderungen an dem Virtualisierungsunterstützungsobjekt zu aktualisieren.
  6. Rechenvorrichtung nach Anspruch 5, wobei: das Virtualisierungsunterstützungsobjekt eine Struktur zur Steuerung einer virtuellen Maschine (Virtual Machine Control Structure, VMCS) oder eine Extended Page Table umfasst; und das virtuelle Virtualisierungsunterstützungsobjekt eine virtuelle VMCS oder eine virtuelle Extended Page Table umfasst.
  7. Rechenvorrichtung nach einem der Ansprüche 1-6, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen: durch den Root-Hypervisor im Root-Virtualisierungsmodus festzustellen, ob ein virtuelles Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors in Reaktion auf das Ausführen des Callback-Handlers verändert wurde; durch den Root-Hypervisor im Root-Virtualisierungsmodus ein Virtualisierungsunterstützungsobjekt der Rechenvorrichtung zu aktualisieren, basierend auf dem virtuellen Virtualisierungsunterstützungsobjekt in Reaktion auf eine Feststellung, dass das virtuelle Virtualisierungsunterstützungsobjekt verändert wurde; und durch den Root-Hypervisor in Reaktion auf eine Aktualisierung des Virtualisierungsunterstützungsobjekts das Ausführen der virtuellen Maschine wieder aufzunehmen.
  8. Rechenvorrichtung nach Anspruch 7, wobei das Aktualisieren des Virtualisierungsunterstützungsobjekts ferner das Überprüfen der Gültigkeit des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor umfasst.
  9. Rechenvorrichtung nach Anspruch 7, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen: das virtuelle Virtualisierungsunterstützungsobjekt in Reaktion auf das Ausführen des Callback-Handlers durch den Non-Root-Hypervisor zu verändern; und in Reaktion auf das Verändern des virtuellen Virtualisierungsunterstützungsobjekts durch den Non-Root-Hypervisor eine Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt zu erzeugen; wobei die Feststellung, ob das virtuelle Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde, die Feststellung durch den Root-Hypervisor umfasst, ob das virtuelle Virtualisierungsunterstützungsobjekt auf der Grundlage der Liste von Veränderungen an dem virtuellen Virtualisierungsunterstützungsobjekt verändert wurde.
  10. Rechenvorrichtung nach einem der Ansprüche 1-6, wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors das Ausführen des Callback-Handlers des Non-Root-Hypervisors im Non-Root-Virtualisierungsmodus des Prozessors umfasst.
  11. Rechenvorrichtung nach einem der Ansprüche 1-6, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen: durch den Non-Root-Hypervisor festzustellen, ob der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird; durch den Non-Root-Hypervisor den Callback-Handler und die zugehörige Auslösebedingung beim Root-Hypervisor in Reaktion auf eine Feststellung zu registrieren, dass der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird; und im Root-Virtualisierungsmodus in Reaktion auf eine Feststellung, dass der Non-Root-Hypervisor nicht im Non-Root-Virtualisierungsmodus ausgeführt wird, die virtuelle Maschine durch den Non-Root-Hypervisor zu hosten.
  12. Rechenvorrichtung nach einem der Ansprüche 1-6, wobei die mehreren Anweisungen bei Ausführung durch den Prozessor die Rechenvorrichtung ferner veranlassen: durch den Root-Hypervisor im Root-Virtualisierungsmodus die Ausführung des Non-Root-Hypervisors zu überwachen; und die Ausführung eines Gastgeberbetriebssystems der Rechenvorrichtung durch den Root-Hypervisor im Root-Virtualisierungsmodus zu überwachen, wobei das Gastgeberbetriebssystem den Non-Root-Hypervisor hostet.
  13. Verfahren für mehrstufige Virtualisierung, wobei das Verfahren Folgendes umfasst: durch einen Root-Hypervisor einer Rechenvorrichtung das Empfangen eines Ausgangs einer virtuellen Maschine, der erzeugt wurde durch eine virtuelle Maschine der Rechenvorrichtung, wobei die virtuelle Maschine von einem Non-Root-Hypervisor der Rechenvorrichtung gehostet wird; durch den Root-Hypervisor in einem Root-Virtualisierungsmodus eines Prozessors der Rechenvorrichtung das Feststellen, ob ein Callback-Handler des Non-Root-Hypervisors für einen Ausgangsgrund des Ausgangs der virtuellen Maschine in Reaktion auf den Empfang des Ausgangs der virtuellen Maschine registriert ist; durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf eine Feststellung, dass der Callback-Handler registriert ist, das Feststellen, ob eine Auslösebedingung in Verbindung mit dem Callback-Handler erfüllt ist; und durch die Rechenvorrichtung in Reaktion auf die Feststellung, dass die Auslösebedingung erfüllt ist, das Ausführen des Callback-Handlers des Non-Root-Hypervisors.
  14. Verfahren nach Anspruch 13, das ferner Folgendes umfasst: durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf die Feststellung, dass ein Callback-Handler des Non-Root-Hypervisors für den Ausgangsgrund des Ausgangs der virtuellen Maschine nicht registriert ist, das Verarbeiten des Ausgangs der virtuellen Maschine; und durch den Root-Hypervisor in Reaktion auf das Verarbeiten des Ausgangs der virtuellen Maschine das Wiederaufnehmen des Ausführens der virtuellen Maschine.
  15. Verfahren nach Anspruch 13, das ferner Folgendes umfasst: Verändern eines Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf den Empfang des Ausgangs der virtuellen Maschine; und Erzeugen einer Liste von Veränderungen am Virtualisierungsunterstützungsobjekt durch den Root-Hypervisor im Root-Virtualisierungsmodus in Reaktion auf das Verändern des Virtualisierungsunterstützungsobjekts; wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors umfasst, dem Non-Root-Hypervisor die Liste von Veränderungen an dem Virtualisierungsunterstützungsobjekt zur Verfügung zu stellen.
  16. Verfahren nach Anspruch 15, das ferner das Aktualisieren eines virtuellen Virtualisierungsunterstützungsobjekts auf der Grundlage des Virtualisierungsunterstützungsobjekts unter Verwendung der Liste von Veränderungen an dem Virtualisierungsunterstützungsobjekt durch den Non-Root-Hypervisor umfasst.
  17. Verfahren nach Anspruch 13, das ferner Folgendes umfasst: die Feststellung durch den Root-Hypervisor im Root-Virtualisierungsmodus, ob ein virtuelles Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors in Reaktion auf das Ausführen des Callback-Handlers verändert wurde; das Aktualisieren eines Virtualisierungsunterstützungsobjekts der Rechenvorrichtung durch den Root-Hypervisor im Root-Virtualisierungsmodus, basierend auf dem virtuellen Virtualisierungsunterstützungsobjekt in Reaktion auf die Feststellung, dass das virtuelle Virtualisierungsunterstützungsobjekt verändert wurde; und das Wiederaufnehmen des Ausführens der virtuellen Maschine durch den Root-Hypervisor in Reaktion auf das Aktualisieren des Virtualisierungsunterstützungsobjekts.
  18. Verfahren nach Anspruch 17, wobei das Aktualisieren des Virtualisierungsunterstützungsobjekts ferner das Überprüfen der Gültigkeit des virtuellen Virtualisierungsunterstützungsobjekts durch den Root-Hypervisor umfasst.
  19. Verfahren nach Anspruch 17, das ferner Folgendes umfasst: Verändern des virtuellen Virtualisierungsunterstützungsobjekts in Reaktion auf das Ausführen des Callback-Handlers durch den Non-Root-Hypervisor; und Erzeugen einer Liste von Veränderungen am virtuellen Virtualisierungsunterstützungsobjekt in Reaktion auf das Verändern des virtuellen Virtualisierungsunterstützungsobjekts durch den Non-Root-Hypervisor; wobei die Feststellung, ob das virtuelle Virtualisierungsunterstützungsobjekt des Non-Root-Hypervisors verändert wurde, die Feststellung durch den Root-Hypervisor umfasst, ob das virtuelle Virtualisierungsunterstützungsobjekt auf der Grundlage der Liste von Veränderungen an dem virtuellen Virtualisierungsunterstützungsobjekt verändert wurde.
  20. Verfahren nach Anspruch 13, wobei das Ausführen des Callback-Handlers des Non-Root-Hypervisors das Ausführen des Callback-Handlers des Non-Root-Hypervisors in einem Non-Root-Virtualisierungsmodus des Prozessors der Rechenvorrichtung umfasst.
  21. Verfahren nach Anspruch 13, das ferner Folgendes umfasst: Feststellen durch den Non-Root-Hypervisor, ob der Non-Root-Hypervisor in einem Non-Root-Virtualisierungsmodus des Prozessors der Rechenvorrichtung ausgeführt wird; und Registrieren des Callback-Handlers und der zugehörigen Auslösebedingung durch den Non-Root-Hypervisor beim Root-Hypervisor in Reaktion auf die Feststellung, dass der Non-Root-Hypervisor im Non-Root-Virtualisierungsmodus ausgeführt wird.
  22. Verfahren nach Anspruch 13, das ferner ein Überwachen der Ausführung des Non-Root-Hypervisors durch den Root-Hypervisor im Root-Virtualisierungsmodus umfasst.
  23. Rechenvorrichtung, die Folgendes umfasst: einen Prozessor, und einen Speicher, in dem mehrere Anweisungen gespeichert sind, die bei Ausführung durch den Prozessor die Rechenvorrichtung veranlassen, das Verfahren nach einem der Ansprüche 13-22 auszuführen.
  24. Maschinenlesbares Speichermedium oder mehrere maschinenlesbare Speichermedien, die mehrere Anweisungen umfassen, die auf ihnen gespeichert sind und die in Reaktion auf ihr Ausführen darin resultieren, dass eine Rechenvorrichtung das Verfahren nach einem der Ansprüche 13-22 ausführt.
  25. Rechenvorrichtung, die Mittel zum Ausführen des Verfahrens nach einem der Ansprüche 13-22 umfasst.
DE112016004297.3T 2015-09-25 2016-08-25 Technologien für mehrstufige virtualisierung Pending DE112016004297T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/866,187 US9747123B2 (en) 2015-09-25 2015-09-25 Technologies for multi-level virtualization
US14/866,187 2015-09-25
PCT/US2016/048681 WO2017052972A1 (en) 2015-09-25 2016-08-25 Technologies for multi-level virtualization

Publications (1)

Publication Number Publication Date
DE112016004297T5 true DE112016004297T5 (de) 2018-06-14

Family

ID=58386754

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112016004297.3T Pending DE112016004297T5 (de) 2015-09-25 2016-08-25 Technologien für mehrstufige virtualisierung

Country Status (4)

Country Link
US (1) US9747123B2 (de)
CN (1) CN107924325B (de)
DE (1) DE112016004297T5 (de)
WO (1) WO2017052972A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9274823B1 (en) * 2014-12-24 2016-03-01 Parallels IP Holdings GmbH Thin hypervisor for native execution of unsafe code
US20170329622A1 (en) * 2016-05-11 2017-11-16 Microsoft Technology Licensing, Llc Shared virtual data structure of nested hypervisors
US11726807B2 (en) * 2017-05-05 2023-08-15 Vmware, Inc. Safe execution of virtual machine callbacks in a hypervisor
US10936353B2 (en) * 2017-05-16 2021-03-02 Dell Products L.P. Systems and methods for hypervisor-assisted hardware accelerator offloads in a virtualized information handling system environment
US11016798B2 (en) 2018-06-01 2021-05-25 The Research Foundation for the State University Multi-hypervisor virtual machines that run on multiple co-located hypervisors
US11182184B2 (en) 2019-10-23 2021-11-23 Red Hat, Inc. Implementing high-performance virtual machines for bare metal simulation
US11144419B2 (en) * 2019-10-25 2021-10-12 Red Hat, Inc. Controlled use of a memory monitor instruction and memory wait instruction in a virtualized environment
US20230066447A1 (en) * 2021-08-24 2023-03-02 Hewlett-Packard Development Company, L.P. Execution of code in system memory
US20230305854A1 (en) * 2022-03-25 2023-09-28 Sap Se Reducing downtime during operating system patching

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
US8479195B2 (en) 2007-05-16 2013-07-02 Vmware, Inc. Dynamic selection and application of multiple virtualization techniques
US8032680B2 (en) * 2008-06-27 2011-10-04 Microsoft Corporation Lazy handling of end of interrupt messages in a virtualized environment
JP5405799B2 (ja) 2008-10-30 2014-02-05 株式会社日立製作所 仮想計算機の制御方法、仮想化プログラム及び仮想計算機システム
US9747118B2 (en) * 2009-01-06 2017-08-29 Intel Corporation Guest-specific microcode
US8495628B2 (en) * 2009-08-23 2013-07-23 International Business Machines Corporation Para-virtualization in a nested virtualization environment using reduced number of nested VM exits
US8479196B2 (en) 2009-09-22 2013-07-02 International Business Machines Corporation Nested virtualization performance in a computer system
US8327059B2 (en) * 2009-09-30 2012-12-04 Vmware, Inc. System and method to enhance memory protection for programs in a virtual machine environment
JP5493125B2 (ja) 2010-02-05 2014-05-14 株式会社日立製作所 仮想化方法及び計算機
US8819677B2 (en) * 2010-11-23 2014-08-26 International Business Machines Corporation Virtual machine data structures corresponding to nested virtualization levels
US8578080B2 (en) * 2011-07-01 2013-11-05 Intel Corporation Secure handling of interrupted events utilizing a virtual interrupt definition table
CN104106050B (zh) * 2011-12-22 2019-01-08 英特尔公司 允许高效的嵌套虚拟化
WO2013100921A1 (en) * 2011-12-28 2013-07-04 Intel Corporation Allocating memory access control policies
EP2867770B1 (de) * 2012-06-29 2020-05-27 Intel Corporation Verfahren, systeme und vorrichtung zur erfassung von fehlerzuständen in leichtgewichtigen verwaltungsvorrichtungen für virtuelle computer
WO2014100273A1 (en) * 2012-12-18 2014-06-26 Dynavisor, Inc. Dynamic device virtualization
US9268707B2 (en) * 2012-12-29 2016-02-23 Intel Corporation Low overhead paged memory runtime protection
CN104424034A (zh) * 2013-09-04 2015-03-18 华为技术有限公司 硬件资源访问方法及装置
US9454676B2 (en) * 2014-06-27 2016-09-27 Intel Corporation Technologies for preventing hook-skipping attacks using processor virtualization features

Also Published As

Publication number Publication date
WO2017052972A1 (en) 2017-03-30
CN107924325B (zh) 2022-02-18
CN107924325A (zh) 2018-04-17
US20170090963A1 (en) 2017-03-30
US9747123B2 (en) 2017-08-29

Similar Documents

Publication Publication Date Title
DE112016004297T5 (de) Technologien für mehrstufige virtualisierung
DE102006061939B4 (de) Verfahren und Vorrichtung zum Zugriff auf eine speicherabgebildete Vorrichtung durch einen Gast
DE102007062744B4 (de) Guest-Host-Adressübersetzung für den Zugriff von Geräten auf einen Speicher in einem partitionierten System
DE112004003080B4 (de) Verwendung mehrerer Monitore virtueller Maschinen zur Abwicklung privilegierter Ereignisse
DE112015006934T5 (de) Verschachtelte Virtualisierung für virtuelle Maschinenexits
Abels et al. An overview of xen virtualization
DE102018115670A1 (de) Technologien für die Ausführung von nicht vertrauenswürdigem Code mit Prozessor-Sandbox-Unterstützung
DE102012218379A1 (de) Paravirtualisierte virtuelle GPU
DE112007001714T5 (de) Virtualisieren von Leistungszählern
DE112012005209T5 (de) Brückenfunktion zwischen Virtual Machine Monitor und Bare-Metal-Bootvorgang
DE112011103845B4 (de) Verwalten einer verschachtelten virtualisierten Umgebung
DE112007001988T5 (de) Gemeinsames Nutzen von Informationen durch Gäste in einer Virtuelle-Maschine-Umgebung
DE102014003798A1 (de) Verfahren zum Booten eines heterogenen Systems und Präsentieren einer symmetrischen Kernansicht
US10853259B2 (en) Exitless extended page table switching for nested hypervisors
DE112004001652B4 (de) Vektorieren eines Interrupt oder einer Ausnahme bei Wiederaufnahme des Betriebes einer virtuellen Maschine
US10664304B2 (en) Application memory protection using an extended page table switching virtual machine function
DE112016005823T5 (de) Überwachen des betriebs eines prozessors
US10698713B2 (en) Virtual processor state switching virtual machine functions
DE202017007430U1 (de) Erkennen von Bussperrbedingungen und Vermeiden von Bussperren
DE112020000280T5 (de) Transparente interpretation von gastbefehlen in einer sicheren virtuellen maschinenumgebung
DE112017003332T5 (de) Öffnungszugriffsprozessoren, verfahren, systeme und befehle
DE102021103041A1 (de) Virtuelle vertrauenswürdige plattformmodule
DE102009060299A1 (de) Das Einführen von Transaktionen, um die Virtualisierung eines physischen Geräte-Controllers zu unterstützen
DE202019005683U1 (de) Prozessorkern mit Unterstützung einer Befehlssatzarchitektur für heterogene Systeme
DE112017001012T5 (de) Prozessoren, verfahren und systeme zum einstellen maximaler taktfrequenzen basierend auf dem befehlstyp

Legal Events

Date Code Title Description
R012 Request for examination validly filed