-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die vorliegende Erfindung betrifft im Allgemeinen eine virtualisierte Computer-Architektur und insbesondere eine paravirtualisierte virtuelle GPU.
-
Beschreibung der betreffenden Technik
-
Computer-Virtualisierung ist eine Technik, welche Einkapseln einer physikalischen Rechenmaschine-Plattform in eine virtuelle Maschine involviert, welche unter der Kontrolle von Virtualisierungs-Software auf einer Hardware-Rechenplattform, oder „Host” ausgeführt wird. Eine virtuelle Maschine hat sowohl virtuelle System-Hardware und Gast-Betriebssystem-Software. In typischen virtualisierten Systemen sind irgendwelche physikalischen Hardware-Ressourcen, welche in dem System umfasst sind, über Emulations-Module für die virtuelle Maschine exponiert. Emulations-Module erlauben, eine Geräte-Funktionalität, welche für einzelne Benutzung ausgelegt sind, um ein Modell zu erweitern, welche Mehrfachbenutzung erlaubt. Zum Beispiel muss dafür, dass eine Maschine mit einem Hardware-Eingabegerät, wie etwa eine Maus, interagiert, ein Software-Emulations-Modul bereitgestellt werden, welches die Operationen der Maus exponiert. Die virtuelle Maschine interagiert dann mit der Maus über das Software-Emulations-Modul.
-
Für einfache Geräte, welche gemeinsame Schnittstellen und Niedrig-Performanz-Bedürfnisse benutzen, wie etwa eine Maus oder eine Tastatur, ist das Software-Emulations-Modell effektiv. Zugreifen jedoch auf komplexere Geräte, welche umfassendere (more comprehensive) Schnittstellen haben und höhere Performanz-Bedürfnisse haben, wie etwa eine Grafik-Verarbeitungseinheit (GPU), über ein Software-Emulations-Modul in einem virtualisierten System ergibt zwei Hauptprobleme. Weil eine GPU eine hochkomplizierte Verarbeitungseinheit ist, ist erstens ein Bereitstellen eines Software-Emulations-Moduls, welches umfassend ist und welches den großen Bereich von Funktionalität, welche mittels der GPU bereitgestellt ist, exponiert, eine sehr schwierige Aufgabe. Daher mangelt es momentanen Software-Emulations-Modulen, welche versuchen alle der Funktionalitäten der GPU zu exponieren, etwa dass Anwendungen, welche in einer virtuellen Maschine laufen, welche die GPU benutzen, nicht optimal laufen, wenn überhaupt. Zweitens erzeugen die Ineffektivitäten der Abstraktion häufig Flaschenhälse und Ineffizienzen, weil die GPU-Schnittstelle komplexer und performanzkritisch ist.
-
Eine Lösung für die Ineffektivitäten, welche oben beschrieben sind, ist es, eine unabhängige GPU für jede virtuelle Maschine, welche auf dem Host ausführt, bereitzustellen. Solch eine Lösung ist jedoch extrem aufwendig zu implementieren und ist nicht skalierbar. Daher kann eine solche Lösung nicht effektiv über eine große Verschiedenheit von Verbrauchern implementiert werden, welche es benötigen, auf eine GPU von innerhalb einer virtuellen Maschine zuzugreifen.
-
Demgemäß ist, was in der Technik benötigt ist, ein System und ein Verfahren zum effizienten Teilen einer einzelnen GPU über mehrere Benutzer oder virtuelle Maschinen ohne die Hardware vergrößern zu müssen (scale up).
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Eine Ausführungsform der vorliegenden Erfindung führt ein Computer-System aus, welches eine primäre Verarbeitungseinheit, eine sekundäre Verarbeitungseinheit, welche mit der primären Verarbeitungseinheit gekoppelt ist und über eine Mehrzahl von zuweisbaren Schnittstellen zugreifbar ist, eine Mehrzahl von Gast-virtuelle-Maschinen, welche auf der primären Verarbeitungseinheit ausführen, aufweist, wobei jede Gast-virtuelle-Maschine einen Treiber aufweist, welcher mit der sekundären Verarbeitungseinheit assoziiert ist, und eine privilegierte virtuelle Maschine, welche auf der primären Verarbeitungseinheit ausführt und konfiguriert ist, einen verschiedenen Satz von zuweisbaren Schnittstellen, welche in der Mehrzahl von zuweisbaren Schnittstellen umfasst sind, an jeden der Treiber zu allozieren, welcher in der Mehrzahl von Gast-virtuelle-Maschinen umfasst ist, wobei ein erster Satz von zuweisbaren Schnittstellen, welcher für einen ersten Treiber alloziert ist, welcher in einer ersten Gast-virtuelle-Maschine umfasst ist, dem ersten Treiber ermöglicht, auf die sekundäre Verarbeitungseinheit zuzugreifen, ohne mit irgendeinem der anderen Treiber in Konflikt zu geraten, welche in der Mehrzahl von Gast-virtuelle-Maschinen umfasst sind.
-
Ein Vorteil der hierin beschriebenen Techniken ist, dass ein Gast-GPU-Treiber, welcher in einer Gast-virtuelle-Maschine ausführt, in der Lage ist, direkt zumindest einen Teil der Verarbeitungs-Fähigkeiten der GPU über einen zugewiesenen Satz von Schnittstellen zu nutzen (harness). Mit solch einem direkten Zugriff wird die Performanz eines Systems erhöht, wobei mehrere Gast-VMs wetteifern, auf die GPU zuzugreifen, da die Virtualisierungs-Schicht eine minimale Intervention beim Einrichten oder Aufsetzen (setting up) und Kontrollieren des Zugriffs für die Gast-VMs durchführt.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
So dass die Art und Weise, in welcher die oben zitierten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, kann eine besondere Beschreibung der Erfindung, welche oben kurz zusammengefasst ist, durch Bezugnahme auf Ausführungsformen erhalten werden, von welchen einige in den angehängten Zeichnungen illustriert sind. Es ist jedoch bemerkt, dass die angehängten Zeichnungen nur typische Ausführungsformen dieser Erfindung illustrieren und deshalb nicht anzusehen sind, ihren Geltungsbereich zu begrenzen, da die Erfindung andere gleich effektive Ausführungsformen zulassen kann.
-
1 ist ein Blockdiagramm, welches ein Computer-System illustriert, welches konfiguriert ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren;
-
2 ist ein Blockdiagramm, welches eine virtualisierte Rechen-Umgebung illustriert, welche innerhalb des Computer-Systems von 1 ausführt, gemäß einer Ausführungsform der vorliegenden Erfindung;
-
3 ist eine detailliertere Ansicht der privilegierten VM und der Gast-VM der 2, gemäß einer Ausführungsform der vorliegenden Erfindung;
-
4 ist eine konzeptionelle Illustration der Interaktionen zwischen der privilegierten VM und der Gast-VM von 2 und der GPU von 1, gemäß einer Ausführungsform der vorliegenden Erfindung; und
-
5A und 5B ist ein Flussdiagramm von Verfahrensschritten zum Ermöglichen der Gast-VM auf die GPU in einer paravirtualisierten Weise zuzugreifen, gemäß einer Ausführungsform der vorliegenden Erfindung.
-
DETAILLIERTE BESCHREIBUNG
-
In der folgenden Beschreibung werden zahlreiche spezifische Details ausgeführt, um ein durchgängigeres Verständnis der vorliegenden Erfindung bereitzustellen. Es wird jedoch für den Fachmann in der Technik ersichtlich sein, dass die vorliegende Erfindung ohne ein oder mehrere dieser spezifischen Details praktiziert werden kann. In anderen Fällen sind wohl bekannte Merkmale nicht beschrieben worden, um ein Verschleiern der vorliegenden Erfindung zu vermeiden.
-
1 ist ein Blockdiagramm, welches ein Computersystem 100 illustriert, welches konfiguriert ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. Computersystem 100 umfasst eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104, welcher über einen Zwischenverbindungspfad (interconnection path) kommuniziert, welcher eine Speicherbrücke 105 umfassen kann. Speicherbrücke 105, welche z. B. ein Northbridge-Chip sein kann, ist über einen Bus oder einen anderen Kommunikationspfad 106 (z. B. HyperTransport-Link) mit einer I/O-(Eingabe/Ausgabe)-Brücke 107 verbunden. I/O-Brücke 107, welche z. B. ein Southbridge-Chip sein kann, empfängt Benutzereingabe von einem oder mehreren Benutzer-Eingabegeräten 108 (z. B. Tastatur, Maus) und leitet die Eingabe an CPU 102 über Pfad 106 und Speicherbrücke 105 weiter. Eine GPU 112 ist mit der Speicherbrücke 105 über einen Bus oder einen anderen Kommunikationspfad 113 (z. B. einen PCI-Express Accelerated Graphics Port, oder HyperTransport-Link) gekoppelt; in einer Ausführungsform ist die GPU 112 ein Grafik-Subsystem, welches Pixel an ein Anzeigegerät 110 (z. B. ein konventioneller CRT- oder LCD-basierter Monitor) liefert. Eine Systemplatte 114 ist auch mit der I/O-Brücke 107 verbunden. Ein Switch 116 stellt Verbindungen zwischen I/O-Brücke 107 und anderen Komponenten bereit, wie etwa ein Netzwerkadapter 118 und verschiedenen Hinzufügungskarten (Add-in-Cards) 120 und 121. Andere Komponenten (nicht explizit gezeigt) umfassend USB- oder andere Port-Verbindungen, CD-Laufwerke, DVD-Laufwerke, Filmaufnahmegeräte, und dergleichen, können auch mit der I/O-Brücke 107 verbunden sein. Kommunikationspfade, welche die verschiedenen Komponenten in 1 wechselseitig verbinden, können unter Benutzung irgendwelcher geeigneten Protokolle implementiert sein, wie etwa PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport, oder irgendeines oder irgendwelcher Bus- oder Punkt-zu-Punkt-Kommunikations-Protokoll(e), und Verbindungen zwischen verschiedenen Geräten können verschiedene Protokolle benutzen, wie in der Technik bekannt ist.
-
In einer Ausführungsform inkorporiert die GPU 112 Schaltung, welche für Grafik- und Video-Verarbeitung optimiert ist, einschließlich zum Beispiel Videoausgabe-Schaltung, und konstituiert eine Grafik-Verarbeitungseinheit (GPU). In einer anderen Ausführungsform umfasst die GPU 112 Schaltung, welche für Allgemeinzweck-Verarbeitung optimiert ist, während die darunter liegende Computer-Architektur, welche im größeren Detail hierin beschrieben ist, beibehalten ist. In noch einer anderen Ausführungsform kann die GPU 102 mit einem oder mit mehreren anderen Systemelementen integriert sein, wie etwa der Speicherbrücke 105, CPU 102 und I/O-Brücke 107, um ein System auf dem Chip (system an chip) (SoC) zu bilden.
-
Es wird geschätzt werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und der Anordnung von Brücken, der Anzahl von CPUs 102, und der Anzahl von Parallel-Verarbeitungs-Subsystemen 112 kann wie gewünscht modifiziert werden. Zum Beispiel ist in einigen Ausführungsformen Systemspeicher 104 mit CPU 102 direkt gekoppelt anstatt durch eine Brücke, und andere Geräte kommunizieren mit Systemspeicher 104 über Speicherbrücke 105 und CPU 102. In anderen alternativen Topologien ist GPU 112 mit I/O-Brücke 107 oder direkt mit CPU 102 verbunden anstatt mit der Speicherbrücke 105. In noch anderen Ausführungsformen können die I/O-Brücke 107 und Speicherbrücke 105 in einen einzelnen Chip integriert sein. Große Ausführungsformen können zwei oder mehr CPUs 102 und zwei oder mehr GPUs 112 umfassen. Die besonderen Komponenten, welche hierin gezeigt sind, sind optional; z. B. könnte irgendeine Anzahl von Hinzufügungskarten oder peripheren Geräten unterstützt sein. In einigen Ausführungsformen ist der Switch 116 eliminiert und der Netzwerkadapter 116 und Hinzufügungskarten 120, 121 verbinden direkt mit der I/O-Brücke 107.
-
In einer Ausführungsform umfasst die GPU 112 eine oder mehrere Parallel-Verarbeitungseinheiten (PPUs) (nicht gezeigt), wobei jede von diesen mit einem lokalen Parallel-Verarbeitungs-(PP)-Speicher (auch nicht gezeigt) gekoppelt ist. Im Allgemeinen umfasst eine GPU eine Anzahl U von PPUs, wobei U ≥ 1. PPUs und Parallel-Verarbeitungs-Speicher können unter Benutzung von einem oder mehreren integrierte-Schaltung-Geräten implementiert sein, wie etwa programmierbare Prozessoren, Anwendungsspezifische integrierte Schaltungen (ASICs), oder Speichergeräte, oder in irgendeiner anderen technisch machbaren Weise. In einigen Ausführungsformen sind einige oder alle der PPUs in GPU 112 Grafikprozessoren mit Render-Pipelines, welche konfiguriert sein können, um verschiedene Aufgaben durchzuführen, welche das Erzeugen von Pixeldaten von Grafik-Daten, welche mittels CPU 102 und/oder Systemspeicher 104 über Speicherbrücke 105 und Kommunikationspfad 113 zugeführt sind, ein Interagieren mit lokalem Parallel-Verarbeitungs-Speicher (welcher als ein Grafikspeicher benutzt werden kann einschließlich z. B. eines konventionellen Bildpuffers (frame buffer), um Pixeldaten zu speichern und zu aktualisieren, ein Liefern von Pixeldaten an das Anzeigegeräte 110, und dergleichen betreffen. In einigen Ausführungsformen kann GPU 112 eine oder mehrere PPUs umfassen, welche als Grafikprozessoren operieren, und eine oder mehrere andere PPUs, welche für Allgemeinzweck-Berechnungen benutzt werden können. Die PPUs können identisch sein oder verschieden sein und jede PPU kann ihr eigenes dediziertes Parallel-Verarbeitungs-Speichergerät(e) haben oder braucht nicht dedizierte Parallel-Verarbeitungs-Speichergerät(e) zu haben. Eine oder mehrere PPUs können Daten an das Anzeigegeräte 110 ausgeben oder jede PPU kann Daten an eines oder mehrere Anzeigegeräte 110 ausgeben.
-
Im Betrieb ist CPU 102 der Master-Prozessor von Computersystems 100, welcher Operationen von anderen Systemkomponenten steuert und koordiniert. Insbesondere stellt CPU 102 Befehle aus (issues), welche den Betrieb von GPU 112 steuern. In einigen Ausführungsformen schreibt CPU 102 einen Strom von Befehlen für die PUT 112 an einen Befehlspuffer, welcher in dem Systemspeicher 104, Parallel-Verarbeitungs-Speicher 204 oder irgendeiner anderen Speicherstelle, welche für sowohl CPU 102 als GPU 112 zugreifbar ist, gespeichert ist. GPU 202 liest den Befehlsstrom von dem Befehlspuffer und führt dann Befehle asynchron relativ zu dem Betrieb von CPU 102 aus.
-
2 ist ein Blockdiagramm, welches eine virtualisierte Rechen-Umgebung (virtualized computation invironment) illustriert, welche innerhalb des Computer-Systems 100 der 1 ausführt, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst der System-Speicher 104 eine privilegierte virtuelle Maschine (VM) 202, einen Satz von Gast-virtuelle-Maschinen 204 und eine Virtualisierungs-Schicht 206.
-
Die Virtualisierungs-Schicht 206 umfasst einen Hypervisor 208, ein Hardware-Virtualisierungs-Modul 220 und eine Eingabe-/Ausgabe-Speicher-Management-Einheit (IOMMU) 212. Der Hypervisor 208 ist ein System-Niveau-Software-Modul, welches mehreren Gast-VMs 204 erlaubt, gleichzeitig innerhalb des Computer-Systems 100 abzulaufen. Der Hypervisor 208 führt über (on top of) dem Hardware-Virtualisierungs-Modul 210 und der IOMMU 212 aus. Das Hardware-Virtualisierungs-Modul 210 ist konfiguriert, das Teilen oder gemeinsamen Nutzen (sharing) der Hardware-Ressourcen, wie etwa die CPU 102, innerhalb des Computer-Systems 100 zu unterstützen. Die IOMMU 212 ist eine Speicher-Management-Einheit, welche einen DMA-fähigen-I/O-Bus mit Systemspeicher 104 verbindet und ist konfiguriert, Gerätesichtbare virtuelle Adressen auf physikalische Adressen abzubilden. Im Betrieb emuliert der Hypervisor 208 mittels eines Gebrauchens der Dienste, welche mittels des Hardware-Virtualisierungs-Moduls 210 und der IOMMU 212 bereitgestellt sind, einen separaten physikalischen Adressraum für jede Gast-VM 204 und ist konfiguriert, virtuelle-Maschine-Seiten in physikalischen Speicher zu sperren (lock) („stecken”, („pin”)), wie etwa System-Speicher 104, um direkten Speicher-Zugriff (DMA) zwischen einem I/O-Gerät und einer virtuelle-Maschine-Seite zu unterstützen.
-
In einer Ausführungsform ist die IOMMU 212, welche in der Virtualisierungs-Schicht 206 umfasst ist, keine notwendige Komponente der Erfindung.
-
Die privilegierte VM 202 stellt I/O-Emulations-Software und einen Ressource-Manager bereit, welcher den Gast-VMs 204 erlaubt, auf die Hardware-Ressourcen innerhalb des Computer-Systems 104 über den Hypervisor 208 zuzugreifen. Die folgende Diskussion beschreibt in größerem Detail die Operationen der privilegierten VM 202 beim Bereitstellen von Zugriff auf die GPU 112 und das Anzeige-Gerät 110 für die Gast-VMs 204. In der folgenden Diskussion ist das „Host-Betriebssystem” das Betriebssystem für die privilegierte VM 202 und das „Gast-Betriebs-System” ist das Betriebssystem einer Gast-VM 204. Die Typen von Operations-System können über die Gast-VMs 204 und die privilegierte VM 202 variieren. Beispiele eines Gast-Betriebs-Systems umfassen irgendwelche der wohl bekannten gebräuchlichen Betriebssysteme, wie etwa Microsoft Windows, Linux und dergleichen.
-
3 ist eine detailliertere Ansicht der privilegierten VM 202 und der Gast-VM 204 der 2 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst die privilegierte VM 202 Hardware-Emulations-Software 302, ein GPU-Emulations-Modul 304, welches in die Hardware-Emulations-Software 302 eingesteckt ist (plugged into), welche ein Anzeige-Emulations-Modul 305 und einen Master-Resource-Manager (RM) 306 umfasst. Wie auch gezeigt ist, umfasst die Gast-VM 204 eine Anwendung 308, einen Gast-GPU-Treiber 310 und einen Proxy-RM 312.
-
Die Anwendung 308 ist ein Software-Modul, welches, wenn ausgeführt, eine oder mehrere Anweisungen übermittelt, welche mittels der GPU 112 zu verarbeiten sind. Die Anwendung 308 benutzt eine oder mehrere Anwendungs-Programmierungs-Schnittstellen (APIs), wie etwa die API 310, welche mittels des Gast-GPU-Treibers 310 exponiert ist, um den Betrieb der GPU 112 zu steuern. Der Gast-GPU-Treiber 310 ist ein Treiber, welcher mit der GPU 112 assoziiert ist, welche keine Kenntnis davon hat, dass die Anwendung 308 oder der Gast-GPU-Treiber 310 innerhalb einer virtuellen Maschine ausführt und nicht direkt innerhalb der Ausführungs-Umgebung der CPU 102.
-
Im Betrieb, wenn die Anwendung 308 als erstes Initialisierungs-Anweisungen an den Gast-GPU-Treiber 310 übermittelt, welche den Zugriff von verschiedenen Komponenten oder die Verarbeitungs-Fähigkeiten der GPU 112 erfordern, übermittelt der Gast-GPU-Treiber 310 eine Anfrage dahingehend, was der Gast-GPU-Treiber 310 als das Betriebs-System annimmt, welches auf der CPU 102 ausführt, zum Aufsetzen oder Einrichten eines Zugriffs auf die GPU 112. Die mittels des Gast-GPU-Treibers 310 übermittelte Anfrage wird mittels des GPU-Emulations-Moduls 304 eingefangen (trapped).
-
Der Proxy-Resource-Manager 312 stellt einen Kommunikations-Kanal zwischen dem Gast-GPU-Treiber 310 und der privilegierten VM 202 bereit. Dem Proxy-Resource-Manager 312 ist dabei wichtiger Weise bewusst, dass die Anwendung 308, der Gast-GPU-Treiber 310 und der Proxy-Resource-Manager innerhalb einer virtuellen Maschine ausführen. Daher führt der Proxy-Resource-Manager 312 Initialisierungs-Befehle, welche Zugriff auf Hardware-Ressourcen innerhalb des Computer-Systems 100 erfordern, an die privilegierte VM 202 zum Handhaben (handling). In einer Ausführungsform kommuniziert der Proxy-Resource-Manager 312 innerhalb der privilegierten VM 202 über entfernte Prozedur-Aufrufe (remote procedure calls) (RPCs). Der RPC-Kommunikations-Pfad ist auf virtuelle-Hardware-Schnittstellen und gemeinsamem Speicher implementiert, um somit zu erlauben, dass der RPC-Pfad unabhängig von dem Typ von Hypervisor 208 ist, welcher in der Virtualisierungs-Schicht 206 umfasst ist.
-
Im Betrieb wird die Anfrage zum Einrichten eines Zugriffs auf die GPU 112 mittels des Proxy-Resource-Managers 312 an das GPU-Emulations-Modul 304 geführt, welches dann die Anfrage an den Master-Resource-Manager 306 übermittelt, welcher in der privilegierten VM 202 umfasst ist. Der Master-Resource-Manager 306 ist ein Software-Modul, welches den Zugriff und die Interaktionen zwischen den verschiedenen Gast-VMs 304 und den Hardware-Ressourcen, welche in dem Computer-System 100 umfasst sind, managed. Insbesondere empfängt der Master-Resource-Manager 306 Zugriffsanfragen nach Hardware-Ressourcen, wie etwa die Eingabe-Geräte 108, GPU 112, etc., von den Gast-VMs 204 und bestimmt den Mechanismus zum Bereitstellen von Zugriff auf diese Hardware-Ressourcen für die Gast-VMs.
-
Auf Empfangen einer Anfrage zum Einrichten von Zugriff auf die GPU 112 hin alloziert der Master-Resource-Manager 306 einen Kanal, welcher mit der GPU 112 assoziiert ist, für die Gast-VM 204. Ein Kanal ist ein Hardware-Konstrukt, welches Anwendungen, wie etwa Anwendungen 308 erlaubt, direkt auf die GPU 112 zuzugreifen, wenn Befehle zur Ausführung innerhalb der GPU 112 übermittelt werden. Jeder Kanal entspricht einem anderen Satz von Kanal-Kontroll-Registern, welcher programmiert ist, den entsprechenden Kanal zu bevölkern (populate). Die GPU 112 ist mit einer vorbestimmten Anzahl von zugewiesenen Schnittstellen (hierin auch als „Kanäle” bezeichnet) assoziiert und der Master-Resource-Manager 306 alloziert eine vorkonfigurierte Anzahl dieser Kanäle für die Gast-VM 204. In einer Ausführungsform ist die Anzahl und die bestimmten Kanäle, welche für eine Gast-VM 204 alloziert sind, zufällig von dem Master-Resource-Manager 306 bestimmt.
-
Sobald ein Kanal an oder für die Gast-VM 204 mittels des Master-Resource-Managers 306 alloziert ist, wird das GPU-Emulations-Modul 304, welches in der Hardware-Emulations-Software 302 umfasst ist, benachrichtigt. Das GPU-Emulations-Modul 304 ist ein paravirtualisiertes Modell der GPU 112, welches Teile der GPU 112 emuliert, wie etwa gewisse Konfigurations-Informations-Register, und stellt einen direkten Zugriff auf andere Teile der GPU 112 für die Gast-VMs 204 bereit. Auf emulierte Teile der GPU 112 wird mittels der Gast-VMs 204 über das GPU-Emulations-Modul 204 zugegriffen und auf die direkt zugreifbaren Teile der GPU 112, wie etwa die Kanäle, wird von den Gast-VMs 204 direkt zugegriffen, sobald das Einrichten für diesen Zugriff mittels der privilegierten VM 202 komplettiert ist. In einer Ausführungsform ist das GPU-Emulations-Modul 304 mit der Hardware-Emulations-Software 202 über eine Plugin-API gekoppelt und ist daher unabhängig von dem Typ von Hypervisor 308.
-
Wenn das GPU-Emulations-Modul 304 benachrichtigt ist, dass ein Kanal an die Gast-VM 204 alloziert worden ist, bildet das GPU-Emulations-Modul 304 den Satz von Kontroll-Registern 316, welche dem allozierten Kanal entsprechen, auf einen Speicher-Raum ab, welcher von der Gast-VM 204 zugreifbar ist. Das GPU-Emulations-Modul 304 stellt Adressenraum-Isolation für die verschiedenen Gast-VMs 204 derart bereit, dass der abgebildete (mapped) Speicher-Bereich für jede Gast-VM 204 separat ist. Daher kann eine Gast-VM 204 nicht auf den Speicher-Bereich zugreifen, welcher für eine andere Gast-VM 204 abgebildet ist, wodurch niemals ein Konflikt auf einem Kanal herbeigeführt ist, welcher an die andere Gast-VM 204 alloziert ist. Um eine solche Isolation zu erreichen, benutzt das GPU-Emulations-Modul 304 die Virtualisierungs-Schicht 206, um VM-Adressen zu sperren (lock) und die gesperrten physikalischen Adressen auf physikalische Adressen innerhalb des System-Speichers zu übersetzen. Die übersetzten Adressen werden dann in den Adressraum abgebildet, welcher mit der GPU 112 assoziiert ist.
-
Sobald der Satz von Kontroll-Registern 316, welche dem allozierten Kanal entsprechen, abgebildet sind, wird der Proxy-Resource-Manager 312 darüber benachrichtigt, dass der Kanal an den Gast-GPU-Treiber 310 alloziert worden ist, welcher wiederum eine Benachrichtigung an den Gast-GPU-Treiber 310 übermittelt, welche anzeigt, dass der Kanal alloziert worden ist. Der Gast-GPU-Treiber 310 bildet dann den abgebildeten Speicher-Bereich in die Anwendung 308 ab.
-
Sobald der Zugriff auf die GPU 112 eingerichtet worden ist, wie oben beschrieben ist, kann der Gast-GPU-Treiber 310 auf einen Befehl der Anwendung 308 hin auf die GPU 112 direkt zugreifen, indem der Satz von Kontroll-Registern 316 manipuliert wird, welche mit dem allozierten Kanal assoziiert sind. Insbesondere bevölkert der Gast-GPU-Treiber 310 einen Bereich von Speicher (hierin auch als „Befehlspuffer” bezeichnet) mit Befehlen, welche an die GPU 112 zu übermitteln sind. Der Gast-GPU-Treiber 310 programmiert dann den Satz von Kontroll-Registern 316, welche in den Speicher-Bereich, auf welchen die Gast-VM 204 zugreifen kann, abgebildet wurden, um die Anfangs- und Endspeicher-Adressen des bevölkerten Befehlspuffers anzuzeigen. Sobald die Endspeicher-Adresse in den Satz von Kontroll-Registern programmiert ist, beginnt die GPU 112 automatisch damit, die Befehle, welche in dem Befehlspuffer umfasst sind, zur Ausführung zu holen. In diesem Stadium werden keine Fang-(trapping)- oder Emulations-Operationen durchgeführt.
-
Mit Bezug zurück auf das GPU-Emulations-Modul 304, welches, wie oben beschrieben, Teile der GPU 112 emuliert, wie etwa Konfigurations-Register, Peripheral Component Interconnect Express-(PCIe)Bus-Register, Ereignisse/Unterbrechungen (events/interrupts). Die Gast-VMs 204, insbesondere der Gast-GPU-Treiber 310, greift auf diese emulierten Ressourcen über das GPU-Emulations-Modul 304 zu und greift nicht direkt auf die GPU 112 zu. Mit Bezug auf die Ereignisse, welche von der GPU 112 hervorgebracht oder verursacht werden (raised), wie etwa Kanalfehler und Vollständigkeits-Benachrichtungen, zeigt der Gast-GPU-Treiber 310 dem GPU-Emulations-Modul 304 die Ereignisse an, für welche sich der Gast-GPU-Treiber 310 gern registrieren würde. Jedes Mal, wenn die GPU 112 ein Ereignis hervorbringt, bestimmt das GPU-Emulations-Modul 304, ob sich eine Gast-VM 204 für dieses bestimmte Ereignis registriert hat. Wenn dem so ist, leitet das GPU-Emulations-Modul 304 eine Benachrichtigung an den Gast-GPU-Treiber 310, welcher in der Gast-VM 204 umfasst ist, weiter, welche anzeigt, dass das Ereignis hervorgebracht wurde. Zusätzlich empfängt das GPU-Emulations-Modul 304 Fehlerereignisse, welche von einer GPU-Befehls-Verarbeitung herrühren, welche mit einem bestimmten Kanal assoziiert ist. Das GPU-Emulations-Modul 304 bestimmt dann die Gast-VM 204, an welche der Kanal alloziert wurde, und leitet das Fehlerereignis an diese Gast-VM 204 weiter.
-
Zusätzlich verfolgt das GPU-Emulations-Modul 304 den Status von GPU-virtuelle-Adressen nach (tracks), wenn die Adressen neu abgebildet werden oder zerstört werden. Wenn alle GPU-Bezugnahmen auf eine aufgesteckte (pinned) Gäste-Seite überschrieben worden sind oder zerstört worden sind, wird die Gast-Seite losgelöst oder von der Pin-Wand genommen (unpinned). Ferner umfasst das GPU-Emulations-Modul 304 Bereitstellungen zum Reservieren von Ressourcen innerhalb des Computer-Systems 100 für eine gegebene Gast-VM 204, derart, dass unerwartete Allokationsfehler vermieden werden. Schließlich unterstützt das GPU-Emulations-Modul 304 ein Aussetzen oder Anhalten (suspending) und ein Wiederaufnehmen einer Gast-VM 204, möglicherweise auf einem anderen physikalischen System oder auf einer anderen GPU, dadurch, dass der Zustand von GPU von GPU-virtuelle-Adresse-Abbildungen und GPU-Kanälen an System-Speicher 104 oder externen Speicher, wie etwa Systemplatte 114, gesichert wird oder gespeichert wird, wenn angehalten oder ausgesetzt wird und beim Wiederherstellen des Status, wenn wieder aufgenommen wird. Nach einem Aussetzen (suspending) der virtuellen Maschine setzt das GPU-Emulations-Modul 304 GPU-Ressourcen frei, wie etwa allozierte Kanäle und entsteckt (unpins) irgendwelche gesteckten virtuelle-Maschine-Seiten (pinned virtual machine pages). Beim Wiederaufnehmen (resuming) steckt das GPU-Emulations-Modul 304 und übersetzt alle abgebildeten virtuelle-Maschine-Adressen und erzeugt erneut die GPU-virtuelle-Abbildungen.
-
Wenn Grafikbilder (graphics frames) zur Anzeige erzeugt werden, erzeugt die Gast-VM 204 Grafikbilder mit der Annahme, dass das gesamte Anzeigegerät 110 für die Gast-VM 204 alloziert ist. Daher werden Anzeige-Befehle, welche mittels eines Anzeige-Treibers (nicht gezeigt), welcher in der Gast-VM 204 umfasst ist, übermittelt werden, mittels des Anzeige-Emulations-Moduls 304 gefangen (trapped). Die gefangenen Anzeige-Befehle werden unter Benutzung der GPU 112 übersetzt, um ein Zusammenstellen, Skalieren und andere Verarbeitung von Anzeigebildern gemäß der aktuellen Allokation des Anzeigegeräts 110 an die Gast-VM 204 zu simulieren.
-
Zusätzlich partitioniert auch der Master-Resource-Manager 306 Ressourcen, wie etwa Speicher über mehrere Gast-VMs 204 hinweg. Die Ressourcen werden entweder statisch oder dynamisch partitioniert, zugeteilt und geschützt für eine einzelne Gast-VM 204 und es wird dann direkter Zugriff (über eine Speicher-Adresse) zurück an die Gast-VM 204 zur Benutzung gegeben. Solch eine Ressource, gleich wie Kanäle, ist dann für direkten geschützten Zugriff mittels des Gast-GPU-Treibers 310 verfügbar.
-
4 ist eine konzeptionelle Illustration der Interaktionen zwischen der privilegierten VM 202 und der Gast-VM 204 der 2 und der GPU von 1, gemäß einer Ausführungsform der Erfindung.
-
Um auf emulierte Ressourcen, wie etwa GPU-Konfigurations-Register, zuzugreifen, übermittelt der Gast-GPU-Treiber 310 bei Interaktion 402 eine Anfrage an das GPU-Emulations-Modul 304. Das GPU-Emulations-Modul 304 kommuniziert mit der GPU 112 entweder auf Empfangen der Anfrage hin oder bereits vorher, um die relevanten Daten, welche mit den emulierten Ressourcen assoziiert sind, abzurufen. In Antwort auf die Anfrage übermittelt das GPU-Emulations-Modul 304 die relevanten Daten an den Gast-GPU-Treiber 310.
-
Um Zugriff auf die GPU zum Ausführen von Befehlen einzurichten, übermittelt der Gast-GPU-Treiber 310 bei Interaktion 404 eine Zugriffsanfrage an den Proxy-Resource-Manager 312. Der Proxy-Resource-Manager 312 leitet bei Interaktion 406 die Anfrage an den Master-Resource-Manager 306 weiter. Der Master-Resource-Manager 306 alloziert bei Operation 408 zumindest einen GPU-Kanal, welcher mit der GPU 112 assoziiert ist, für den Gast-GPU-Treiber 310. Die Allozierung kann dynamisch gemacht werden oder kann statisch vorbestimmt sein. Der Master-Resource-Manager 306 benachrichtigt das GPU-Emulations-Modul 304 von der Kanal-Alloziierung. Das GPU-Emulations-Modul 304 bildet dann bei Operation 410 den Satz von Kanal-Kontroll-Registern, welche mit den allozierten Kanälen assoziiert sind, auf Speicherbereich ab, welcher mittels der Gast-VM 204 zugreifbar ist, welche den Gast-GPU-Treiber 310 umfasst. Der Gast-GPU-Treiber 310 greift dann direkt auf die GPU 112 über den Satz von Kanal-Kontroll-Registern bei Operation 412 in der oben beschriebenen Weise zu.
-
Um sich für Ereignisse zu registrieren, welche von der GPU 112 hervorgebracht werden (raised), wird die Anfrage für eine Ereignis-Registrierung, welche mittels des Gast-GPU-Treibers 310 übermittelt ist, an das GPU-Emulations-Modul 304 geführt (routed). Das GPU-Emulations-Modul 304 verfolgt irgendwelche Ereignisse (keeps track), für welche sich der Gast-GPU-Treiber 310 registriert hat. Wenn das GPU-Emulations-Modul 304 eine Ereignis-Benachrichtung von der GPU 112 empfängt, für welche sich der Gast-GPU-Treiber 310 registriert hat, leitet das GPU-Emulations-Modul 304 die Ereignis-Benachrichtung an den Gast-GPU-Treiber 310 weiter.
-
5 ist ein Flussdiagramm von Verfahrensschritten zum Ermöglichen der Gast-VM, auf die GPU in einer paravirtualisierten Weise zuzugreifen, gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Zusammenhang mit 1 bis 3 beschrieben werden, werden die Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte, in irgendeiner Ordnung, durchzuführen, innerhalb des Geltungsbereichs der vorliegenden Erfindung fällt.
-
Das Verfahren 500 beginnt bei Schritt 502, wo der Proxy-Resource-Manager 312 eine Anfrage von dem Gast-GPU-Treiber 310 zum Zugriff auf ein emuliertes Register, welches mit der GPU 112 assoziiert ist, empfängt. Bei Schritt 504 übermittelt der Proxy-Resource-Manager 308 die Anfrage an das GPU-Emulations-Modul 304 über den Master-Resource-Manager 306. Bei Schritt 506 übermittelt das GPU-Emulations-Modul 304 Daten, welche mit den emulierten Register assoziiert sind, an den Gast-GPU-Treiber 310 über den Master-Resource-Manager 306 und den Proxy-Resource-Manager 312.
-
Bei Schritt 508 empfängt der Proxy-Resource-Manager 312 eine Anfrage von dem Gast-GPU-Treiber 310 zum Einrichten eines Zugriffs auf die GPU 112 zum Ausführen von Befehlen. Bei Schritt 510 leitet der Proxy-Resource-Manager 312 die Anfrage an den Master-Resource-Manager 306 über einen entfernter-Prozedur-Aufruf (remote procedure call) weiter. Der Master-Resource-Manager 306 alloziert bei Schritt 512 zumindest einen GPU-Kanal, welcher mit der GPU 112 assoziiert ist, für den Gast-GPU-Treiber 310. Der Master-Resource-Manager 306 benachrichtigt dann das GPU-Emulations-Modul 304 über die Kanal-Allozierung. Bei Schritt 514 bildet das GPU-Emulations-Modul 304 den Satz von Kanal-Kontroll-Registern, welche mit den allozierten Kanälen assoziiert sind, in einen Speicherraum ab, welcher von der Gast-VM 204 zugreifbar ist, welche den Gast-GPU-Treiber 310 umfasst. Bei Schritt 516 zeigt der Proxy-Resource-Manager 312 dem Gast-GPU-Treiber 310 an, dass auf die GPU 112 direkt, ohne die Intervenierung irgendwelcher anderen Komponenten innerhalb des Systems 100, über den Satz von Kanal-Kontroll-Registern bei Operation 412 in der oben beschriebenen Weise zugegriffen werden kann.
-
In solch einer Weise ist ein Gast-GPU-Treiber 310, welcher in einer Gast-virtuellen-Maschine ausführt, in der Lage, direkt zumindest einen Teil der Verarbeitungs-Fähigkeiten der GPU 112 zu nutzen (harness). Mit solch einem direkten Zugriff wird die Performanz eines Systems erhöht, wo mehrere Gast-VMs für einen Zugriff auf die GPU 112 wetteifern, da die Virtualisierungs-Schicht 206 eine minimale Intervention beim Einrichten von Zugriff für die Gast-VMs durchführt. Weil der Gast-GPU-Treiber 310 Befehle direkt an die GPU 112 übermitteln kann, ist zusätzlich der Umfang von Befehls-Übersetzung und die Kompatibilitäts-Probleme, welche auftreten, wenn verschiedene Typen von GPU-Treibern in einer virtualisierten Umgebung unterstützt sind, drastisch reduziert.
-
Die verschiedenen Ausführungsformen, welche hierin beschrieben sind, können verschiedene Computer-implementierte Operationen einsetzen, was involviert, dass Daten in Computer-Systemen gespeichert werden. Zum Beispiel können diese Operationen physikalische Manipulation von physikalischen Quantitäten erfordern – gewöhnlich, obwohl nicht notwendiger Weise, können diese Quantitäten die Form von elektrischen oder magnetischen Signalen annehmen, wo sie oder Repräsentationen von ihnen in der Lage sind, gespeichert, transferiert, kombiniert, verglichen oder auf andere Weise manipulier zu werden. Ferner wird auf solche Manipulationen oft in Begriffen, wie etwa Erzeugen, Identifizieren, Bestimmen oder Vergleichen Bezug genommen. Irgendwelche Operationen, welche hierin beschrieben sind, welche einen Teil von einer oder mehreren Ausführungsformen der Erfindung bilden, können nützliche Maschinen-Operationen sein. Zusätzlich beziehen sich eine oder mehrere Ausführungsformen der Erfindung auf ein Gerät oder einen Apparat zum Durchführen dieser Operationen. Der Apparat kann speziell für spezifische erforderliche Zwecke konstruiert sein oder er kann ein Allgemeinzweck-Computer sein, welcher selektiv mittels eines Computer-Programms aktiviert oder konfiguriert ist, welches in dem Computer gespeichert ist. Insbesondere können verschiedene Allgemeinzweck-Maschinen mit Computer-Programmen benutzt werden, welche in Übereinstimmung mit den Lehren hierin geschrieben sind, oder es kann bequemer sein, einen spezialisierteren Apparat zu konstruieren, um die erforderlichen Operationen durchzuführen.
-
Die hierin beschriebenen verschiedenen Ausführungsformen können mit anderen Computer-System-Konfigurationen praktiziert werden einschließlich handgehaltenen Geräten, Mikroprozessor-Systemen, Mikroprozessor-basierten oder programmierbaren Verbraucher-Elektronik-Geräten, Minicomputern, Mainframe-Computer und dergleichen.
-
Eine oder mehrere Ausführungsformen der vorliegenden Erfindung können als ein oder mehrere Computer-Programme oder als ein oder mehrere Computer-Programm-Module implementiert sein, welche in einem oder mehreren Computer-lesbaren Medien verkörpert sind. Der Ausdruck Computer lesbares Medium bezieht sich auf irgendein Datenspeicher-Gerät, welches Daten speichern kann, welche danach in ein Computer-System eingegeben werden können – Computer lesbare Medien können auf irgendeiner existierenden oder nachfolgend entwickelten Technologie zum Verkörpern von Computer-Programmen in einer Weise basieren, welche ihnen erlaubt, mittels eines Computers gelesen zu werden. Beispiele von Computer lesbaren Medium umfassen eine Festplatte, ein Netzwerk angebrachter Speicher (network attached storage) (NAS), Nur-Lesespeicher, Speicher mit willkürlichem Zugriff (Random-Access-Memory) (z. B. ein Flash-Speichergerät), eine CD (Compact Disks) – CD-ROM, eine CD-R, oder eine CD-RW, eine DVD (Digital Versatile Disk), ein magnetisches Band, oder andere optische oder nicht-optische Datenspeicher-Geräte. Das Computer-lesbare Medium kann auch über ein Netzwerk gekoppeltes Computer-System verteilt sein, so dass der Computer-lesbare Code in einer verteilten Weise gespeichert und ausgeführt ist.
-
Obwohl eine oder mehrere Ausführungsformen der vorliegenden Erfindung in einem Detail zur Klarheit des Verständnis beschrieben worden sind, wird es ersichtlich sein, dass gewisse Änderungen und Modifikationen innerhalb des Geltungsbereiches der Ansprüche vorgenommen werden können. Demgemäß sind die beschriebenen Ausführungsformen als illustrativ und nicht als beschränkend anzusehen und der Geltungsbereich der Ansprüche ist nicht auf hierin gegebene Details begrenzt, sondern kann innerhalb des Geltungsbereichs und von Äquivalenten der Ansprüche modifiziert werden. In den Ansprüchen implizieren Elemente und/oder Schritte nicht eine bestimmte Ordnung der Operation, es sei denn, es ist ausdrücklich in den Ansprüchen ausgeführt.
-
Visualisierungs-Systeme in Übereinstimmung mit den verschiedenen Ausführungsformen können als gehostete (hosted) Ausführungsformen, nicht-gehostete Ausführungsformen oder Ausführungsformen implementiert werden, welche dazu neigen, Unterscheidungen zwischen den beiden zu verwischen, alle von diesen werden betrachtet. Ferner können verschiedene Virtualisierungs-Operationen vollständig oder teilweise in Hardware implementiert sein. Zum Beispiel kann eine Hardware-Implementierung eine Look-up-Tabelle zur Modifikation von Speicher-Zugriffs-Anfragen auf sichere Nicht-Platte-Daten (secure non-disk data) einsetzen.
-
Viele Variationen, Modifikationen, Hinzufügungen und Verbesserungen sind unabhängig von dem Grat einer Virtualisierung möglich. Die Virtualisierungs-Software kann daher Komponenten eines Host-, Konsole- oder Gast-Betriebs-Systems umfassen, welche Virtualisierungs-Funktionen durchführen. Mehrere Instanzen können für Komponenten, Operationen und Strukturen, welche hierin beschrieben sind, als eine einzelne Instanz bereitgestellt sein. Schließlich sind Grenzen zwischen verschiedenen Komponenten, Operationen und Daten-Speichern in gewisser Weise willkürlich und bestimmte Operationen sind im Zusammenhang von spezifischen illustrativen Konfigurationen illustriert. Andere Allozierungen von Funktionalität werden auch betrachtet und können innerhalb des Geltungsbereichs der Erfindung(en) fallen. Im Allgemeinen können Strukturen und Funktionalität, welche als separate Komponenten präsentiert sind, in exemplarischen Konfigurationen als eine kombinierte Struktur oder Komponente implementiert sein. Ähnlich können Strukturen und Funktionalität, welche als eine einzelne Komponente präsentiert ist, als separate Komponenten implementiert sein. Diese und andere Variationen, Modifikationen, Hinzufügungen und Verbesserungen können innerhalb des Geltungsbereichs der angehängten Ansprüche fallen.
