x86-Virtualisierung

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 isoliert 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.

Seit Ende der 1990er Jahre wurde Virtualisierung für x86-Prozessoren durch komplexe Softwareimplementierungen erreicht, die notwendig waren, da es den damaligen Prozessormodellen an hardwareseitiger Unterstützung für die Virtualisierung fehlte. Erst 2006 kündigten AMD (AMD-V), gefolgt von Intel (VT-x) 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.

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 sehen bzw. ändern können, die der Hypervisor zur Verwaltung benötigt.

Mit dem 80286-Prozessor wurde in der x86-Welt der sogenannte Protected Mode eingeführt. Mit ihm wurden vier verschiedene als Ringe bezeichnete Schutzebenen bzw. Befugnisstufen (englisch privilege levels) eingeführt, die den darauf ablaufenden Codesegmenten unterschiedliche Rechte gewähren. Erst mit der Einführung dieses Konzeptes war es möglich, Virtualisierung auf Basis der x86-Architektur 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 Hostbetriebssystem 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]

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 zwei Features implementieren, nämlich Ring-Deprivilegierung und Ring Aliasing:

• 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]

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 zur VM gehörigen Speicherbereiche für diese zwar sichtbar und ggf. auch änderbar sind, jedoch dürfen die 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 der VMs gespeichert. Für Prozessorregister werden die Zugriffe durch den Hypervisor normalerweise abgefangen (trapped) und der Zustand des Prozessors ü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 jeweiligen 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]

Um diese Funktionen zu implementieren, wird normalerweise 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-Systems zu übersetzen – und zwar in geeigneter Art und Weise, um Ring-Deprivilegierung und Ring Aliasing umzusetzen.^[3]:3[5]
• Eine 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 ein (das sind Prozessorzustandsdaten, die nicht in Prozessorregistern, sondern außerhalb des Prozessors im Speicher abgelegt sind), 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 Softwareemulatoren 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 Aufwand zur Implementierung der oben beschriebenen Verfahren notwendig war.^[8]

Diese Art der Implementierung des Hypervisors führte zu geringerer relativer 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 Virtualisierungsfeatures 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

Ein anderer Ansatz zur Implementierung der Virtualisierung wurde von Hypervisoren wie Denali, L4 und Xen verfolgt. Um die Implementierung zu vereinfachen, wurde eine grundsätzliche Forderung nicht umgesetzt, nämlich die, dass das Gastbetriebssystem unverändert sowohl auf einem virtualisierten wie auf einem nicht virtualisierten System lauffähig sein solle. Es wurden spezielle Versionen der Gastbetriebssysteme entwickelt, die für den Betrieb mit dem jeweiligen Hypervisor abgestimmt waren. Diese Hypervisoren virtualisierten dabei besonders schwierig 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.

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 für 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ützte Virtualisierung für seine 64-Bit-Prozessoren an.^[13][14]:4

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. Dazu gehört im Besonderen die hardwareseitige Erweiterung bestimmter Speicher-Register, um es virtuellen Maschinen zu ermöglichen, direkt ohne den Umweg über den Virtual Machine Manager (VMM) auf diese Ressourcen zuzugreifen. In den folgenden Jahren wurde diese Technik dann unter verschiedenen Bezeichnungen hauptsächlich auf Server-Chipsätze und Server-Netzwerkkarten adaptiert.

Aufgrund der großen Schwierigkeiten mit dem Protected Mode des 80286, der selbst nur bedingt tauglich war, 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 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 umbenannt 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 2.^[17] und 3. 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 ein, Extended Page Tables (EPT) genannt. Die im Allgemeinen als „Second Level Address Translation“ (kurz SLAT) bezeichnete Technologie unterstützt die Page-Table-Virtualisierung, die vor allem das Problem der softwareseitig zu implementierenden Shadow-Struktur-Synchronisation für VMs löst.

Notebook-Prozessoren der AMD A4-Serie, wie der A-9120, beinhalten AMD-Virtualisierung.^[19]

Zu Beginn noch unter dem Codenamen „Vanderpool“ geführt, stellt die schließlich „VT-x“ genannte Technologie Hardwareunterstützung für die Virtualisierung auf Intel-x86-Prozessoren 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, VMs dagegen im „VMX non Root Operation“. 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-Prozessoren VT-x.^[20] Ob VT-x unterstützt wird oder nicht, kann sogar für unterschiedliche Versionen (identifizierbar anhand von Intels sSpec Number) desselben Prozessormodells variieren.^[21][22] Selbst im Mai 2011 unterstützt der vorwiegend für den Laptopeinsatz konzipierte P6100 VT-x nicht.^[23] Eine vollständige Liste aller Intel-Prozessoren mit VT-x-Unterstützung findet man auf der Intel-eigenen Website.^[24]

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

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

Mit der Westmere-Prozessorreihe 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.^[30][31]

Eine als VMCS Shadowing bezeichnete Technologie erlaubt seit der Einführung mit Prozessoren der Haswell-Prozessorfamilie hardwareunterstützte geschachtelte Virtualisierung:^[32] Die sogenannte Virtual Machine Control Structure (VMCS), eine Speicherstruktur, die für jede VM genau einmal vorhanden ist, wird durch den VMM verwaltet, das heißt 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.^[33] 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 mit der Haswell-Generation hardwareunterstützte Shadow VMCS eingeführt.^[34]

Mit den VIA-Nano-3000-Prozessoren^[35] 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.

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.^[36] Es existieren jedoch noch keine AMD-Prozessoren, die diese Erweiterung auch implementieren.^[37]

Ebenfalls 2012 kündigte Intel eine vergleichbare Technologie zur Interrupt-Virtualisierung an, die anfänglich keine eigene Bezeichnung bekam.^[38] Später wurde sie als APIC virtualization (APICv)^[39] bezeichnet und erstmals in der Ivy-Bridge-Prozessorfamilie implementiert, 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.^[40]

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).^[41]

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.^[42] Normalerweise muss dieses 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.

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.^[43]

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 haben entsprechende Spezifikationen herausgebracht:

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

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.

Intels „Virtualization Technology for Connectivity“ (VT-c).^[47] 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.^[48]

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.^[48] Dabei wird jeder VM eine separate Queue für „seine“ Netzwerkpakete innerhalb des Netzwerkadapters zugewiesen, wodurch die Quelle- und Zielerkennung für Netzwerkpakete vereinfacht und beschleunigt wird. Die Quelle- und Zielerkennung sowie das erforderliche Umkopieren der Netzwerkpakete im Speicher zwischen den Queues und den VMs wird von einem virtuellen Switch innerhalb des Hypervisors erledigt.^[49]

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

• 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. Virtuelle Funktionen, aus Hardwarefunktionen abgeleitet (Netzwerkkarte mit aktiviertem SR-IOV-Support)
7. Externes Netzwerk

• Die Grundlagen der Intel Virtualisierungs Technologien (Servermeile Technet)
• Everything You Need to Know About the Intel Virtualization Technology
• A special course at the University of San Francisco on Intel EM64T and VT Extensions (2007)
• 2 day open source & open access class on writing a VT-x VMM