x86-Virtualisierung

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Intel VT)
Wechseln zu: Navigation, Suche

x86-Virtualisierung bezeichnet hardware- und softwarebasierte Mechanismen zur Unterstützung der Virtualisierung für Prozessoren, die auf der x86-Architektur basieren. Sie erlaubt es unter Verwendung eines Hypervisors mehrere Betriebssysteme parallel auf einem x86-Prozessor auszuführen und die Ressourcen sicher und effizient zwischen den parallel ausgeführten Betriebssystemen aufzuteilen. Die (Gast-)Betriebssysteme sollten bei der vollständigen Virtualisierung keinen Unterschied zwischen virtualisiertem (Parallel-)Betrieb und (exklusivem) Betrieb direkt auf der Hardware erkennen können.

Entwicklung der x86-Virtualisierung[Bearbeiten]

Seit Ende der 1990er Jahre wurde Virtualisierung für x86-Prozessoren durch komplexe Softwareimplementierung erreicht, die notwendig waren, da es den damaligen Prozessormodellen an hardwareseitiger Unterstützung für die Virtualisierung fehlte. Erst 2006 kündigten sowohl Intel (VT-x) als auch AMD (AMD-V) die Einführung von hardwareseitiger Unterstützung für die Virtualisierung an. Allerdings boten die ersten Versionen der Implementierung nur sehr geringe Geschwindigkeitsvorteile gegenüber den rein softwareseitig implementierten Virtualisierungslösungen.[1] Bessere hardwareseitige Virtualisierungsunterstützung wurde erst später mit der Entwicklung neuerer Prozessormodelle erreicht.

Softwarebasierte Virtualisierung[Bearbeiten]

Um Ressourcen exklusiv den parallel laufenden Gastsystemen zuteilen zu können, darf nur dem Hostbetriebssystem bzw. dem Hypervisor direkter Zugriff auf die Prozessor-Hardware gewährt werden, während die Gastsysteme wie alle anderen Applikationen nur eingeschränkte Zugriffsrechte auf die Hardware haben dürfen. So kann insbesondere verhindert werden, dass die Gastsysteme Speicherbereiche, die der Hypervisor zur Verwaltung benötigt, sehen bzw. ändern können.

Mit dem 80286-Prozessor wurde in der x86-Welt der sogenannte Protected Mode, eingeführt. Mit ihm wurden vier verschiedene als Ringe bezeichneten Schutzebenen bzw. Befugnisstufen (engl. „privilege level“) eingeführt, die den darauf ablaufenden Codesegmenten unterschiedliche Rechte gewähren. Erst mit der Einführung dieses Konzept war es möglich, Virtualisierung auf Basis der x86-Architktur zu implementieren: Im Protected Mode läuft der Betriebssystem-Kernel in einem höher privilegierten Modus, der als Ring 0 bezeichnet wird und Applikationen in einem weniger privilegierten Modus, in der Regel entweder Ring 1 oder Ring 3.

Der Hypervisor bzw. das Hostbetriebsystem werden aufgrund ihrer privilegierten Stellung bei der Ressourcenverwaltung mit Ring-0-Berechtigung ausgeführt. Gastsysteme müssen, um den Schutz der Hypervisor-Ressourcen zu gewährleisten, folglich entweder auf Berechtigungslevel Ring 1 (im sogenannten 0/1/3 Modell) oder Ring 3 (im sogenannten 0/3/3 Modell) ausgeführt werden.[2]

Deprivilegierung[Bearbeiten]

Da Betriebssysteme für die x86-Architektur (die als Gastsystem keinen Unterschied zwischen virtualisiertem Betrieb und Betrieb direkt auf der Hardware sehen dürfen) so implementiert sind, dass sie von der Ring-0-Berechtigung ausgehen und auch nur dann korrekt funktionieren, muss die Virtualisierungslösung die zwei Ring Deprivilegierung und Ring Aliasing genannten Features implementieren:

  • Die Ring Deprivilegierung sorgt dafür, dass das Gastsystem alle Befehle so ausführen kann, als hätte es Ring-0-Berechtigungen auf der Hardware, obwohl es durch die Virtualisierung weniger privilegierte Berechtigungen hat.
  • Das Ring Aliasing sorgt dafür, dass das Gastsystem, wenn es eine Aktion ausführt, immer die Antwort erhält, die es erhalten würde, wenn der Befehl mit Ring-0-Berechtigungen ausgeführt worden wäre. Beispielsweise existiert ein Befehl zur Abfrage des Privilegierungslevels, der mit allen Berechtigungsleveln aufgerufen werden darf. Würde ein Gastsystem diesen Befehl ohne Ring Aliasing aufrufen, würde es Ring 1 oder 3 als Antwort erhalten, mit Ring Aliasing erhält es Ring 0.[2]

Primär- und Shadowstrukturen[Bearbeiten]

Der Hypervisor benötigt außerdem eigene Speicherbereiche, in denen Verwaltungsdaten z.B. zu den Zuständen der verschiedenen VMs gespeichert werden. Dabei muss sichergestellt werden, dass die entsprechenden Speicherbereich für die VMs zwar sichtbar und ggf. auch änderbar sind, jedoch dürfen die dort abgelegten Verwaltungsdaten des Hypervisors nicht sichtbar sein oder gar verändert werden. Der Speicher muss vielmehr so erscheinen, als würde er exklusiv durch die jeweilige VM benutzt. Um das zu gewährleisten, werden die entsprechenden Speicherbereiche mehrfach vorgehalten: In der Primärstruktur werden die Hypervisor-Daten in den für jede VM vorhandenen Sekundär- oder auch Shadowstrukturen genannten Bereichen die der VMs gespeichert. Für Prozessorregister werden die Zugriffe durch den Hypervisor normalerweise abgefangen (trapped) und der Zustand des Prozessor über die Shadowstruktur emuliert. Bei jedem Speicherzugriff der VMs muss der Hypervisor kontrollieren, ob es sich um einen solchen besonders geschützten Speicherbereich handelt und ggf. die Daten aus der Shadowstruktur der jeweilige VM statt aus der Primärstruktur zur Verfügung stellen, jedoch ohne dass die VM aus ihrer Sicht dies feststellen kann. Diese Technik wird auch als Tracing bezeichnet.[3]

Sofwarebasierte Vollvirtualisierung für die x86-Architektur[Bearbeiten]

Normalerweise wird, um diese Funktionen zu implementieren, ein nach der Trap-and-Emulate-Methode funktionierendes Verfahren[4] bereits hardwareseitig im Prozessor bereitgestellt. Es stand in der x86-Architektur bis 2006 (danach siehe hier) aber keine Hardwareunterstützung für die Virtualisierung zur Verfügung, so dass o.g. Funktionen softwareseitig implementiert werden mussten. Allerdings lässt sich das Trap-and-Emulate-Verfahren nicht softwareseitig ohne Hardwaresupport im Prozessor umsetzen,[3] sodass man für die softwarebasierte Virtualisierung einen anderen Weg gehen musste:

  • Die sogenannte Binärcode-Übersetzung wird eingesetzt, um Anweisungen des Gastsystems auf Prozessorinstruktionslevel von Ring 3 / Ring 1 – Anweisungen in entsprechende Ring 0 – Anweisungen des Host-System zu übersetzten – und zwar in geeigneter Art und Weise um Ring Deprivilegierung und Ring Aliasing umzusetzen.[3]:3[5]
  • Ein Reihe von wichtigen Datenstrukturen die durch den Prozessor benutzt werden, müssen geshadowed werden. Da die meisten Gastbetriebssysteme paged virtual memory benutzen und direkter Zugriff auf die Speicherbereiche ggf. zum Überschreiben von Daten des Hypervisors bzw. anderer VMs führen würde, muss einiges, was normalerweise durch die Memory Management Unit des Prozessors geleistet wird, softwareseitig im Hypervisor nochmals implementiert werden, um dies zu verhindern.[6]:5[3] Insbesondere ist es eben erforderlich, den direkten Zugriff der Gastsysteme auf die primären Seitentabellen zu verhindern, indem alle Zugriffe darauf abgefangen und softwareseitig emuliert werden. Die x86-Architektur setzt außerdem hidden states (das sind Prozessorzustandsdaten, die nicht in Prozessorregistern, sondern außerhalb des Prozessors im Speicher abgelegt sind) ein, um Segment-Deskriptoren des Prozessors zwischenzuspeichern und ggf. wiederherzustellen. Sobald die Speicherbereiche in den Prozessor geladen wurden, um die Segmentdeskriptoren wiederherzustellen, wird der für den hidden state ursprünglich verwendete Speicherbereich freigegeben und kann sofort, z.B. durch Anwendungsprozesse, überschrieben werden. Deswegen müssen auch Shadow Descriptor Tables implementiert werden, um Änderungen an diesen Speicherbereichen durch die VMs nachvollziehen zu können.[7]
  • I/O-Geräte der Gastsysteme, die im Hostbetriebssystem nicht unterstützt werden, müssen durch entsprechende Softwaremulatoren auf dem Hostbetriebssystem emuliert werden.[8]

Um diese komplexen Aufgaben softwareseitig zu implementieren, wurden die ersten Virtualisierungsprodukte als Typ-2-Hypervisoren zum Einsatz auf Workstation Computern konzipiert. Der Hypervisor wurde auf dem Hostbetriebssystem in einem Kernelmodul ausgeführt. Dadurch mussten zumindest keine Treiber für die Hosthardware entwickelt werden, da ohnehin schon sehr viel Implementierungsaufwand zur Implementierung der oben beschriebenen Verfahren notwendig war.[8]

Diese Art der Implementierung des Hypervisors führten zu geringerer relativen Performance der VMs (im Relation zur Performance des Hostprozessors), insbesondere aufgrund der softwareseitig reimplementierten Teile der MMU im Vergleich zur Performance von VMs auf CPU-Architekturen, die bereits hardwareseitig eine Virtualisierung der MMU vorsehen wie z.B. die IBM-System/370-Architektur[3]:10[9]:17 and 21

Es gab außerdem eine kontroverse wissenschaftliche Diskussion darüber, ob die x86-Architektur ohne hardwaregestützte Virtualsisierungsfeatures wie hier beschrieben überhaupt die Voraussetzungen zur Virtualisierung gemäß den von Popek and Goldberg aufgestellten Kriterien erfüllt. VMware-Forscher zeigten 2006 in einem ASPLOS-Aufsatz, dass die oben dargestellten Techniken die x86-Plattform virtualisierbar im Sinne der drei von Popek und Goldberg aufgestellten Kriterien macht, jedoch nicht mit Hilfe der ebenfalls von Popek und Goldberg beschriebenen klassischen „trap-and-emulate“-Technik.[3]:2–3

Sofwarebasierte Paravirtualisierung für die x86-Architektur[Bearbeiten]

Ein andere Ansatz zur Implementierung der Virtualisierung wurde von Hypervisoren wie Denali, L4 und Xen verfolgt. Um die Implementierung zu vereinfachen, wurde eine der grundsätzliche Forderung nicht umgesetzt, nämlich das Gastbetriebssystem solle unverändert sowohl auf einem virtualisierten wie nicht virtualisierten System lauffähig sein. Es wurden spezielle Versionen der Gastbetriebssysteme entwickelt, die für den Betrieb mit dem jeweiligen Hypervisor abgestimmt waren. Diese Hypervisoren virtualisierten dabei besonders schwierig und zu implementierende und performancehemmende Aspekte der x86-Architektur nicht, z.B. die I/O-Virtualisierung. Dieser als Paravirtualisierung bezeichnete Ansatz kann signifikante Performancegewinne bringen, wie im SOSP-Xen-Aufsatz von 2003 nachgewiesen wird.[10] Die Paravirtualisierung spielt heute vor allem im Embedded Umfeld noch eine wichtige Rolle.

Sofwarebasierte Vollvirtualisierung für die x86-64-Architektur[Bearbeiten]

Die erste Version von x86-64 von AMD (AMD64) erlaubte keine ausschließlich softwarebasierte Virtualisierung mehr, da es keinen Support für Segmentierung im Long Mode (also für die 64-bit-Adressierung) mehr bot und damit den Schutz des Speichers des rein softwarebasierten Hypervisors nicht erlaubte.[11][12]:11 and 20. Die Revisionen D und alle folgenden 64-bit-AMD-Prozessoren (grob gesagt alle in 90-nm-Technologie und darunter entworfenen Chips) wurde mit grundlegendem Support for Segmentation im Long Mode ausgestattet, womit 64-bit-Gastsysteme auf 64-bit-Hostsystemenen über Binärcode-Übersetzung virtualisiert werden konnten.

Intel bot ebenfalls keinen Support für Segmentierung im Long Mode für seine x86-64-Prozessoren an, wodurch wie auch bei AMDs ersten Chips keine softwarebasierte 64-bit-Virtualisierung möglich war. Im Unterschied zu AMD bot Intel allerdings mit VT-x zu diesem Zeitpunkt bereits hardwareunterstütze Virtualisierung für seine 64-bit-Prozessoren an.[13][14]:4

Hardwareunterstützte Virtualisierung[Bearbeiten]

2005 bzw. 2006 brachten Intel und AMD (unabhängig voneinander) Prozessormodelle mit Befehlssatzerweiterungen zur Virtualisierungsunterstützung auf den Markt. Die erste Generation dieser Prozessoren adressierte vor allem das Problem der Deprivilegierung. Verbesserungen bezüglich der virtualisierten Systemspeicherverwaltung für VMs wurden in späteren Prozessormodellen hinzugefügt.

Prozessoren (CPU)[Bearbeiten]

Virtual 8086 Mode[Bearbeiten]

Aufgrund der großen Schwierigkeiten mit dem Protected Mode des 80286, der selbst nur bedingt tauglich war, um parallel mehrere MS-DOS-Applikationen zu betreiben, führte Intel mit dem 80386er Prozessor den Virtual 8086 Mode ein, der eine virtualisierte 8086-Umgebung ermöglichte. Hardwareunterstützung für die Virtualisierung des Protected Mode wurde durch Intel erst gut 20 Jahre später im Prozessorbefehlssatz implementiert.[15]

Der Virtual 8086 Mode lässt sich softwareseitig allerdings erkennen und erlaubt den Programmen Zugriff auf die Erweiterungen, die mit dem 286er späteren Prozessorgenerationen eingeführt wurden.

AMD Virtualisierung (AMD-V) [Bearbeiten]

AMD entwickelte die erste Generation von Befehlssatzerweiterungen für die Virtualisierungsunterstützung unter dem Namen „Pacifica“ und brachte sie schließlich unter dem Namen AMD Secure Virtual Machine (SVM)[16] auf den Markt. Später wurde die Technologie erneut unbenannt und wird bis heute unter dem Namen AMD Virtualization – kurz AMD-V vermarktet.

Am 23. Mai 2006 brachte AMD den Athlon 64, den Athlon 64 X2 und den Athlon 64 FX als erste Prozessoren mit AMD-V-Unterstützung auf den Markt.

AMD-V ist auch auf den Prozessorfamilien Athlon 64 und Athlon 64 X2 mit Revisionsnummern „F“ und „G“ basierend auf dem AM2 Sockel, Turion 64 X2 und Opteron Prozessoren der 2ten Generation[17] und 3ten Generation[18], sowie den Prozessoren Phenom und Phenom II verfügbar. Auch die Prozessorfamilie AMD Fusion unterstützt AMD-V. Die einzigen Sempron-Prozessoren, die AMD-V unterstützten sind, die Versionen Huron und Sargas. Nicht unterstützt wird AMD-V von allen Prozessoren mit 939 Sockel.

AMD Opteron CPUs ab der 0x10 Barcelona Line und Phenom II CPUs unterstützen eine fortgeschrittene Virtualisierungstechnologie, die von AMD „Rapid Virtualization Indexing“ genannt wird (während der Entwicklung wurde sie als „Nested Page Tables“ bezeichnet). Intel führte später eine vergleichbare Technologie, von Intel Extended Page Tables (EPT) genannt, ein. Die im Allgemeinen als „Second Level Address Translation“ (kurz SLAT) bezeichnet Technologie unterstützt die Page-Table-Virtualisierung, die vor allem das Problem der softwareseitig zu implementierenden Shadow-Struktur-Synchronisation für VMs löst.

Intel Virtualisierungstechnologie (VT-x)[Bearbeiten]

Intel Core i7 (Bloomfield) CPU

Zu Beginn noch unter dem Codename „Vanderpool“ geführt, stellt die schließlich „VT-x“ genannte Technologie Hardwareunterstützung für die Virtualisierung auf Intel-x86-Prozessorn bereit. Am 13. November 2005 führte Intel mit den Modellen 662 und 672 der „Pentium 4“-Reihe die ersten beiden Prozessoren mit VT-x Unterstützung ein. Gleichzeitig wurde eine vergleichbare Technologie für die Itanium-Prozessorfamilie unter der Bezeichnung „VT-i“ vorgestellt.

Eine der wichtigsten Neuerungen durch VT-x ist die Einführung eines weiteren ausschließlich für die Virtualisierung gedachten Berechtigungskonzepts neben dem Ring-Konzept. Es werden zwei neue Berechtigungslevels „VMX Root Operation“ und „VMX non Root Operation“ eingeführt. Der Hypervisor wird im „VMX Root Operation“ ausgeführt, während VMs im „VMX non Root Operation“ ausgeführt werden. In beiden Modi sind Ring-0 bis Ring-3 als Berechtigungen vorhanden – jedoch können Ring-0 Instruktionen, die im „VMX non Root Operation“ durch VMs ausgeführt werden, nun durch den Hypervisor im „VMX Root Operation“ gefangen werden – es handelt sich also um eine Implementierung des „trap-and-emulate“-Verfahrens.[4] Damit ist das Problem der Deprivilegierung gelöst und muss nicht mehr über Binär-Translation softwareseitig implementiert werden.[2]

Nach wie vor unterstützen jedoch nicht alle Intel-Prozessor-Modelle VT-x.[19] Ob VT-x unterstützt wird oder nicht, kann sogar für unterschiedliche Versionen (identifizierbar anhand von Intels sSpec Number) desselben Prozessormodells variieren.[20][21] Selbst im Mai 2011 unterstützt der vorwiegend für den Laptopeinsatz konzipierte P6100 VT-x nicht.[22] Eine vollständige Liste aller Intel-Prozessoren mit VT-x-Unterstützung findet man auf der Intel-eigenen Website.[23]

Bei einigen Mainboards muss Intels VT-x-Feature außerdem explizit über die BIOS-Einstellungen aktiviert werden.[24]

Mit der Nehalem Prozessorfamilie führte Intel eine von Intel selbst als Extended Page Tables (EPT)[25] bezeichnete Technologie ein.[26][27] Die im Allgemeinen als „Second Level Address Translation“ (kurz SLAT) bezeichnete Technologie unterstützt die Page-Table-Virtualisierung,[28], die vor allem das Problem der softwareseitig zu implementierenden Shadow-Struktur-Synchronisation für VMs löst.

Mit der Westmere Reihe von Prozessoren ergänzte Intel ein Feature, welches es erlaubt, logische Prozessoren direkt im „Real Mode“ zu starten. Das Feature wird von Intel „Unrestricted Guest“ genannt und setzt das vorher eingeführte EPT-Feature voraus.[29][30]

Eine als VMCS Shadowing bezeichnete Technologie erlaubt seit der Einführung mit Prozessoren der Haswell Prozessorfamilie hardwareunterstützte geschachtelte Virtualisierung.[31]: Die sogenannte Virtual Machine Control Structure (VMCS), eine Speicherstruktur, die für jede VM genau einmal vorhanden ist, wird durch den VMM verwaltet, d.h. bei jedem Wechsel des Ausführungskontexts von einer VM zu einer anderen wird die jeweilige VMCS wiederhergestellt und legt den Zustand der Virtuellen Maschine fest.[32] Sobald mehr als ein VMM oder ein VMM in einem VMM geschachtelt ausgeführt wird, entsteht ein ähnliches Problem wie bei den Seitentabellenzugriffen (die mit EPT, RVI bzw. Second Level Address Translation gelöst wurden): die VMCS Struktur muss nun mehrfach geshadowed werden (innerhalb des Gast-VMM, des VMM und nochmals auf den eigentlichen Prozessor bzw. Speicher). Um den Aufwand dafür zu reduzieren wurden, hardwareunterstützte Shadow VMCS mit der Haskell-Generation eingeführt.[33]

VIA Virtualisierung (VIA VT)[Bearbeiten]

Mit der Einführung der VIA-Nano-3000-Prozessoren[34] und späteren Prozessoren führte VIA eine als „VIA VT“ bezeichnete Hardwareunterstützung für die Virtualisierung ein, die kompatibel zu Intels VT-x-Erweiterung ist.

Interrupt Virtualisierung (AMD AVIC, Intel APICv)[Bearbeiten]

2012 kündigte AMD ihre Advanced Virtual Interrupt Controller (AVIC) genannte Befehlssatzerweiterung an, die darauf abzielt, die Verwaltung und Virtualisierung von Interrupts effizienter durch Hardwaresupport zu implementieren.[35] Es existieren jedoch noch keine AMD-Prozessoren, die diese Erweiterung auch implementieren.[36]

Ebenfalls 2012 kündigte Intel eine vergleichbare Technologie zur Interrupt-Virtualisierung an, die anfänglich keine eigene Bezeichnung bekam.[37] Später wurde sie als APIC virtualization (APICv)[38] bezeichnet und erstmals in der Ivy Bridge Prozessorfamilie von Intel-CPUs, die unter der Bezeichnung Xeon E5-26xx v2 (seit Ende 2013 verfügbar) und Xeon E5-46xx v2 (seit Anfang 2014 verfügbar) verkauft werden, implementiert.[39]

Grafikprozessoren (GPU)[Bearbeiten]

Grafikprozessoren Virtualisierungstechnologie (Intel GVT-d, GVT-g, GVT-s)[Bearbeiten]

Mit der integrierten GPU Intel Iris Pro wurde durch Intel am 1. Januar 2014 eine Technologie (bezeichnet als Intel GVT-d, GVT-g und GVT-s) zur hardwarebasierten Unterstützung der Virtualisierung für Grafikprozessoren angekündigt. Intels integrierter Grafikprozessor Iris Pro kann mit Hilfe der Erweiterung GVT-d entweder explizit einer VM zugewiesen werden oder auf timesharing Basis zwischen mehreren VMs geteilt werden, wobei der native Grafiktreiber benutzt werden kann (GVT-g) oder zwischen mehreren VMs unter Verwendung eines virtuellen Grafiktreibers geteilt werden (GVT-s).[40]

PC-Chipsatz[Bearbeiten]

Speicher- und I/O-Virtualisierung muss durch den Chipsatz unterstützt werden, da dieser auch die entsprechenden Funktionen hardwareseitig für den Prozessor zur Verfügung stellt.[41] Normalerweise muss diese Feature im BIOS eingeschaltet werden, und das BIOS muss in der Lage sein, diese Funktionen auch zu unterstützen und zu nutzen. Das bedeutet auch, das BIOS muss in einer Version vorliegen, die an die Virtualisierungsfunktionen des Chipsatzes angepasst ist.

I/O MMU Virtualisierung (AMD-Vi and VT-d)[Bearbeiten]

Eine Input/Output Memory Management Unit (IOMMU) erlaubt Gast-VMs die direkte Benutzung von Peripheriegeräten, z.B. Netzwerkkarten, Grafikkarten, Festplattenkontrollern durch das Mapping von Speicherzugriffen und Interrupts. Diese Technik wird manchmal auch als PCI Passthrough bezeichnet.[42]

Eine IOMMU erlaubt es Betriebssystemen und VMs außerdem, Peripheriegeräte durch Pufferung leichter zu benutzen, deren Speicher oder Verarbeitungsgeschwindigkeit kleiner ist als der der VM oder Betriebssysteme. Die entsprechenden Mechanismen werden durch die IOMMU implementiert und müssen damit nicht durch die Betriebssysteme bzw. VMs implementiert werden.

Sowohl AMD als auch Intel habe entsprechende Spezifikationen herausgebracht:

  • AMDs I/O Virtualisierungstechnologie, AMD-Vi, ursprünglich IOMMU genannt.[43]
  • Intels Virtualization Technology for Directed I/O (VT-d),[44] welches durch die meisten high-end (jedoch nicht alle) Nehalem und neuere Intel-Prozessoren unterstützt wird.[45]

Neben der Unterstützung durch die CPU müssen sowohl das Mainboard, der Chipsatz als auch das BIOS oder UEFI die IOMMU-Virtualisierungsfunktionen unterstützen, um diese auch wirklich nutzbar zu machen.

Netzwerk Virtualisierung (VT-c)[Bearbeiten]

Intels „Virtualization Technology for Connectivity“ (VT-c).[46] ist ein Oberbegriff für mehrere Technologien (insbesondere VDMQ und SR-IOV) zur Vereinfachung des Netzwerkmanagements und Beschleunigung des Netzwerkszugriffs für den Hypervisor bzw. die Gast-VMs.[47]

Virtual Machine Device Queues (VMDQ)[Bearbeiten]

Um den Netzwerkverkehr jeweils der richtigen virtuellen Maschine zuordnen zu können, benötigt der Hypervisor eine einem Netzwerkswitch vergleichbare Funktion zur Aufteilung des Netzwerkverkehrs auf die Gast-VMs. Um diese Funktion hardwareseitig zu unterstützen, hat Intel mit VMDQ im Intel Ethernet-Controller bereits einen Mechanismus implementiert, der diese Verteilung für den Hypervisor übernimmt und damit die Handhabung vereinfacht und beschleunigt.[47]

PCI-SIG Single Root I/O Virtualization (SR-IOV)[Bearbeiten]
SR-IOV Komponenten

PCI-SIG Single Root I/O Virtualization (SR-IOV) stellt einen Satz von (nicht für x86 spezifisch konzipierten) I/O Virtualisierungsmethoden basierend auf PCI Express (PCIe) Hardware bereit, die durch die PCI-SIG standardisiert sind:[48] Die Technologie ermöglicht die parallele Nutzung eines einzelnen Intel® Ethernet-Server-Adapter-Ports durch mehrere virtuelle Funktionen. IT-Administratoren können so bereitgestellte virtuellen Ports nutzen, um mehrere separate Verbindungen zu virtuellen Maschinen herzustellen [47]:

  • Address translation services (ATS) unterstützt native IOV über PCI Express durch Address Translation. Die Benutzung durch Software erfordert die Unterstützung einer neuen Art von Transaktion, um die Address Translation einzuschalten.
  • Single-root IOV (SR-IOV or SRIOV) unterstützt native IOV in existierenden single-root PCI Express Topologien. Die Benutzung durch Software erfordert die Unterstützung neuer Device-Eigenschaften, um virtualisierte Konfigurationen zu verwalten.
  • Multi-root IOV (MR-IOV) unterstützt native IOV in neuen Topologien (z.B. Blade Servern)

Die SR-IOV Funktionalität wird in verschiedenen Schichten implementiert, die sich folgendermaßen einteilen lassen:

  1. Virtuelle Maschine mit Netzwerkkarte basierend auf virtuellen Funktionen (VM)
  2. Interface mit der Virtuellen Maschine (VM)
  3. Management Applikation (Hypervisor)
  4. Management Virtual Machine (Hypervisor)
  5. Hardware Funktionen (Netzwerkkarte mit aktiviertem SR-IOV Support)
  6. Virtual Funktionen, aus Hardwarefunktionen abgeleitet (Netzwerkkarte mit aktiviertem SR-IOV Support)
  7. Externes Netzwerk

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. A Comparison of Software and Hardware Techniques for x86 Virtualization, Keith Adams and Ole Agesen, VMware, ASPLOS’06 October 21–25, 2006, San Jose, California, USA"Surprisingly, we find that the first-generation hardware support rarely offers performance advantages over existing software techniques. We ascribe this situation to high VMM/guest transition costs and a rigid programming model that leaves little room for software flexibility in managing either the frequency or cost of these transitions.
  2. a b c Intel Virtualization Technology: Hardware Support for Efficient Processor Virtualization. Intel.com. 10. August 2006. Abgerufen am 2. Mai 2010.
  3. a b c d e f A Comparison of Software and Hardware Techniques for x86 Virtualization (PDF) VMware. Abgerufen am 8. September 2010.
  4. a b Gerald J. Popek and Robert P. Goldberg: Formal Requirements for Virtualizable Third Generation Architectures. In: Communications of the ACM. 17, Nr. 7, 1974, S. 412–421. doi:10.1145/361011.361073.
  5. USENIX Technical Program – Abstract – Security Symposium – 2000. Usenix.org. 29. Januar 2002. Abgerufen am 2. Mai 2010.
  6. Virtualization: architectural considerations and other evaluation criteria (PDF) VMware. Abgerufen am 8. September 2010.
  7. US Patent US 6397242 B1 – Virtualization system including a virtual machine monitor for a computer with a segmented architecture
  8. a b US Patent US 6496847 B1 – System and method for virtualizing computer systems
  9. VMware and Hardware Assist Technology (PDF) Abgerufen am 8. September 2010.
  10. Xen and the Art of Virtualization (PDF) Abgerufen am 2. September 2014.
  11. How retiring segmentation in AMD64 long mode broke VMware. Pagetable.com. 9. November 2006. Abgerufen am 2. Mai 2010.
  12. VMware and CPU Virtualization Technology (PDF) VMware. Abgerufen am 8. September 2010.
  13. VMware KB: Hardware and firmware requirements for 64bit guest operating systems. Kb.vmware.com. Abgerufen am 2. Mai 2010.
  14. Software and Hardware Techniques for x86 Virtualization (PDF) Abgerufen am 2. Mai 2010.
  15. Tom Yager: Sending software to do hardware's job | Hardware – InfoWorld. Images.infoworld.com. 5. November 2004. Abgerufen am 8. Januar 2014.
  16. 33047_SecureVirtualMachineManual_3-0.book (PDF) Abgerufen am 2. Mai 2010.
  17. What are the main differences between Second-Generation AMD Opteron processors and first-generation AMD Opteron processors? publisher=Amd.com. Archiviert vom Original am 15. April 2009. Abgerufen am 4. Februar 2012.
  18. What virtualization enhancements do Third-Generation AMD Opteron processors feature?. Amd.com. Archiviert vom Original am 16. April 2009. Abgerufen am 4. Februar 2012.
  19. Jon Stokes: Microsoft, Intel goof up Windows 7's „XP Mode“. Arstechnica.com. 8. Mai 2009. Abgerufen am 2. Mai 2010.
  20. Processor Spec Finder. Processorfinder.intel.com. Abgerufen am 2. Mai 2010.
  21. Intel Processor Number Details. In: Intel. Intel. 3. Dezember 2007. Abgerufen am 3. Oktober 2008.
  22. Intel Pentium P6100 (3M cache, 2.00 GHz). Ark.intel.com. Abgerufen am 4. Februar 2012.
  23. About Intel® Virtualization Technology – abgerufen am 23. August 2014
  24. Windows Virtual PC: Configure BIOS. Microsoft. Abgerufen am 8. September 2010.
  25. Gil Neiger: Intel Virtualization Technology: Hardware Support for Efficient Processor Virtualization. In: Intel (Hrsg.): Intel Technology Journal. 10, Nr. 3, S. 167–178. doi:10.1535/itj.1003.01. Abgerufen am 6. Juli 2008.
  26. First the Tick, Now the Tock: Next Generation Intel Microarchitecture (Nehalem). (PDF) . Abgerufen am 6. Juli 2008.
  27. Technology Brief: Intel Microarchitecture Nehalem Virtualization Technology (PDF) Intel. 25. März 2009. Abgerufen am 3. November 2009.
  28. Matt Gillespie: Best Practices for Paravirtualization Enhancements from Intel Virtualization Technology: EPT and VT-d. In: Intel Software Network. Intel. 12. November 2007. Abgerufen am 6. Juli 2008.
  29. http://2013.asiabsdcon.org/papers/abc2013-P5A-paper.pdf: „Intel added unrestricted guest mode on Westmere micro-architecture and later Intel CPUs, it uses EPT to translate guest physical address access to host physical address. With this mode, VMEnter without enable paging is allowed.“
  30. http://download.intel.com/products/processor/manual/326019.pdf: "If the “unrestricted guest” VM-execution control is 1, the “enable EPT” VM-execution control must also be 1"
  31. 4th Gen Intel Core vPro Processors with Intel VMCS Shadowing. (PDF) . Abgerufen am 17. August 2013.
  32. Understanding Intel® Virtualization Technology (VT). Abgerufen am 1. September 2014
  33. The 'what, where and why' of VMCS shadowing. Abgerufen am 1. September 2014
  34. VIA Introduces New VIA Nano 3000 Series Processors
  35. Wei Huang, Introduction of AMD Advanced Virtual Interrupt Controller, XenSummit 2012
  36. Jörg Rödel: Next-generation Interrupt Virtualization for KVM. AMD. August 2012. Abgerufen am 12. Juli 2014.
  37. Jun Nakajima: Reviewing Unused and New Features for Interrupt/APIC Virtualization. Intel. 13. Dezember 2012. Abgerufen am 12. Juli 2014.
  38. Khang Nguyen: APIC Virtualization Performance Testing and Iozone. 17. Dezember 2013. Abgerufen am 12. Juli 2014.
  39. Product Brief Intel Xeon Processor E5-4600 v2 Product Family. Intel. 14. März 2014. Abgerufen am 12. Juli 2014.
  40. Sunil Jain: Intel Graphics Virtualization Update. Intel. May 2014. Abgerufen am 11. Mai 2014.
  41. Intel platform hardware support for I/O virtualization. Intel.com. 10. August 2006. Abgerufen am 4. Februar 2012.
  42. Linux virtualization and PCI passthrough. IBM. Abgerufen am 10. November 2010.
  43. AMD I/O Virtualization Technology (IOMMU) Specification Revision 1.26. Abgerufen am 24. Mai 2011.
  44. Intel Virtualization Technology for Directed I/O (VT-d) Architecture Specification (PDF) Abgerufen am 4. Februar 2012.
  45. Intel Virtualization Technology for Directed I/O (VT-d) Supported CPU List. Ark.intel.com. Abgerufen am 4. Februar 2012.
  46. Intel Virtualization Technology for Connectivity (VT-c). Intel.com. Abgerufen am 27. Mai 2014.
  47. a b c Intel® Connectivity-Virtualisierungstechnik. Abgerufen am 1. September 2014
  48. PCI-SIG I/O Virtualization (IOV) Specifications. Pcisig.com. 31. März 2011. Abgerufen am 4. Februar 2012.