DE102007037814B4 - Synchronisieren eines Translation-Lookaside-Pufferspeichers mit einer erweiterten Paging-Tabelle - Google Patents

Synchronisieren eines Translation-Lookaside-Pufferspeichers mit einer erweiterten Paging-Tabelle Download PDF

Info

Publication number
DE102007037814B4
DE102007037814B4 DE102007037814.0A DE102007037814A DE102007037814B4 DE 102007037814 B4 DE102007037814 B4 DE 102007037814B4 DE 102007037814 A DE102007037814 A DE 102007037814A DE 102007037814 B4 DE102007037814 B4 DE 102007037814B4
Authority
DE
Germany
Prior art keywords
ept
instruction
operand
address
stored
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.)
Active
Application number
DE102007037814.0A
Other languages
English (en)
Other versions
DE102007037814A1 (de
Inventor
Steven M. Bennett
Andrew V. Anderson
Gilbert Neiger
Richard Uhlig
Dion Rodgers
Rajesh Madukkarumukumana
Camron Rust
Sebastian Schoenberg
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 DE102007037814A1 publication Critical patent/DE102007037814A1/de
Application granted granted Critical
Publication of DE102007037814B4 publication Critical patent/DE102007037814B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30047—Prefetch instructions; cache control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1036—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] for multiple virtual address spaces, e.g. segmentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1045—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] associated with a data cache
    • G06F12/1054—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] associated with a data cache the data cache being concurrently physically addressed
    • 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
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • 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/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/152—Virtualized environment, e.g. logically partitioned system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20—Employing a main memory using a specific memory technology
    • G06F2212/202—Non-volatile memory
    • G06F2212/2022—Flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/452—Instruction code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/50—Control mechanisms for virtual memory, cache or TLB
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/657—Virtual address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68—Details of translation look-aside buffer [TLB]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68—Details of translation look-aside buffer [TLB]
    • G06F2212/683—Invalidation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

Prozessor (318) eines auf Virtualisierung basierenden Systems (300), der umfasst:einen Translation-Lookaside-Puffer, TLB, (323) um ein Mapping von einer physikalischen Gastadresse (412, 432, 452) zu einer physikalischen Host-Adresse (404, 414, 424) zu speichern; undeine Logikschaltung (322, 332, 334), um eine Synchronisierung des Mappings von der physikalischen Gastadresse (412, 432, 452) zur physikalischen Host-Adresse (404, 414, 424), die im Translation-Lookaside-Puffer (323) gespeichert ist, mit einem entsprechenden Mapping, das in einer erweiterten Paging-Tabelle, EPT, (328; 455, 465, 475) gespeichert ist, durchzuführen,wobei das entsprechende Mapping ein in der EPT (328; 455, 465, 475) gespeichertes Mapping mit derselben physikalischen Gastadresse (412, 432, 452) wie das im TLB (323) gespeicherte Mapping aufweist,wobei die Synchronisierung auf dem Operanden eines Befehls basiert,wobei der Operand einen EPT-Zeiger umfasst, undwobei eine Abruflogik (330) ferner einen ersten Operanden des Befehls, einen zweiten Operanden des Befehls und einen dritten Operanden des Befehls empfängt;die Logikschaltung (322, 332, 334) fernerdas Mapping auswählt, das zumindest teilweise in der EPT (328; 455, 465, 475) gespeichert ist, basierend auf einer Kontextbezeichnung, die aus dem ersten Operanden des Befehls erhalten wird;die Gastadresse (412, 432,452) auswählt, zumindest teilweise basierend auf dem zweiten Operanden des Befehls; undeinen Ausführungsmodus des Befehls auswählt, basierend auf dem dritten Operanden des Befehls;und wobei es sich bei dem Ausführungsmodus des Befehls um einen der folgenden handelt;ein erster Modus, in welchem nur ein einziges in dem TLB (323) gespeichertes und zu der physikalischen Gastadresse (412, 432,452) gehörendes Mapping mit der entsprechenden Umsetzung in der EPT (328; 455, 465, 475) synchronisiert wird;ein zweiter Modus, in welchem alle Mappings, die in dem TLB (323) gespeichert sind und zu einem EPT-Kontext gehören, der aus der Kontextbezeichnung erhalten wird, mit den entsprechenden Mappings in der EPT (328; 455, 465, 475) synchronisiert werden, wobei die Synchronisation des Mappings ein Synchronisieren jener Einträge im TLB (323) in dem EPT-Kontext, der in dem EPT-Zeiger spezifiziert ist, mit der erweiterten Paging-Tabelle,EPT, (328; 455, 465, 475) umfasst; undein dritter Modus, in welchem alle Mappings, die in dem TLB (323) gespeichert sind und zu irgendeinem EPT-Kontext gehören, der aus der Kontextbezeichnung erhalten wird, mit den entsprechenden Mappings in einer EPT (328; 455, 465, 475) synchronisiert werden.

Description

  • Allgemeiner Stand der Technik
  • Die Virtualisierung ermöglicht einer einzelnen Host-Maschine mit Hardware- und Software-Unterstützung für die Virtualisierung, eine Abstraktion des Host-Rechners darzustellen, derart, daß die zugrunde liegende Hardware der Host-Maschine als eine oder mehrere unabhängig voneinander operierende virtuelle Maschinen erscheint. Jede virtuelle Maschine kann deswegen als in sich geschlossene Plattform fungieren. Oft wird die Virtualisierungstechnologie angewendet, um zu ermöglichen, daß mehrere Gastbetriebssysteme und/oder eine andere Gastsoftware koexistieren und scheinbar gleichzeitig und scheinbar unabhängig voneinander auf mehreren virtuellen Maschinen ausgeführt werden, obwohl sie tatsächlich real auf derselben Hardware-Plattform ausgeführt werden. Eine virtuelle Maschine kann die Hardware der Host-Maschine nachahmen oder alternativ eine gänzlich unterschiedliche Hardware-Abstraktion vorlegen.
  • Virtualisierungssysteme können einen Monitor der virtuellen Maschine (Virtual Machine Monitor, VMM) aufweisen, welcher die Host-Maschine steuert. Der VMM stellt der Gastsoftware, die in einer virtuellen Maschine arbeitet, einen Satz von Ressourcen (z.B. Prozessoren, Speicher, E/A-Einheiten) bereit. Der VMM kann einige oder alle der Komponenten einer physischen bzw. realen Host-Maschine in die virtuelle Maschine umsetzen und kann vollständig virtuelle Komponenten erzeugen, welche in Software in dem VMM emuliert sind und in der virtuellen Maschine enthalten sind (z.B. virtuelle E/A-Einheiten). Man kann daher sagen, daß der VMM der Gastsoftware eine Schnittstelle einer „unbestückten virtuellen Maschine“ bereitstellt. Der VMM verwendet Möglichkeiten in einer Hardware-Virtualisierungsarchitektur, um einer virtuellen
  • Maschine Dienste bereitzustellen und um Schutz vor und zwischen mehreren virtuellen Maschinen zu bieten, die auf der Host-Maschine ausgeführt werden. Wenn Gastsoftware in einer virtuellen Maschine ausgeführt wird, griffen bestimmte von der Gastsoftware ausgeführte Befehle (z.B., Befehle, die auf Peripherieeinheiten zugreifen) normalerweise direkt auf die Hardware zu, wenn die Gastsoftware direkt auf einer Hardware-Plattform ausgeführt würde. In einem Virtualisierungssystem, das von einem VMM unterstützt wird, können diese Befehle einen Übergang auf den VMM bewirken, was hierin als Ausstieg der virtuellen Maschine bezeichnet wird. Der VMM behandelt diese Befehle in einer Software auf eine Weise, die für die Host-Maschinen-Hardware und die Host-Maschinen-Peripherieeinheiten geeignet ist und mit den virtuellen Maschinen vereinbar ist, auf welchen die Gastsoftware ausgeführt wird. In ähnlicher Weise kann es sein, dass bestimmte Unterbrechungen und Ablaufunterbrechungen, die in der Host-Maschine erzeugt werden, vom VMM abgefangen und behandelt werden müssen oder durch den VMM für die Gastsoftware angepasst werden, bevor sie zur Abwicklung zur Gastsoftware weitergeleitet werden. Der VMM überträgt dann die Steuerung auf die Gastsoftware, und die virtuelle Maschine übernimmt wieder den Betrieb. Die Übertragung vom VMM auf die Gastsoftware wird hierin als Einstieg der virtuellen Maschine bezeichnet.
  • Wie auf dem Fachgebiet bekannt ist, wird eine Seitentabelle (page table) oft benutzt, um in einem typischen prozessorbasierten System für ein Mapping bzw. eine Umsetzung von einem linearen Speicher in einem realen Speicher zu sorgen. Bei Seitentabellen handelt es sich im Allgemeinen um speicherresidente Strukturen, und deswegen verursacht der Zugriff auf eine Seitentabelle, um eine physikalische oder reale Adresse zu ermitteln, die einer linearen Adresse entspricht, einen Speicherzugriff, wodurch die Verarbeitungszeit verlängert werden kann. Um diese Probleme zu verringern, weisen viele Prozessorimplementierungen einen Hochgeschwindigkeitsspeicher oder eine Registerbank innerhalb des Prozessors auf, welche als Adressenübersetzungs-Pufferspeicher (Translation Lookaside Buffer, TLB) bezeichnet werden, und in welchen basierend auf den Werten in der Seitentabelle eine gewisse Untergruppe der aktuellen Umsetzungen von linearem in realen Speicher, die in Verwendung sind, zwischengespeichert werden. Dies ermöglicht einem Prozessor, schneller auf eine Übersetzung einer linearen Adresse in die entsprechende reale Adresse zuzugreifen, als es im allgemeinen möglich wäre, wenn der Prozessor auf die Seitentabelle zugreifen müsste. Bei Prozessorimplementierungen werden im allgemeinen Befehle bereitgestellt, um den TLB zu verwalten, z.B. ein Befehl, um alle Einträge in den TLB basierend auf aktuellen Übersetzungen, wie sie in der Seitentabelle gespeichert sind, zu löschen oder zu aktualisieren.
  • Das Dokument „AMD64 Technology, AMD64 Architecture Programmer's Manual, Volume 2: System Programming, Publication No. 24593, Rev. 3.11, Dezember 2005, Seiten 464 und 465” zeigt einen Translation Lookaside Buffer (TLB) mit Adressraumidentifizierungsbereichen („Address Space Identifier“ ASID) für einzelne Host- und Gastsysteme. Es kann ein Befehl, „INVLPGA”, vorgesehen sein, welcher einem Virtual Machine Monitor (VMM) erlaubt, selektiv Einträge im TLB zu invalidieren.
  • Die US 2006/0161719 A1 und die EP 1 681 630 A1 beschreiben das Betreiben von virtuellen Maschinen auf einem Host-Rechner auf Basis des sogenannten EPT-Pagings. Hierbei wird eine Umsetzung einer physikalischen Gast-Adresse in eine physikalische Host-Adresse sowie das Konzept der Verwendung eines EPT-Zeigers im Detail erläutert. Die Verwendung eines TLB oder eine entsprechende Synchronisierung des TLB gemäß dem EPT-Kontext wird jedoch nicht beschrieben.
  • Die US 2004/0064668 A1 ist auf eine Speicheradressierung für eine virtuelle Maschine auf einem Prozessor mit Virtual Hash-Page-Table Searching-Unterstützung gerichtet. Hierbei wird die Verwendung eines virtuellen TLB beschrieben.
  • Die US 2004/0054518 A1 ist auf ein Verfahren und ein System zur effizienten Emulation einer Multiprozessor-Adressübersetzung auf einem Multiprozessor-Host gerichtet. Es wird kein Hinweis dahingehend gegeben, einen TLB in einer virtualisierten Umgebung entsprechend einem EPT-Kontext zu invalidieren.
  • Die US 2006/0026383 A1 ist auf ein Verfahren zur effizienten Virtualisierung eines physikalischen Speichers in einem virtuellen Maschinenmonitor gerichtet. Obwohl die Verwendung eines Translation-Lookaside-Puffers in einem virtualisierten System erwähnt wird, gibt es keinen Hinweis in die Richtung einer Invalidierung oder Aktualisierung eines TLB basierend auf einem in einer EPT gespeicherten Mapping mittels eines Befehls, dessen Operand eine Kontextbezeichnung und/oder einen EPT-Zeiger umfasst.
  • Die WO 2006/081582 A2 ist eine Anmeldung der Intel Corporation, welche auf ein Verfahren und eine Vorrichtung gerichtet ist, welche eine Adressübersetzung in einer virtualisierten Umgebung unterstützt. Die Verwendung eines Translation-Lookaside-Puffers bei der Verwendung einer erweiterten Paging-Table-(EPT)-Adressumsetzung wird nicht beschrieben.
  • Die US 2004/0117593 A1 ist auf das Betreiben eines TLB in einer virtualisierten Umgebung gerichtet. Diese Schrift ist jedoch nicht auf das Konzept von erweiterten Seiten-Tabellen gerichtet.
  • Die Erfindung ist im Hauptanspruch und in den nebengeordneten Ansprüchen definiert. Ausführungsformen der Erfindung sind in den Unteransprüchen definiert.
  • Figurenliste
    • 1 zeigt die Beziehung zwischen einem Prozeß und einem physikalischen Speicher.
    • 2 zeigt abstrakt die Beziehung zwischen virtuellen Maschinen und einer Host-Maschine in einer Ausführungsform.
    • 3 zeigt eine höhere Struktur einer virtuellen Maschinenumgebung in einer Ausführungsform.
    • 4 zeigt einen Prozessor in einer Ausführungsform auf Funktionsebene.
    • 5 zeigt die Adressenberechnung unter Verwendung von erweiterten Seitenwechseltabellen in einer Ausführungsform.
    • 6 zeigt den Befehlsausführungsablauf in einer Ausführungsform.
  • Detaillierte Beschreibung
  • 1 zeigt einen Prozeß, welcher in einem prozessorbasierten System ausgeführt wird, welches einen Prozessor und einen Speicher beinhaltet, der über einen Bus zum Datenaustausch mit dem Prozessor verbunden ist. Wenn, Bezug nehmend auf 1, ein Prozeß 105 auf eine Speicherstelle 110 in seinem linearen Adreßraum 115 (linearen Speicherraum) verweist, wird durch die Speicherverwaltung 130, welche in Hardware (manchmal in den Prozessor 120 integriert) und Software (im Allgemeinen im Betriebssystem der Maschine) implementiert sein kann, ein Verweis auf eine aktuelle Adresse 140 in dem physikalischen bzw. dem realen Speicher 145 der Maschine 125 (realer Maschinenspeicher) erzeugt. Die Speicherverwaltung 130 setzt neben anderen Funktionen eine Stelle im linearen Adreßraum in eine Stelle im realen Speicher der Maschine um. Wie in 1 dargestellt, kann für einen Prozeß ein anderer Speicher ersichtlich sein als der tatsächliche in der realen Maschine verfügbare Speicher. In dem in 1 abgebildeten Beispiel arbeitet der Prozeß in einem linearen Adreßraum von 0 bis 1 MB, welcher von der Speicherverwaltungs-Hardware und -Software aktuell in einen Teil des realen Speichers umgesetzt wird, welcher selbst einen Adreßraum von 10 bis 11 MB aufweist; um aus einer Prozeßraumadresse eine reale Adresse zu errechnen, kann der linearen Adresse ein Zusatz 135 hinzugefügt werden. Es sind komplexere Umsetzungen vom linearen Adreßraum in einen realen Speicher möglich, es kann zum Beispiel der einem linearen Speicher entsprechende reale Speicher in Teile wie z.B. Seiten unterteilt werden und mit Seiten aus anderen Prozessen im realen Speicher verschachtelt werden.
  • Ein Speicher wird üblicherweise in Seiten unterteilt, wobei jede Seite eine bekannte Datenmenge enthält, die über die Implementationen hinweg variiert, z.B. kann eine Seite 4096 Speicher-Bytes, 1 Speicher-MB oder irgendeine andere Speichermenge enthalten, wie sie für eine bestimmte Anwendung gewünscht wird. Da durch den ausgeführten Prozeß auf Speicherstellen verwiesen wird, werden diese in Seitenverweise übersetzt. In einer typischen Maschine setzt die Speicherverwaltung einen Verweis auf eine Seite im linearen Speicher zu einer Seite im realen Maschinenspeicher um. Im allgemeinen kann die Speicherverwaltung eine Seitentabelle verwenden, um die reale Stelle der Seite entsprechend einer Stelle der Seite im Prozeßraum zu spezifizieren.
  • Ein Aspekt der Verwaltung von Gastsoftware in einer virtuellen Maschinenumgebung ist die Verwaltung des Speichers. Die Behandlung von Speicherverwaltungsaktionen, die von der Gastsoftware vorgenommen werden, die in einer virtuellen Maschine ausgeführt wird, erzeugt eine Komplexität für ein Steuersystem wie einen Monitor der virtuellen Maschine. Man betrachte zum Beispiel ein System, in welchem zwei virtuelle Maschinen über Virtualisierung auf einer Host-Maschine ausgeführt werden, die auf einer x86er-Plattform implementiert ist, welche Seitentabellen umfassen kann, die als Teil des x86er-Prozessors implementiert sind. Ferner nehme man an, daß jede virtuelle Maschine selbst eine Abstraktion einer x86er-Maschine für die Gastsoftware darstellt, die darauf ausgeführt wird. Gastsoftware, die auf irgendeiner virtuellen Maschine ausgeführt wird, kann Verweise auf eine Gast-Linearspeicheradresse vornehmen, welche im Gegenzug durch das Speicherverwaltungssystem der Gastmaschine in eine reale Gast-Speicheradresse übersetzt wird. Der reale Gastspeicher selbst kann jedoch durch eine weitere Umsetzung in einen realen Host-Speicher über einen VMM und das Virtualisierungs-Untersystem in Hardware auf dem Host-Prozessor implementiert sein. Daher müssen Verweise auf einen Gastspeicher durch Gastprozesse oder das Gastbetriebssystem, zum Beispiel Verweise auf Gast-x86er-Seitentabellen-Steuerregister, dann vom VMM abgefangen werden, weil sie nicht direkt ohne weitere Aufbereitung zur Seitentabelle der Host-Maschine weitergeleitet werden können, weil der reale Gastspeicher in Wirklichkeit nicht direkt dem realen Host-Speicher entspricht, sondern über das Virtualisierungssystem der Host-Maschine weiter umgesetzt ist.
  • 2: In 2 ist die Beziehung zwischen einer oder mehreren virtuellen Maschinen abgebildet, die auf einer Host-Maschine ausgeführt werden, mit speziellem Augenmerk auf die Umsetzung des Gastspeichers in einer Ausführungsform. 2 veranschaulicht, wie ein realer Gastspeicher über das Virtualisierungssystem der Host-Maschine neu umgesetzt wird. Jede virtuelle Maschine, z.B. eine virtuelle Maschine A, 242, und eine virtuelle Maschine B, 257, stellt für die Gastsoftware, die auf den virtuellen Maschinen ausgeführt wird, einen virtuellen Prozessor 245 bzw. 255 dar. Jede Maschine stellt dem Gastbetriebssystem oder anderer Gastsoftware eine Abstraktion des realen Speichers bereit, die realen Gastspeicher 240 bzw. 250. Wenn Gastsoftware auf den virtuellen Maschinen 242 und 257 ausgeführt wird, wird sie tatsächlich unter Verwendung des realen Host-Speichers 260 von der Host-Maschine 267 auf dem Host-Prozessor 265 ausgeführt.
  • Wie in 2 dargestellt, wird in dieser Ausführungsform der reale Gastspeicher 240, welcher als ein realer Speicherraum dargestellt wird, der bei Adresse 0 in der virtuellen Maschine A, 242, beginnt, in einen zusammenhängenden Bereich 270 im realen Host-Speicher 260 umgesetzt. In ähnlicher Weise wird der reale Gastspeicher 250 in der virtuellen Maschine B, 257, in einen anderen Abschnitt 275 des realen Host-Speichers 260 umgesetzt. Wie in 2 dargestellt, könnte die Host-Maschine einen realen Host-Speicher von 1024 MB aufweisen. Wenn jeder virtuellen Maschine 242 und 257 eine Speicherkapazität von 256 MB zugeordnet werden, könnte eine mögliche Umsetzung so ausgestaltet sein, daß der virtuellen Maschine A, 242, der Bereich von 128 bis 384 MB zugeordnet wird und der virtuellen Maschine B, 257, der Bereich von 512 bis 768 MB zugeordnet wird. Beide virtuellen Maschinen 242 und 257 verweisen auf einen realen Gastadreßraum von 0 bis 256 MB. Nur dem VMM ist bekannt, daß der Adreßraum jeder virtuellen Maschine in verschiedene Abschnitte des realen Host-Adreßraums umgesetzt wird.
  • Die virtuellen Maschinen und die Speicherumsetzung, die in 2 dargestellt ist, sind nur eine Darstellung einer Ausführungsform, in anderen Ausführungsformen kann die tatsächliche Anzahl virtueller Maschinen, die auf einer Host-Maschine ausgeführt werden, von einer bis vielen variieren; die tatsächlichen Speichergrößen der Host-Maschine und der virtuellen Maschinen können variieren und können von virtueller Maschine zu virtueller Maschine verschieden sein. In dem Beispiel ist eine einfache zusammenhängende Speicherzuordnung zu den virtuellen Maschinen dargestellt. In einem allgemeineren Fall kann es sein, daß die Realspeicherseiten, die einer virtuellen Maschine zugeordnet werden, nicht zusammenhängen und in dem realen Host-Speicher untereinander und mit Seiten, die zum VMM und zu anderen Host-Prozessen gehören, verschachtelt verteilt sein könnten.
  • Ein prozessorbasiertes System, welches sich als eine virtuelle Maschine in einem System wie jenem in 2 abgebildeten darstellt, kann eine virtuelle Maschine in ihrer gesamten Komplexität implementieren. So kann zum Beispiel eine virtuelle Maschine für das Gastbetriebssystem (Gast-BS) eine vollständige Ansicht eines realen Gastspeichers darstellen und die Speicherverwaltung für die Gastsoftware durchführen, die auf der virtuellen Maschine ausgeführt wird, wobei sie eine Speicherverwaltung anwendet, die von dem Gast-BS und dem virtuellen Prozessor oder einer anderen virtuellen Hardware der virtuellen Maschine bereitgestellt wird. In einem Ausführungsbeispiel kann die virtuelle Maschine für das Gast-BS eine x86er-Plattform einschließlich x86er-Hardwareunterstützung, z.B. Seitentabellen für die Speicherverwaltung, darstellen, und im Gegenzug tatsächlich auf einer Host-Plattform ausgeführt werden, welche ebenfalls eine x86er-Plattform ist, die eine x86er-Hardware für Speicherverwaltung aufweist. Ohne zusätzliche Mechanismen muß ein Virtualisierungssystem in dieser Ausführungsform einen Realspeicher-Virtualisierungsalgorithmus im VMM implementieren, wobei als eine mögliche Lösung ein x86er-Seitentabellen-Shadowing angewendet wird, um den realen Speicher neu umzusetzen, aufzuteilen und zu schützen. Somit muß zum Beispiel, wenn eine Gastsoftware versucht, auf die x86er-Seitentabellen der virtuellen Maschine zuzugreifen, der VMM der Funktionalität, die von dem Gast-BS benötigt wird, eine Funktionalität überlagern, die für die Virtualisierung benötigt wird (z.B. Neuumsetzung von realen Adressen).
  • Zu diesem Zweck muß der VMM eine Vielfalt von Ereignissen einfangen, welche die Verwendung des Seitenwechselmechanismus durch die Gastsoftware umgeben. Dies umfaßt Schreibvorgänge an Steuerregister, z.B. Steuerregister des x86er-Speicherverwaltungssystems (z.B. CR0, CR3 und C4), Zugriffe auf modellspezifische Register (MSR), welche mit dem Seitenwechsel in Verbindung stehen, und den Speicherzugriff (z.B. auf speicherartige Bereichsregister (Memory-Type Range Registers, MTRR)), die Handhabung bestimmter Ablaufunterbechungen (z.B. Seitenfehler), wie in der x86er-Dokumentation beschrieben. Diese Verwendung der x86er-Seitentabellen, um den realen Speicher zu virtualisieren, ist komplex und verlangt eine merkliche zusätzliche Leistung.
  • 3: 3 veranschaulicht eine Ausführungsform einer virtuellen Maschinenumgebung 300. in dieser Ausführungsform kann eine prozessorbasierte Plattform 316 einen VMM 312 ausführen. Der VMM, obwohl typischerweise in Software implementiert, kann eine Schnittstelle einer unbestückten virtuellen Maschine emulieren und an eine höhere Software exportieren. Eine solche höhere Software kann ein Standard-BS, ein Echtzeit-BS umfassen, oder es kann sich um eine abgerüstete Umgebung mit begrenzter Betriebssystemfunktionalität handeln, oder sie kann in einigen Ausführungsformen keine BS-Merkmale aufweisen, die in einem Standard-BS typischerweise verfügbar sind. Alternativ kann der VMM 312 zum Beispiel innerhalb eines anderen VMM ausgeführt werden oder dessen Dienste verwenden. VMM können zum Beispiel in Hardware, Software, Firmware oder in einigen Ausführungsformen durch eine Kombination verschiedener Techniken implementiert sein. In mindestens einer Ausführungsform können eine oder mehrere Komponenten des VMM in einer oder mehreren virtuellen Maschinen ausgeführt werden, und eine oder mehrere Komponenten des VMM können auf der unbestückten Plattform-Hardware ausgeführt werden, wie in 3 dargestellt. Die Komponenten des VMM, welche direkt auf der unbestückten Plattform-Hardware ausgeführt werden, werden hierin als Host-Komponenten des VMM bezeichnet.
  • Bei der Plattform-Hardware 316 kann es sich um einen Personalcomputer (PC), einen Server, einen Großrechner, ein Handgerät wie z.B. einen persönlichen digitalen Assistenten (PDA) oder ein intelligentes Mobiltelefon, einen tragbaren Computer, eine Set-top-Box oder ein anderes prozessorbasiertes System handeln. Die Plattform-Hardware 316 umfaßt mindestens einen Prozessor 318 und einen Speicher 320. Bei dem Prozessor 318 kann es sich um irgendeine Art von Prozessor handeln, der Programme ausführen kann, z.B. einen Mikroprozessor, einen digitalen Signalprozessor, einen Mikrocontroller oder ähnliches. Der Prozessor kann in einigen Ausführungsformen Mikrocode, eine programmierbare Logik oder eine festcodierte Logik zur Ausführung umfassen. Obwohl 3 nur einen solchen Prozessor 318 zeigt, kann es in einer Ausführungsform einen oder mehrere Prozessoren in dem System geben. Außerdem kann der Prozessor 318 mehrere Hauptspeicher, Unterstützung für mehrere Threads oder ähnliches umfassen. Der Speicher 320 kann eine Hartplatte, eine Diskette, einen Direktzugriffsspeicher (RAM), einen Festspeicher (ROM), einen Flashspeicher, irgendeine Kombination der obigen Einheiten oder in verschiedenen Ausführungsformen irgendeine andere Art des Maschinenmediums, das vom Prozessor 318 lesbar ist, umfassen. Der Speicher 320 kann Befehle und/oder Daten speichern, um Programme und andere Prozeßausführungsformen auszuführen. In einigen Ausführungsformen können einige Elemente der Erfindung in anderen Systemkomponenten verwirklicht werden, z.B. im Plattform-Chipsatz oder in einer oder mehreren Speicher-Steuervorrichtungen des Systems.
  • Der VMM 312 stellt für die Gastsoftware eine Abstraktion einer oder mehrerer virtueller Maschinen dar, welche den verschiedenen Gästen dieselben oder andere Abstraktionen bereitstellen können. 3 zeigt zwei virtuelle Maschinen, 302 und 314. Die Gastsoftware, z.B. die Gastsoftware 303 und 313, welche auf jeder virtuellen Maschine abläuft, kann ein Gast-BS, z.B. ein Gast-BS 304 oder 306, und verschiedene Gastsoftwareanwendungen 308 und 310 umfassen. Die Gastsoftware 303 und 313 kann auf reale Ressourcen (z.B. Prozessorregister, Speicher und E/A-Einheiten) innerhalb der virtuellen Maschinen zugreifen, auf welchen die Gastsoftware 303 und 313 abläuft, und um andere Funktionen auszuüben. Die Gastsoftware 303 und 313 erwartet zum Beispiel, Zugriff auf alle Register, Cache-Speicher, Strukturen, E/A-Einheiten, Speicher und ähnliches gemäß der Architektur des Prozessors und der Plattform zu haben, die in der virtuellen Maschine 302 und 314 dargestellt werden.
  • In einer Ausführungsform steuert der Prozessor 318 die Operation der virtuellen Maschinen 302 und 314 gemäß Daten, die in einer Steuerstruktur der virtuellen Maschine (Virtual Machine Control Structure, VMCS) 324 gespeichert sind. Die VMCS 324 ist eine Struktur, welche einen Zustand der Gastsoftware 303 und 313, einen Zustand des VMM 312, Ausführungssteuerungsinformationen, die anzeigen, wie der VMM 312 die Operation der Gastsoftware 303 und 313 zu steuern wünscht, Informationen, welche Übertragungen zwischen dem VMM 312 und einer virtuellen Maschine steuern, usw. enthalten kann. Der Prozessor 318 liest Informationen aus der VMCS 324 aus, um die Ausführungsumgebung der virtuellen Maschine zu ermitteln und deren Verhalten einzugrenzen. In einer Ausführungsform ist die VMCS 324 im Speicher 320 gespeichert. In einigen Ausführungsformen werden mehrere VMCS-Strukturen verwendet, um CPUs innerhalb einer oder mehreren virtuellen Maschinen zu unterstützen.
  • Es kann sein, daß der VMM 312 den realen Speicher verwalten muß, auf den die Gastsoftware zugreifen kann, die in den virtuellen Maschinen 302 und 314 abläuft. Um die Realspeicherverwaltung zu unterstützen, stellt der Prozessor 318 in einer Ausführungsform einen erweiterten Seitentabellenmechanismus (Extended Page Table, EPT-Mechanismus) bereit. In dieser Ausführungsform kann der VMM ein Realspeicher-Verwaltungsmodul 326 umfassen, welches Werte für Felder bereitstellt, die mit der Realspeicher-Virtualisierung in Verbindung stehen und möglicherweise vor der Übertragung der Steuerung auf die virtuelle Maschine 302 oder 314 bereitgestellt werden müssen. Diese Felder werden zusammenfassend als EPT-Steuerungen bezeichnet. EPT-Steuerungen können zum Beispiel einen EPT-Freigabeindikator, welcher spezifiziert, ob der EPT-Mechanismus freigegeben werden sollte, und eine oder mehrere EPT-Tabellenkonfigurationssteuerungen aufweisen, welche die Form und Semantik des Realspeicher-Virtualisierungsmechanismus anzeigen. Diese werden unten noch detaillierter beschrieben. Außerdem zeigen in einer Ausführungsform die EPT-Tabellen 328 die Realadressenübersetzung und die Schutzsemantik an, welche der VMM 312 auf die Gastsoftware 303 und 313 anwendet.
  • In einer Ausführungsform sind die EPT-Steuerungen in der VMCS 324 gespeichert. Alternativ können sich die EPT-Steuerungen in einem Prozessor 318, einer Kombination des Speichers 320 und des Prozessors 318 oder an irgendeinem anderen Speicherort (irgendwelchen anderen Speicherorten) befinden. In einer Ausführungsform werden für jede der virtuellen Maschinen 302 und 314 separate EPT-Steuerungen unterhalten. Alternativ werden für beide virtuellen Maschinen dieselben EPT-Steuerungen unterhalten und werden durch den VMM 312 vor jedem Einstieg einer virtuellen Maschine aktualisiert.
  • In einer Ausführungsform sind die EPT-Tabellen 328 im Speicher 320 gespeichert. Alternativ können sich die EPT-Tabellen in dem Prozessor 318, einer Kombination des Speichers 320 und des Prozessors 318 oder an irgendeinem anderen Speicherort (irgendwelchen anderen Speicherorten) befinden. In einer Ausführungsform werden für jede der virtuellen Maschinen 302 und 314 separate EPT-Tabellen 328 unterhalten. Alternativ werden für beide virtuellen Maschinen dieselben EPT-Tabellen 328 unterhalten und werden durch den VMM 312 vor jedem Einstieg einer virtuellen Maschine aktualisiert.
  • In einer Ausführungsform weist der Prozessor 318 eine EPT-Zugriffslogik 322 auf, welche dafür verantwortlich ist, zu ermitteln, ob der EPT-Mechanismus freigegeben ist, basierend auf dem EPT-Freigabeindikator. Wenn der EPT-Mechanismus freigegeben ist, übersetzt der Prozessor reale Gastadressen in reale Host-Adressen, basierend auf den EPT-Steuerungen und EPT-Tabellen 328.
  • In der dargestellten Ausführungsform kann der Prozessor ferner einen Adressenübersetzungs-Pufferspeicher (TLB) 323 aufweisen, um Übersetzungen von linearer in reale Gastadresse, von realer Gastadresse zu realer Host-Adresse und von realer Host-Adresse zu linearer Adresse zwischenzuspeichern. Übersetzungen von linearer zu realer Gastadresse und linearer zu realer Host-Adresse werden hierin als „lineare Übersetzungen“ bezeichnet. Übersetzungen von realer Gastadresse zu realer Host-Adresse und von linearer zu realer Host-Adresse werden hierin als „reale Übersetzungen“ bezeichnet.
  • In einer Ausführungsform, in welcher das System 300 mehrere Prozessoren oder Multithread-Prozessoren aufweist, ist jeder der logischen Prozessoren mit einer eigenen EPT-Zugriffslogik 322 verbunden, und der VMM 312 konfiguriert die EPT-Tabellen 328 und EPT-Steuerungen für jeden der logischen Prozessoren.
  • Ressourcen, auf welche die Gastsoftware (z.B. 303, einschließlich des Gast-BS 304 und der Anwendung 308) Zugriff nehmen kann, können entweder als „privilegiert“ oder „nicht privilegiert“ klassifiziert werden. Für privilegierte Ressourcen erleichtert der VMM 312 die von der Gastsoftware gewünschte Funktionalität, wobei er die letzte Kontrolle über diese privilegierten Ressourcen behält. Ferner erwartet jede Gastsoftware 303 und 313, verschiedene Plattformereignisse, wie z.B. Ablaufunterbrechungen (z.B. Seitenfehler, allgemeine Schutzfehler usw.), Unterbrechungen (z.B. Hardware-Unterbrechungen, Software-Unterbrechungen) und Plattformereignisse (z.B. Initialisierung (INIT) und Systemverwaltungsunterbrechungen (System Management Interrupts, SMIs)) abzuwickeln. Einige dieser Plattformereignisse sind „privilegiert“, weil sie vom VMM 312 abgewickelt werden müssen, um die richtige Operation der virtuellen Maschinen 302 und 314 sicherzustellen, und um Schutz vor und zwischen Gastsoftware zu gewährleisten. Sowohl Gastbetriebssystem als auch Gastanwendungen können versuchen, auf privilegierte Ressourcen zuzugreifen, und beide können privilegierte Ereignisse verursachen oder erfahren. Privilegierte Plattformereignisse und Zugriffsversuche auf privilegierte Ressourcen werden hierin zusammenfassend als „privilegierte Ereignisse“ oder „Virtualisierungsereignisse“ bezeichnet.
  • 3a: In 3a sind in Blockform auf höherer Ebene einige Merkmale des Prozessors 318 in der Ausführungsform der 3 abgebildet. Im allgemeinen kann ein Prozessor wie der in 3 bei 318 abgebildete einen Prozessorbus oder Busse aufweisen, wie z.B. den in 3a bei 337 gezeigten. Ferner kann ein Prozessor, wie in 3a dargestellt, Register 350 in einer oder mehreren Bänken aufweisen, und jedes Register kann die Kapazität aufweisen, 32, 64, 128 oder eine Anzahl von Daten-Bits zu speichern, wie bekannt ist. Jede Registerbank kann ferner mehrere Register aufweisen, z.B. 8, 32, 64 Register. Einige Register können für eine Steuer- und Statusverwendung vorgesehen sein, um zum Beispiel wie in einer x86er-Umgebung die CR-Bits zu speichern. In anderen Ausführungsformen können in dem Prozessor andere Steuerregister und Merker gespeichert sein, um verschiedene Operationsmodi und eine Statusüberprüfung zu ermöglichen, wie es auf dem Fachgebiet bekannt ist. Im allgemeinen weist ein Prozessor wie der in der Ausführungsform der 3 abgebildete eine Logik oder Logikschaltung 330 auf, um Befehle und Daten aus dem Speicher, dem Cache-Speicher oder einer anderer Speicherung abzurufen; und eine Logik oder Logikschaltung 330, um Befehle und Ausfuhrungseinheiten wie 334, um die Befehle auszuführen, zu decodieren. Es sind viele Variationen an diesen funktionellen Einheiten möglich, z.B. kann die Ausführung in der Ausführungseinheit als Fließbandverarbeitung ausgestaltet sein; oder eine Spekulation und Verzweigungsannahme umfassen; oder in Beziehung zu einem bestimmten Prozessor oder einer bestimmten Anwendung andere Merkmale aufweisen. Es kann eine andere funktionelle Logik 365 in dem Prozessor vorliegen, z.B. eine Logik für Arithmetik, Grafikverarbeitung und viele andere spezielle Funktionen des Prozessors, wie bekannt ist. In einigen Ausführungsformen kann ein integrierter Cache-Speicher 360 vorliegen. Dieser Cache-Speicher kann verschiedene Größen haben, z.B. 128 MB, 1 GB usw., wie bekannt ist. Wie bereits in Bezug auf 3 gezeigt, weist der Prozessor 318 eine EPT-Zugriffslogik 322 und einen TLB 323 auf. Die EPT-Zugriffslogik kann in einer Ausführungsform eine Logik aufweisen, um die EPT zu bestücken, zu steuern und zu verwalten; und der TLB ist im allgemeinen ein Puffer, welcher Umsetzungen von Seitentabellen aufweist, die aus Gründen der Effizienz und zu anderen Zwecken innerhalb des Prozessors zwischengespeichert werden.
  • 4: 4 zeigt ein Beispiel der Verarbeitung unter Verwendung der oben eingeführten erweiterten Seitentabellen, um eine reale Host-Adresse abschließend zu errechnen, wenn die Gastsoftware in einer virtuellen Maschine auf eine virtuelle Gastadresse verweist. Das dargestellte Beispiel zeigt eine Gastsoftware, die in einer x86er-Plattform abläuft, wobei sie eine einfache virtuelle 32-Bit-Adressierung und einfache Seitentabellenformate anwendet. Der Fachmann wird dieses Beispiel leicht erweitern können, um zum Beispiel andere Seitenwechsel-Modi (z.B. eine 64-Bit-Adressierung in der Gastsoftware), andere Befehlssatz-Architekturen (z.B. unter vielen anderen die Intel-Itanium®-Architektur, 64-Bit- und andere Variationen der x86er-Architektur, die PowerPC®-Architektur) zu verstehen, und er wird es auf andere Konfigurationen erweitern können.
  • In 4 wird von einer Gastsoftware, die in einer virtuellen Maschine ausgeführt wird, ein Verweis auf eine virtuelle Gastadresse 410 durchgeführt. Der in dem Gast (konfiguriert z.B. durch das Gastbetriebssystem) aktive Speicherverwaltungsmechanismus wird benutzt, um die virtuelle Adresse in eine reale Gastadresse zu übersetzen. Jede bei der Übersetzung verwendete reale Gastadresse und die resultierende reale Gastadresse werden über die EPT in eine reale Host-Adresse übersetzt, bevor auf den realen Host-Speicher Zugriff genommen wird. Dieser Prozeß wird in der folgenden Erörterung detailliert beschrieben.
  • In diesem Beispiel zeigen die entsprechenden Bits 403 im CR3-Register 420 auf die Basis der Gast-Seitenverzeichnistabelle 460 im realen Gastspeicher. Dieser Wert 402 wird mit den oberen Bits aus der virtuellen Gastadresse 410 (gemäß der x86er-Semantik durch Multiplizieren mit 4 entsprechend angepaßt, weil in diesem Beispiel die Einträge in die Tabellen jeweils 4 Bytes aufweisen) kombiniert, um die reale Gastadresse 412 des Seitenverzeichniseintrags (Page Directory Entry, PDE) in die Gast-Seitenverzeichnistabelle 460 zu bilden. Dieser Wert 412 wird über die EPT-Tabellen 455 übersetzt, um die reale Host-Adresse 404 des Seitenverzeichniseintrags zu bilden. Der Prozessor greift auf den Seitenverzeichniseintrag unter Verwendung dieser realen Host-Adresse 404 zu.
  • Die Informationen aus dem PDE umfassen die Basisadresse 422 der Gast-Seitentabelle 470. Diese reale Gastadresse 422 wird mit den Bits 21:12 der entsprechend angepassten virtuellen Gastadresse 410 kombiniert, um die reale Gastadresse 432 des Seitentabelleneintrags in die Gast-Seitentabelle 470 zu bilden. Diese reale Gastadresse 432 wird über die EPT-Tabellen 465 übersetzt, um die reale Host-Adresse 414 des Gast-Seitentabelleneintrags (Page Table Entry, PTE) zu bilden. Der Prozessor greift auf den PTE unter Verwendung dieser realen Host-Adresse 414 zu.
  • Die Informationen aus dem PTE umfassen die Basisadresse 442 der Seite im realen Gastspeicher, auf den Zugriff genommen wird. Dieser Wert wird mit den niederwertigen Bits (11:0) der virtuellen Gastadresse 410 kombiniert, um die reale Gastadresse 452 des Speichers, auf den Zugriff genommen wird, zu bilden. Dieser Wert 452 wird über die EPT-Tabellen 475 übersetzt, um die reale Host-Adresse 424 des Speichers, auf den zugegriffen wird, zu bilden.
  • Jedes Mal, wenn die EPT-Tabellen benutzt werden, um eine reale Gastadresse in eine reale Host-Adresse zu übersetzen, überprüft der Prozessor auch, ob der Zugriff gemäß den Steuerungen in den EPT-Tabellen zugelassen wird, wie es unten noch beschrieben wird. Außerdem versteht es sich, daß es sich bei den EPT-Tabellen 455, 465 und 475 in einer Ausführungsform um denselben Satz von EPT-Tabellen handeln kann, obwohl sie in 4 als verschieden dargestellt sind (z.B. wird für alle Adressenübersetzungen von realer Gastadresse in reale Host-Adresse ein einziger Satz von EPT-Tabellen benutzt).
  • In einer typischen Verwirklichung einer Unterstützung eines linearen Speichers in einem prozessorbasierten System können Umsetzungen von linearen Adressen zu realen Adressen, die in einer Seitentabellenstruktur gespeichert sind, aus Effizienzgründen in einem Adressenübersetzungs-Pufferspeicher (TLB) zwischengespeichert werden. In einem Prozessorbefehlssatz können Befehle enthalten sein, um den TLB zu verwalten und zu ermöglichen, daß ein Programm, das in dem prozessorbasierten System ausgeführt wird, sicherstellt, daß ein bestimmter Eintrag in den TLB mit einem Seitentabelleneintrag synchronisiert ist. So kann zum Beispiel in der x86er-Architektur der Befehl MOV CR eine globale Annullierung aller TLB-Einträge und somit eine Neusynchronisierung der Einträge verursachen, wenn auf Adressen Zugriff genommen wird. Alternativ kann in dem x86er-Beispiel ein INVLPG-Befehl benutzt werden, um für eine spezielle lineare Adresse eine im TLB gespeicherte Umsetzung zu annullieren, was bewirkt, daß der Eintrag im TLB aktualisiert und mit der Umsetzung in der Seitentabelle synchronisiert wird.
  • In einer Ausführungsform, die ein virtualisiertes System umfaßt, das eine erweiterte Seitenwechseltabelle (EPT) wie oben beschrieben beinhaltet, kann ein TLB Umsetzungen von linearer Gastadresse zu realer Host-Adresse für Prozesse, die in einem Gastmaschinenspeicher ausgeführt werden, und Umsetzungen von linearer Host-Adresse zu realer Host-Adresse für Prozesse wie den VMM, die direkt auf der Host-Maschine ausgeführt werden, wie zuvor in Bezug auf 3 bei 323 beschrieben, zwischenspeichern. Im ersteren Fall können die Umsetzungen von linearer Gastadresse zu realer Host-Adresse sowohl aus Seitentabellen im Gast als auch aus der EPT erhalten werden; im letzteren Fall können die Umsetzungen aus den Host-Seitentabellen erhalten werden. Eine weitere Art der Umsetzung kann ebenfalls in dem TLB gespeichert werden: eine direkt erhaltene Umsetzung von realem Gastspeicher zu realem Host-Speicher, basierend auf den in der EPT gespeicherten Umsetzungen.
  • In einer Ausführungsform wird dem Prozessorbefehlssatz ein neuer Befehl hinzugefügt. In dieser Ausführungsform stellt der neue Befehl INVL_EPT Programmen, die, wie der VMM, direkt auf der Host-Maschine eines virtualisierten Systems ausgeführt werden, einen Weg bereit, die TLB-Einträge zu verwalten, die aus Umsetzungen von realer Gastadresse zu realer Host-Adresse erhalten werden. Insbesondere stellt in dieser Ausführungsform der INVL_EPT-Befehl sicher, daß Umsetzungen von realer Gastadresse zu realer Host-Adresse und von linearer Adresse zu realer Host-Adresse im TLB mit den EPT-Tabellen synchronisiert sind, die auf dem Host-Speicher residieren, und daß das Ausmaß der Synchronisierung, der EPT-Kontext und, wo es relevant ist, die reale Gastspeicheradresse, für welche die Umsetzungen zu synchronisieren sind, spezifiziert wird. Ein Kontext definiert im allgemeinen einen Abschnitt des Adreßraums eines Systems. Für Umsetzungen von realen Gastadressen zu realen Host-Adressen ist der EPT-Kontext durch die aktuell aktive EPT-Tabelle definiert, auf welche in dieser Ausführungsform wiederum von einem Register verwiesen wird, das als EPT-Zeiger oder EPTP (EPT Pointer) bezeichnet wird.
  • In dieser Ausführungsform weist der INVL_EPT-Befehl drei Operanden auf, als erstes einen Wert für einen Befehlsmodus oder eine abweichende Spezifizierung; als zweiten Operanden einen Wert, der den EPT-Zeiger spezifiziert, welcher dem EPT-Kontext entspricht, in welchem der INVL_EPT-Befehl auszuführen ist; und als dritten Operanden einen Wert, der die reale Gastadresse spezifiziert, die zu den zu annullierenden TLB-Einträgen gehört. In dieser Ausführungsform wird der erste Operand als 8-Bit-Direktwert bereitgestellt, und der zweite und dritte Operand werden als ein Block im Speicher bereitgestellt, wobei jeder 64 Bit besetzt. Es sind auch andere Ausführungsformen möglich. Die Operanden können zum Beispiel in Registern oder anderen Speicherstellen entweder direkt oder indirekt bereitgestellt werden.
  • Der erste Operand in dieser Ausführungsform ist ein Schalter oder ein Merker mit mindestens drei definierten Werten und spezifiziert so, daß der INVL_EPT-Befehl in einem von drei möglichen Modi auszuführen ist:
    1. 1. Individualadressenmodus: in diesem Modus werden reale Übersetzungen im TLB, die zu einer einzigen realen Gastadresse gehören, mit der EPT synchronisiert, basierend auf den Umsetzungen für diese Adresse in der EPT, auf die der Kontext verweist, der in dem zweiten Operanden bereitgestellt wird, wie oben beschrieben.
    2. 2. Kontextmodus: in diesem Modus wird der Gastadressenparameter (der dritte Operand, wie oben beschrieben) ignoriert, und jene Einträge in den TLB in dem EPT-Kontext, der in dem zweiten Operanden spezifiziert wird, wie oben beschrieben, werden mit der EPT synchronisiert.
    3. 3. Globalmodus: in diesem Modus werden sowohl der Gastadressenparameter als auch die EPT-Kontextparameter ignoriert, und TLB-Einträge, die aus irgendeinem EPT-Kontext erhalten werden, werden synchronisiert.
  • 5. Das Ablaufdiagramm der 5 stellt die Ausführung des INVL_EPT-Befehls in einer Ausführungsform dar. Die Ausführung beginnt bei 500. Zuerst kann der Prozessor bei 505 eine Anzahl von Tests durchführen, um sicherzustellen, daß die aktuelle Ausführungsumgebung für EPT-bezogene Operationen zulässig ist. Diese Tests können unter anderem einen Test umfassen, um sicherzustellen, daß sich das System in einem virtualisierten Operationsmodus befindet; daß der Seitenwechsel freigegeben ist und daß aktuell keine Fehlerzustände vorliegen. Wenn die Ausführungsumgebung nicht zulässig ist, kann der Befehl über 555 und 560 entweder in einen undefinierten Zustand aussteigen, einen allgemeinen Schutzfehler erzeugen oder einen Fehler eines undefinierten Operationscodes erzeugen oder ähnliches. Wenn die Ausführungsumgebung zulässig ist, dann liest die Befehlsausführung in dieser Ausführungsform bei 510 einen 8-Bit-Direktoperanden aus. Von diesem Operanden, bezeichnet als SYNC_CMD, wird angenommen, daß er für einen zulässigen Modus für den INVL_EPT-Befehl steht, wie oben detailliert beschrieben. Wenn der Operand nicht zulässig ist, steigt der Befehl bei 515 wie zuvor zu 555 und 560 aus. Wenn der Operand zulässig ist, wird die Ausführung dann damit fortgesetzt, den zweiten und dritten Operanden aus dem Speicher auszulesen, 520, und wie zuvor beschrieben, wird erwartet, daß sich die Operanden in einem 128-Bit-Block im Speicher an einem Verweis befinden, der in der Figur mit INVLEPT_DESC gekennzeichnet ist. Bei den ersten 64 Bits handelt es sich in dieser Ausführungsform um den EPT-Kontext oder den EPT-Tabellenzeiger, sie werden bei 525 als EPTP_CTX extrahiert; bei den nächsten 64 Bits handelt es sich um den Realgastadressenparameter für den Befehl, bei 530 als GP_ADDR extrahiert.
  • Die Ausführung des Befehls wird dann damit fortgesetzt, daß die aktuelle Synchronisierung ausgeführt wird, abhängig von dem Wert des SYNC_CMD-Operanden in dem Ausführungsablauf, der von 535 bis 580 abgebildet ist. Wie zuvor bereits beschrieben, kann es sich bei SYNC_CMD entweder um ein Zeichen dafür handeln, eine globale Synchronisierung des TLB basierend auf allen EPT-Kontexten durchzuführen; oder ein Zeichen dafür, eine Synchronisierung nur des EPT-Kontexts durchzuführen, der durch einen Operanden des Befehls spezifiziert wird; oder schließlich dafür, eine Synchronisierung nur der realen Gastadresse durchzuführen, die als ein Parameter in dem EPT-Kontext weitergeleitet wird, der als Parameter bereitgestellt wird. In dieser Ausführungsform findet bei 535, dargestellt im Ablaufdiagramm der 5, eine Überprüfung des SYNC_CMD-Wertes statt; die zweite bei 540 und die dritte bei 545. Bei 535 werden durch den Befehl, wenn der SYNC_CMD-Wert eine globale Synchronisierung anzeigt, alle realen Umsetzungen für alle EPT-Kontexte synchronisiert, und die Ausführung ist beendet, 580. Wenn anderenfalls SYNC_CMD bei 540 eine kontextspezifische Synchronisierung anzeigt, dann wird die Ausführung damit fortgesetzt zu überprüfen, ob der bereitgestellte EPTP_CTX-Wert zulässig ist. Wenn dies nicht der Fall ist, zum Beispiel weil ein reserviertes Bit in dem Wert eingestellt ist oder die Adresse in dem EPTP unzulässig ist, endet die Ausführung des Befehls mit einem allgemeinen Schutzfehler, 555 und 560. Wenn der bereitgestellte Kontext zulässig ist, wird die Ausführung fortgesetzt, wobei alle realen Umsetzungen für den EPT-Kontext, auf den EPTP_CTX verweist, bei 575 synchronisiert werden, und dann bei 580 beendet.
  • Wenn es sich bei SYNC_CMD weder um eine globale noch um eine kontextweite Synchronisierung handelt und außerdem um einen zulässigen Operationsmodus handelt, ist es für den Befehl die einzige verbleibende Möglichkeit in dieser Ausführungsform, eine spezielle reale Gastadresse zu synchronisieren. Es wird dann überprüft, ob der bei 545 bereitgestellte GP_ADDR-Parameter zulässig ist. Wenn eine unzulässige Adresse bereitgestellt wird, steigt die Ausführung bei 555 und 560 mit einem allgemeinen Schutzfehler aus. Anderenfalls werden bei 550 alle realen Umsetzungen, die zu der bereitgestellten realen Gastadresse GP_ADDR gehören, mit der EPT synchronisiert, auf welche der Kontext verweist, der in EPTP_CTX bereitgestellt wird, und die Ausführung wird beendet, 580.
  • Es ist für den Durchschnittsfachmann klar, daß die oben beschriebenen Ausführungsformen breit variiert werden können. In einigen Ausführungsformen kann ein Befehl verfügbar sein, der INVL_EPT äquivalent ist, dieser kann jedoch eine andere Syntax aufweisen, umfassend unter anderem einen Namen, die Anzahl, das Format und die Größe der Parameter. Wie es bekannt ist, gibt es verschiedene Befehlssatzarchitekturen (Instruction Set Architectures, ISA), und ein ähnlicher Befehl kann für eine andere ISA mit einem Format und anderen Eigenschaften bereitgestellt werden, die mit dieser ISA vereinbar sind. Für ein Beispiel kann ein Befehl, für einen Prozessor, der auf der Intel®-­Itanium-Architektur basiert, einen TLB zu annullieren und/oder mit einer EPT zu synchronisieren, durch einen Durchschnittsfachmann einfach visualisiert und beschrieben werden, basierend auf den Beschreibungen der obigen Ausführungsformen; ebenso gilt dies für Befehle für jede andere ISA.
  • Die Beschreibung bezüglich des EPT-Kontexts in den Ausführungsformen, auf die oben Bezug genommen wird, sollte nicht als beschränkend angesehen werden. In anderen Ausführungsformen kann es sein, daß es nur ein Beispiel einer EPT gibt, in anderen können mehrere Beispiele einsatzbereit sein, wie in dem x86er-Beispiel erörtert, mit einem Verweismechanismus wie z.B. einem Verweisregister oder einem Zeiger, der dem oben erörterten EPTP entspricht.
  • In anderen Ausführungsformen können die Anzahl und das Format der Parameter variieren. In den oben beschriebenen Ausführungsformen weist zum Beispiel der INVL_EPT-Befehl einen Direkt- und zwei speicherbasierte Operanden auf. In anderen Ausführungsformen können mehr Direktoperanden verwendet werden; in anderen können alle Operanden speicherbasiert sein; in wiederum anderen Ausführungsformen können die Operanden aus Registern oder anderen Speichern innerhalb des Prozessors ausgelesen werden, neben vielen anderen bekannten Variationen.
  • Die oben beschriebenen Ausführungsformen sind mit Bezug auf drei Operationsmodi für den INVL_EPT-Befehl beschrieben. In anderen Ausführungsformen können einige oder alle dieser Modi fehlen; in anderen können mehr Modi verfügbar sein. Es kann zum Beispiel sein, daß es in einigen Ausführungsformen keinen Modus für eine individuelle Adressannullierung gibt, und in einem solchen Modus würden alle TLB-Einträge synchronisiert. Es kann sein, daß es in einigen Ausführungsformen nur ein Beispiel einer EPT gibt, die in dem System arbeitet, und in solchen Ausführungsformen kann der Kontextmodus unnötig sein. Alternativ kann es sein, daß in einigen Ausführungsformen nur eine individuelle Adresssynchronisierung verfügbar ist; oder es kann in anderen sein, daß nur eine globale Adresssynchronisierung benutzt wird, wodurch der erste Operand, wie in Bezug auf INVL_EPT beschrieben, unnötig wird.
  • Während diese Variationen des Befehls und seiner Durchführung möglich sind, kann der Durchschnittsfachmann viele andere leicht vorhersehen, neben vielen anderen z.B. Variationen, wobei die allgemeine Wirkung des INVL_EPT-Befehls durch eine Kombination anderer Befehle erhalten wird.

Claims (8)

  1. Prozessor (318) eines auf Virtualisierung basierenden Systems (300), der umfasst: einen Translation-Lookaside-Puffer, TLB, (323) um ein Mapping von einer physikalischen Gastadresse (412, 432, 452) zu einer physikalischen Host-Adresse (404, 414, 424) zu speichern; und eine Logikschaltung (322, 332, 334), um eine Synchronisierung des Mappings von der physikalischen Gastadresse (412, 432, 452) zur physikalischen Host-Adresse (404, 414, 424), die im Translation-Lookaside-Puffer (323) gespeichert ist, mit einem entsprechenden Mapping, das in einer erweiterten Paging-Tabelle, EPT, (328; 455, 465, 475) gespeichert ist, durchzuführen, wobei das entsprechende Mapping ein in der EPT (328; 455, 465, 475) gespeichertes Mapping mit derselben physikalischen Gastadresse (412, 432, 452) wie das im TLB (323) gespeicherte Mapping aufweist, wobei die Synchronisierung auf dem Operanden eines Befehls basiert, wobei der Operand einen EPT-Zeiger umfasst, und wobei eine Abruflogik (330) ferner einen ersten Operanden des Befehls, einen zweiten Operanden des Befehls und einen dritten Operanden des Befehls empfängt; die Logikschaltung (322, 332, 334) ferner das Mapping auswählt, das zumindest teilweise in der EPT (328; 455, 465, 475) gespeichert ist, basierend auf einer Kontextbezeichnung, die aus dem ersten Operanden des Befehls erhalten wird; die Gastadresse (412, 432,452) auswählt, zumindest teilweise basierend auf dem zweiten Operanden des Befehls; und einen Ausführungsmodus des Befehls auswählt, basierend auf dem dritten Operanden des Befehls; und wobei es sich bei dem Ausführungsmodus des Befehls um einen der folgenden handelt; ein erster Modus, in welchem nur ein einziges in dem TLB (323) gespeichertes und zu der physikalischen Gastadresse (412, 432,452) gehörendes Mapping mit der entsprechenden Umsetzung in der EPT (328; 455, 465, 475) synchronisiert wird; ein zweiter Modus, in welchem alle Mappings, die in dem TLB (323) gespeichert sind und zu einem EPT-Kontext gehören, der aus der Kontextbezeichnung erhalten wird, mit den entsprechenden Mappings in der EPT (328; 455, 465, 475) synchronisiert werden, wobei die Synchronisation des Mappings ein Synchronisieren jener Einträge im TLB (323) in dem EPT-Kontext, der in dem EPT-Zeiger spezifiziert ist, mit der erweiterten Paging-Tabelle,EPT, (328; 455, 465, 475) umfasst; und ein dritter Modus, in welchem alle Mappings, die in dem TLB (323) gespeichert sind und zu irgendeinem EPT-Kontext gehören, der aus der Kontextbezeichnung erhalten wird, mit den entsprechenden Mappings in einer EPT (328; 455, 465, 475) synchronisiert werden.
  2. Prozessor (318) nach Anspruch 1, wobei die Logikschaltung (322, 332, 334) eine Logikschaltung umfasst, welche zumindest teilweise auf der Basis von Mikrocode-Befehlen arbeitet.
  3. Prozessor (318) nach Anspruch 1, wobei die EPT (328; 455, 465, 475) in einem Speicher (320) gespeichert ist, der durch einen Bus (336) mit dem Prozessor (318) verknüpft ist.
  4. Prozessor (318) nach Anspruch 1, wobei die Logikschaltung (322, 332, 334) ferner einen Ausführungsmodus des Befehls auswählt, zumindest teilweise basierend auf dem Operanden des Befehls.
  5. Verfahren, welches das folgende umfasst: in einem auf Virtualisierung basierenden System (300), welches einen Host und einen Gast umfasst, Synchronisieren eines Mappings, welches eine Übersetzung einer physikalischen Gastadresse (412, 432, 452) in eine physikalische Host-Adresse (404, 414, 424) umfasst, die in einem Translation-Lookaside-Puffer,TLB, (323) gespeichert ist, mit einem entsprechenden Mapping, das in einer erweiterten Paging-Tabelle,EPT, (328; 455, 465, 475) des auf Virtualisierung basierenden Systems (300) gespeichert ist; und Auswählen des in der EPT (328; 455, 465, 475) gespeicherten Mappings basierend auf einem Operanden eines Befehls, wobei der Operand einen EPT-Zeiger umfasst, ferner mit den Schritten: Auswählen des Mappings, das in der EPT (328; 455, 465, 475) gespeichert ist, basierend auf einer Kontextbezeichnung, die aus einem ersten Operanden des Befehls erhalten wird; Auswählen der Gastadresse (412, 432,452) basierend auf einem zweiten Operanden des Befehls; und Auswählen eines Ausführungsmodus des Befehls basierend auf einem dritten Operanden des Befehls; wobei es sich bei dem Ausführungsmodus des Befehls um einen der folgenden handelt: ein erster Modus, in welchem nur ein einziges in dem TLB (323) gespeichertes und zu der physikalischen Gastadresse (412, 432,452) gehörendes Mapping mit der entsprechenden Umsetzung in der EPT (328; 455, 465, 475) synchronisiert wird; ein zweiter Modus, in welchem alle Mappings, die in dem TLB (323) gespeichert sind und zu dem EPT-Kontext gehören, der aus der Kontextbezeichnung erhalten wird, mit den entsprechenden Mappings in der EPT (328; 455, 465, 475) synchronisiert werden, wobei das Synchronisieren des Mappings ein Synchronisieren jener Einträge im TLB (323) in dem EPT-Kontext, der in dem EPT-Zeiger spezifiziert ist, mit der erweiterten Paging-Tabelle,EPT, (328; 455, 465, 475) umfasst; und ein dritter Modus, in welchem alle Mappings, die in dem TLB (323) gespeichert sind und zu irgendeinem EPT-Kontext gehören, der aus der Kontextbezeichnung erhalten wird, mit den entsprechenden Mappings in einer EPT (328; 455, 465, 475) synchronisiert werden.
  6. Verfahren nach Anspruch 5, welches ferner das Auswählen eines Ausführungsmodus des Befehls zumindest teilweise basierend auf einem Operanden des Befehls umfasst.
  7. Auf Virtualisierung basierendes System (300), welches das folgende umfasst: einen Prozessor (318) gemäß einem der Ansprüche 1 bis 4; und einen Speicher (320), welcher über einen Bus mit dem Prozessor (318) verknüpft ist.
  8. System nach Anspruch 7, wobei der Speicher (320) ferner einen dynamischen Direktzugriffsspeicher,DRAM, umfasst.
DE102007037814.0A 2006-08-15 2007-08-10 Synchronisieren eines Translation-Lookaside-Pufferspeichers mit einer erweiterten Paging-Tabelle Active DE102007037814B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/504,964 US7555628B2 (en) 2006-08-15 2006-08-15 Synchronizing a translation lookaside buffer to an extended paging table
US11/504,964 2006-08-15

Publications (2)

Publication Number Publication Date
DE102007037814A1 DE102007037814A1 (de) 2008-03-27
DE102007037814B4 true DE102007037814B4 (de) 2021-12-02

Family

ID=38543361

Family Applications (3)

Application Number Title Priority Date Filing Date
DE102007063960.2A Active DE102007063960B3 (de) 2006-08-15 2007-08-10 Synchronisieren eines Übersetzungspufers (TLB) mit einer erweiterten Seitenwechseltabelle
DE102007063876.2A Ceased DE102007063876A1 (de) 2006-08-15 2007-08-10 Synchronisieren eines Translation-Lookaside-Pufferspeichers mit einer erweiterten Paging-Tabelle
DE102007037814.0A Active DE102007037814B4 (de) 2006-08-15 2007-08-10 Synchronisieren eines Translation-Lookaside-Pufferspeichers mit einer erweiterten Paging-Tabelle

Family Applications Before (2)

Application Number Title Priority Date Filing Date
DE102007063960.2A Active DE102007063960B3 (de) 2006-08-15 2007-08-10 Synchronisieren eines Übersetzungspufers (TLB) mit einer erweiterten Seitenwechseltabelle
DE102007063876.2A Ceased DE102007063876A1 (de) 2006-08-15 2007-08-10 Synchronisieren eines Translation-Lookaside-Pufferspeichers mit einer erweiterten Paging-Tabelle

Country Status (6)

Country Link
US (18) US7555628B2 (de)
JP (3) JP4849372B2 (de)
KR (1) KR100944563B1 (de)
CN (2) CN101149707B (de)
DE (3) DE102007063960B3 (de)
GB (1) GB2441039B (de)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7555628B2 (en) 2006-08-15 2009-06-30 Intel Corporation Synchronizing a translation lookaside buffer to an extended paging table
WO2008126202A1 (ja) * 2007-03-23 2008-10-23 Fujitsu Limited ストレージシステムの負荷分散プログラム、ストレージシステムの負荷分散方法、及びストレージ管理装置
US8799620B2 (en) * 2007-06-01 2014-08-05 Intel Corporation Linear to physical address translation with support for page attributes
US9213651B2 (en) 2009-06-16 2015-12-15 Vmware, Inc. Synchronizing a translation lookaside buffer with page tables
US8479295B2 (en) 2011-03-30 2013-07-02 Intel Corporation Method and apparatus for transparently instrumenting an application program
US9916257B2 (en) * 2011-07-26 2018-03-13 Intel Corporation Method and apparatus for TLB shoot-down in a heterogeneous computing system supporting shared virtual memory
US20130219146A1 (en) * 2012-02-16 2013-08-22 Micron Technology, Inc. Method, device and system for a configurable address space for non-volatile memory
US9182984B2 (en) * 2012-06-15 2015-11-10 International Business Machines Corporation Local clearing control
US9256531B2 (en) * 2012-06-19 2016-02-09 Samsung Electronics Co., Ltd. Memory system and SoC including linear addresss remapping logic
KR101420754B1 (ko) * 2012-11-22 2014-07-17 주식회사 이에프텍 비휘발성 메모리 시스템 및 이를 위한 맵핑 테이블 관리 방법
US11249652B1 (en) 2013-01-28 2022-02-15 Radian Memory Systems, Inc. Maintenance of nonvolatile memory on host selected namespaces by a common memory controller
US10445229B1 (en) 2013-01-28 2019-10-15 Radian Memory Systems, Inc. Memory controller with at least one address segment defined for which data is striped across flash memory dies, with a common address offset being used to obtain physical addresses for the data in each of the dies
US9652376B2 (en) 2013-01-28 2017-05-16 Radian Memory Systems, Inc. Cooperative flash memory control
US9619387B2 (en) * 2014-02-21 2017-04-11 Arm Limited Invalidating stored address translations
US20150261688A1 (en) * 2014-03-14 2015-09-17 International Business Machines Corporation Extended page table for i/o address translation
WO2016003646A1 (en) * 2014-06-30 2016-01-07 Unisys Corporation Enterprise management for secure network communications over ipsec
EP3172673B1 (de) * 2014-07-21 2020-09-02 VIA Alliance Semiconductor Co., Ltd. Adressübersetzungscache mit unterstützung von gleichzeitiger ungültigkeitserklärung von einträgen mit gemeinsamem kontext
US9542118B1 (en) 2014-09-09 2017-01-10 Radian Memory Systems, Inc. Expositive flash memory control
US9665505B2 (en) 2014-11-14 2017-05-30 Cavium, Inc. Managing buffered communication between sockets
US9684606B2 (en) * 2014-11-14 2017-06-20 Cavium, Inc. Translation lookaside buffer invalidation suppression
US9697137B2 (en) 2014-11-14 2017-07-04 Cavium, Inc. Filtering translation lookaside buffer invalidations
US9870328B2 (en) * 2014-11-14 2018-01-16 Cavium, Inc. Managing buffered communication between cores
US9727359B2 (en) * 2015-04-27 2017-08-08 Red Hat Israel, Ltd. Virtual machine function based sub-page base address register access for peripheral component interconnect device assignment
US9792223B2 (en) * 2015-05-11 2017-10-17 Via Alliance Semiconductor Co., Ltd. Processor including load EPT instruction
CN105487837B (zh) * 2015-05-11 2018-10-09 上海兆芯集成电路有限公司 具有载入扩展页表指令的处理器
US10007435B2 (en) 2015-05-21 2018-06-26 Micron Technology, Inc. Translation lookaside buffer in memory
US10942683B2 (en) 2015-10-28 2021-03-09 International Business Machines Corporation Reducing page invalidation broadcasts
US9898226B2 (en) 2015-10-28 2018-02-20 International Business Machines Corporation Reducing page invalidation broadcasts in virtual storage management
US10216643B2 (en) 2015-11-23 2019-02-26 International Business Machines Corporation Optimizing page table manipulations
JP6607798B2 (ja) * 2016-01-29 2019-11-20 株式会社ジャパンディスプレイ 表示装置
US20210026950A1 (en) * 2016-03-07 2021-01-28 Crowdstrike, Inc. Hypervisor-based redirection of system calls and interrupt-based task offloading
US9779028B1 (en) 2016-04-01 2017-10-03 Cavium, Inc. Managing translation invalidation
US10725807B2 (en) 2016-10-13 2020-07-28 Red Hat Israel, Ltd. Page table entry caching for virtual device emulation
US10997066B2 (en) * 2018-02-20 2021-05-04 Samsung Electronics Co., Ltd. Storage devices that support cached physical address verification and methods of operating same
CN108959127B (zh) * 2018-05-31 2021-02-09 华为技术有限公司 地址转换方法、装置及系统
US11954026B1 (en) * 2018-09-18 2024-04-09 Advanced Micro Devices, Inc. Paging hierarchies for extended page tables and extended page attributes
US11803468B2 (en) * 2018-09-19 2023-10-31 Seagate Technology Llc Data storage system with write back cache
US10891238B1 (en) 2019-06-28 2021-01-12 International Business Machines Corporation Dynamically joining and splitting dynamic address translation (DAT) tables based on operational context
US11074195B2 (en) 2019-06-28 2021-07-27 International Business Machines Corporation Access to dynamic address translation across multiple spaces for operational context subspaces
US10970224B2 (en) * 2019-06-28 2021-04-06 International Business Machines Corporation Operational context subspaces
CN112463657B (zh) * 2019-09-09 2024-06-18 阿里巴巴集团控股有限公司 一种地址转换缓存清除指令的处理方法和处理装置
US20210406199A1 (en) * 2020-06-25 2021-12-30 Intel Corporation Secure address translation services using cryptographically protected host physical addresses

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040054518A1 (en) 2002-09-17 2004-03-18 International Business Machines Corporation Method and system for efficient emulation of multiprocessor address translation on a multiprocessor host
US20040064668A1 (en) 2002-09-26 2004-04-01 Todd Kjos Memory addressing for a virtual machine implementation on a computer processor supporting virtual hash-page-table searching
US20040117593A1 (en) 2002-12-12 2004-06-17 Richard Uhlig Reclaiming existing fields in address translation data structures to extend control over memory acceses
US20060026383A1 (en) 2004-07-31 2006-02-02 Dinechin Christophe De Method for efficient virtualization of physical memory in a virtual-machine monitor
EP1681630A1 (de) 2005-01-14 2006-07-19 Intel Corporation Virtualisierung eines physischen Speichers in einem virtuellen Maschinensystem
WO2006081582A2 (en) 2005-01-28 2006-08-03 Intel Corporation A method and apparatus for supporting address translation in a virtual machine environment

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4456954A (en) * 1981-06-15 1984-06-26 International Business Machines Corporation Virtual machine system with guest architecture emulation using hardware TLB's for plural level address translations
JPS6184754A (ja) 1984-10-03 1986-04-30 Hitachi Ltd 拡張アドレス変換装置
JPS62295147A (ja) * 1986-06-16 1987-12-22 Hitachi Ltd 仮想計算機システム
US5109496A (en) 1989-09-27 1992-04-28 International Business Machines Corporation Most recently used address translation system with least recently used (LRU) replacement
EP0425077A3 (en) 1989-10-26 1992-07-15 Westinghouse Electric Corporation System enabling control information display format changes during on-line control of a plant or process
EP0425771A3 (en) * 1989-11-03 1992-09-02 International Business Machines Corporation An efficient mechanism for providing fine grain storage protection intervals
US5293595A (en) 1990-12-17 1994-03-08 Unisys Corporation Paging system using extension tables for conflict resolution
JPH04357540A (ja) 1991-03-28 1992-12-10 Ricoh Co Ltd マップドファイル仮想記憶方式
JPH05241965A (ja) * 1992-02-28 1993-09-21 Fuji Xerox Co Ltd メモリ管理装置
US5675762A (en) 1992-04-03 1997-10-07 International Business Machines Corporation System for locking down part of portion of memory and updating page directory with entry corresponding to part of portion of the memory locked down
DE19523358C8 (de) * 1995-06-28 2006-01-26 Volkswagen Ag Arretiermechanismus für eine Kopfstütze
US5893152A (en) * 1996-03-08 1999-04-06 Sun Microsystems, Inc. Method and apparatus that detects and tolerates inconsistencies between the cache and main memory, and the translation lookaside buffer and the virtual memory page table in main memory
US5809563A (en) * 1996-11-12 1998-09-15 Institute For The Development Of Emerging Architectures, Llc Method and apparatus utilizing a region based page table walk bit
JP3154949B2 (ja) 1997-02-28 2001-04-09 川崎重工業株式会社 鉄カーバイドの製造方法
JP3607540B2 (ja) 1999-08-18 2005-01-05 エヌイーシーシステムテクノロジー株式会社 プログラム単位メモリアクセス属性管理方式
US6393544B1 (en) 1999-10-31 2002-05-21 Institute For The Development Of Emerging Architectures, L.L.C. Method and apparatus for calculating a page table index from a virtual address
US6907600B2 (en) 2000-12-27 2005-06-14 Intel Corporation Virtual translation lookaside buffer
US6643759B2 (en) 2001-03-30 2003-11-04 Mips Technologies, Inc. Mechanism to extend computer memory protection schemes
DE10127198A1 (de) 2001-06-05 2002-12-19 Infineon Technologies Ag Vorrichtung und Verfahren zum Ermitteln einer physikalischen Adresse aus einer virtuellen Adresse unter Verwendung einer hierarchischen Abbildungsvorschrift mit komprimierten Knoten
US8051301B2 (en) * 2001-11-13 2011-11-01 Advanced Micro Devices, Inc. Memory management system and method providing linear address based memory access security
DE10208765A1 (de) 2002-02-28 2003-09-18 Infineon Technologies Ag Datenverarbeitungsvorrichtung
US6996748B2 (en) 2002-06-29 2006-02-07 Intel Corporation Handling faults associated with operation of guest software in the virtual-machine architecture
US7124327B2 (en) 2002-06-29 2006-10-17 Intel Corporation Control over faults occurring during the operation of guest software in the virtual-machine architecture
US6970990B2 (en) 2002-09-30 2005-11-29 International Business Machines Corporation Virtual mode virtual memory manager method and apparatus
US6915405B2 (en) 2002-12-04 2005-07-05 Bull Hn Information Systems Inc. Emulated target associative memory system with a multi-digit incrementable validity counter
US7284100B2 (en) * 2003-05-12 2007-10-16 International Business Machines Corporation Invalidating storage, clearing buffer entries, and an instruction therefor
US7409487B1 (en) 2003-06-30 2008-08-05 Vmware, Inc. Virtualization system for computers that use address space indentifiers
US7451443B2 (en) 2003-10-01 2008-11-11 Hewlett-Packard Development Company, L.P. Online computer maintenance utilizing a virtual machine monitor
US7376949B2 (en) 2003-10-01 2008-05-20 Hewlett-Packard Development Company, L.P. Resource allocation and protection in a multi-virtual environment
US7552426B2 (en) 2003-10-14 2009-06-23 Microsoft Corporation Systems and methods for using synthetic instructions in a virtual machine
US7069389B2 (en) * 2003-11-26 2006-06-27 Microsoft Corporation Lazy flushing of translation lookaside buffers
US7206915B2 (en) 2004-06-03 2007-04-17 Emc Corp Virtual space manager for computer having a physical address extension feature
US7260702B2 (en) 2004-06-30 2007-08-21 Microsoft Corporation Systems and methods for running a legacy 32-bit x86 virtual machine on a 64-bit x86 processor
US7562179B2 (en) * 2004-07-30 2009-07-14 Intel Corporation Maintaining processor resources during architectural events
US7340582B2 (en) * 2004-09-30 2008-03-04 Intel Corporation Fault processing for direct memory access address translation
US9058292B2 (en) 2004-12-29 2015-06-16 Intel Corporation System and method for one step address translation of graphics addresses in virtualization
US7370160B2 (en) * 2005-06-29 2008-05-06 Intel Corporation Virtualizing memory type
US7797463B2 (en) * 2005-06-30 2010-09-14 Intel Corporation Hardware assisted receive channel frame handling via data offset comparison in SAS SSP wide port applications
US7555628B2 (en) * 2006-08-15 2009-06-30 Intel Corporation Synchronizing a translation lookaside buffer to an extended paging table
US7802050B2 (en) * 2006-09-29 2010-09-21 Intel Corporation Monitoring a target agent execution pattern on a VT-enabled system
US7882318B2 (en) * 2006-09-29 2011-02-01 Intel Corporation Tamper protection of software agents operating in a vitual technology environment methods and apparatuses
DE102009024487A1 (de) * 2009-06-10 2010-12-16 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verstellvorrichtung für einen Kraftfahrzeugsitz sowie Verfahren zur Montage der Verstellvorrichtung

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040054518A1 (en) 2002-09-17 2004-03-18 International Business Machines Corporation Method and system for efficient emulation of multiprocessor address translation on a multiprocessor host
US20040064668A1 (en) 2002-09-26 2004-04-01 Todd Kjos Memory addressing for a virtual machine implementation on a computer processor supporting virtual hash-page-table searching
US20040117593A1 (en) 2002-12-12 2004-06-17 Richard Uhlig Reclaiming existing fields in address translation data structures to extend control over memory acceses
US20060026383A1 (en) 2004-07-31 2006-02-02 Dinechin Christophe De Method for efficient virtualization of physical memory in a virtual-machine monitor
EP1681630A1 (de) 2005-01-14 2006-07-19 Intel Corporation Virtualisierung eines physischen Speichers in einem virtuellen Maschinensystem
US20060161719A1 (en) 2005-01-14 2006-07-20 Bennett Steven M Virtualizing physical memory in a virtual machine system
WO2006081582A2 (en) 2005-01-28 2006-08-03 Intel Corporation A method and apparatus for supporting address translation in a virtual machine environment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
„AMD64 Technology, AMD64 Architecture Programmer's Manual, Volume 2: System Programming, Publication No. 24593, Rev. 3.11, Dezember 2005
AMD64 Technology, AMD64 Architecture Programmer's Manual, Volume 2: System Programming, Publication No. 24593, Rev. 3.11, Dezember 2005, S. 464 u. 465

Also Published As

Publication number Publication date
US8949571B2 (en) 2015-02-03
JP5663069B2 (ja) 2015-02-04
US9372807B2 (en) 2016-06-21
CN101814056A (zh) 2010-08-25
DE102007037814A1 (de) 2008-03-27
US9372806B2 (en) 2016-06-21
CN101149707A (zh) 2008-03-26
US20140059320A1 (en) 2014-02-27
US20100011186A1 (en) 2010-01-14
US20180196758A1 (en) 2018-07-12
US9298640B2 (en) 2016-03-29
KR100944563B1 (ko) 2010-02-25
US20160019140A1 (en) 2016-01-21
CN101149707B (zh) 2010-06-02
JP5379203B2 (ja) 2013-12-25
US20160019164A1 (en) 2016-01-21
US20180196759A1 (en) 2018-07-12
US20160019162A1 (en) 2016-01-21
US8099581B2 (en) 2012-01-17
US9251094B2 (en) 2016-02-02
US10180911B2 (en) 2019-01-15
JP2008077642A (ja) 2008-04-03
US8601233B2 (en) 2013-12-03
US20120110299A1 (en) 2012-05-03
JP4849372B2 (ja) 2012-01-11
US20160019166A1 (en) 2016-01-21
DE102007063876A1 (de) 2015-06-18
US7555628B2 (en) 2009-06-30
US10747682B2 (en) 2020-08-18
US20150205728A1 (en) 2015-07-23
KR20080015763A (ko) 2008-02-20
DE102007063960B3 (de) 2021-12-16
US20160019165A1 (en) 2016-01-21
US9141555B2 (en) 2015-09-22
US20180060247A1 (en) 2018-03-01
GB0715604D0 (en) 2007-09-19
JP2012053888A (ja) 2012-03-15
JP2014013615A (ja) 2014-01-23
US9262338B1 (en) 2016-02-16
US9330021B2 (en) 2016-05-03
US20080046679A1 (en) 2008-02-21
US20160019163A1 (en) 2016-01-21
CN101814056B (zh) 2013-03-27
US8296546B2 (en) 2012-10-23
US20150039850A1 (en) 2015-02-05
GB2441039A (en) 2008-02-20
US9678890B2 (en) 2017-06-13
GB2441039B (en) 2009-01-28
US20150205723A1 (en) 2015-07-23
US9298641B2 (en) 2016-03-29
US20130054935A1 (en) 2013-02-28
US9122624B2 (en) 2015-09-01

Similar Documents

Publication Publication Date Title
DE102007037814B4 (de) Synchronisieren eines Translation-Lookaside-Pufferspeichers mit einer erweiterten Paging-Tabelle
DE602004011018T2 (de) Ungültigkeitserklärung eines speichers und löschen von puffereinträgen
DE112005003859B4 (de) Verwalten von Prozessorressourcen während Architekturereignissen
DE10357804B4 (de) Neu-Beanspruchung vorhandener Felder in Adressübersetzungsdatenstrukturen zum Erweitern der Kontrolle über Speicherzugriffe
DE112005002405B4 (de) Fehlerverarbeitung für Direktspeicherzugriffs-Adreßübersetzung
DE3751645T2 (de) Anteilige Nutzung von Kopie-beim-Schreiben-Segmenten in einer Datenverarbeitungsanlage mit virtuellen Maschinen und virtuellem Speicher
DE102007062744B4 (de) Guest-Host-Adressübersetzung für den Zugriff von Geräten auf einen Speicher in einem partitionierten System
DE10393920B4 (de) Verfahren und Systeme zur Steuerung virtueller Maschinen
US6055617A (en) Virtual address window for accessing physical memory in a computer system
DE112007001988T5 (de) Gemeinsames Nutzen von Informationen durch Gäste in einer Virtuelle-Maschine-Umgebung
DE102008025476A1 (de) Übersetzung einer virtuellen Adresse in eine physikalische Adresse mit Unterstützung von Seitenattributen
US9817689B2 (en) Dirty page tracking of guest-uncached memory
DE102013017509A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE112010004971T5 (de) Ein System, Verfahren und eine Vorrichtung für einen Cache-Flush eines Seitenbereichs und TLB Invalidierung eines Bereichs von Einträgen
DE102014014076A1 (de) Reduzierte Adressenkonvertierung mit mehreren Seitengrößen
DE102013017511A1 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
DE112007001466T5 (de) Behandlung von Adressübersetzungen und Ausnahmen einer Heterogenen Ressource
GB2514107A (en) Page table data management
DE112013003731T5 (de) Neue befehls- und hocheffiziente Mikroarchitektur zum ermöglichen einer sofortigen Kontextumschaltung für Benutzerebenen-Threading
DE112016005919T5 (de) Verfahren und Vorrichtung zum Sub-Seiten-Schreibschutz
DE112017003332T5 (de) Öffnungszugriffsprozessoren, verfahren, systeme und befehle
DE112018005404T5 (de) Vereinfachen des zugriffs auf lokalitätsdomäneninformationen eines speichers
DE112016004297T5 (de) Technologien für mehrstufige virtualisierung
DE102018002294A1 (de) Effizientes bereichsbasiertes speicher-rückschreiben zum verbessern der host-zu-geräte-kommunikation für optimale energie und leistung
DE112010003942T5 (de) Einrichtung zum Setzen von Schlüsseln ohne Stilllegung

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R130 Divisional application to

Ref document number: 102007063876

Country of ref document: DE

R130 Divisional application to

Ref document number: 102007063876

Country of ref document: DE

Effective date: 20150415

R002 Refusal decision in examination/registration proceedings
R006 Appeal filed
R008 Case pending at federal patent court
R082 Change of representative

Representative=s name: BOEHMERT & BOEHMERT ANWALTSPARTNERSCHAFT MBB -, DE

Representative=s name: MUELLER HOFFMANN & PARTNER PATENTANWAELTE MBB, DE

R130 Divisional application to

Ref document number: 102007063876

Country of ref document: DE

Ref document number: 102007063960

Country of ref document: DE

Ref document number: 102007063985

Country of ref document: DE

R130 Divisional application to

Ref document number: 102007063876

Country of ref document: DE

Ref document number: 102007063960

Country of ref document: DE

Ref document number: 102007063985

Country of ref document: DE

R009 Remittal by federal patent court to dpma for new decision or registration
R082 Change of representative

Representative=s name: BOEHMERT & BOEHMERT ANWALTSPARTNERSCHAFT MBB -, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final