Diskussion:Secure Virtual Machine

Überarbeiten

Dieser Artikel ist das Resultat einer Diskussion im Artikel AMD Virtualization. Ich habe diesen Artikel nun einstweilen erstellt und AMD Virtualization und Intel VT entsprechend umgeändert. Die Funktionsweise dieser SVMs sollte also hier erklärt werden. Mir fehlen dazu leider die Kenntnisse. --Stickedy 19:47, 27. Nov. 2006 (CET)

Es ist die Geschichte mit der Ring 0 Problematik, die dadurch gelöst wird, dass so etwas wie ein Ring -1 eingeführt wird. Das ist nötig um nur genau einem Kernel (dem Hypervisor) zu ermöglichen immer wieder in die Kontrolle über die Maschine zu kommen. Er legt fest was gilt, wer was darf, usw. :) Und wenn einer der anderen etwas anstellt, was er nicht darf, kommt der Hypervisor wieder dran (per Exception/Trap) und kann die Situation behandeln. Besser kann ich es gerade nicht erklären ohne nachzuschlagen.

Mit Ring 0 Problematik ist gemeint, dass ein Betriebssystem-Kernel normalerweise den Ring 0 braucht um die Kontrolle über die Maschine zu sichern. Das heisst im Ring 0 kann er alle priviligierten Befehle nutzen um das System zu konfigurieren, wobei nur sein eigener Code im Ring 0 laufen soll, um zu vermeiden, dass fremder Code dasselbe tun kann. Da nun aber ein virtualisiertes Betriebssystem ebenfalls allein im Ring 0 laufen will bzw. im Ring 0 laufen soll, damit die privilegierten Befehle nicht durch Exception Handling emuliert werden müssen, ergibt sich das Problem. Dabei geht es auch immer um das Zugriffsrecht auf Speicherseiten, die nur Code im Ring 0 erlaubt sind (zB. pagetables, interrupt description table, ...).

Die Hardwareunterstützung für Virtualisierung stellt also quasi einen Mechanismus zur Verfügung, der es einem Hypervisor ermöglicht privilegiert zu bleiben, während noch andere virtualisierte Betriebssysteme ablaufen, und deren Hardwarezustände (zB. control flags, page table pointer, ...) zu verwalten. Die virtualisierten Systeme können dadurch die Hardware (auf die sie Zugriff haben) fast in normaler Weise verwenden, ohne dass so oft Exceptions ausgelöst und vom Hypervisor behandelt werden. Darum kann sich durch die Hardwareunterstützung ein Performance Vorteil ergeben.

Ich kann mir irgendwie nicht so recht vorstellen, dass der Hauptzweck der Hardware-Virtualisierung sein soll, die Performance zu erhöhen. Beispielsweise läuft Windows XP in VirtualBox extrem viel langsamer mit VT/Pacifica als ohne (jedenfalls auf meinem AMD). Und die einzige WinXP-Maschine, die ich je in Xen gesehen habe, war extrem lahm.

Die Vorteile der hardwarebasierten Virtualisierung liegen im reduzierten Virtualisierungsaufwand und der damit verbundenen Performance-Verbesserung. Zugleich sind hardwarebasierte Virtualisierungslösungen sicherer, da das Gastbetriebssystem besser überwacht werden kann. Diese Möglichkeiten müssen natürlich vom Hypervisor aktiv genutzt werden um den gewünschten Geschwindigkeits- und Sicherheitsgewinn zu erzielen. -- Virtimo 23:12, 11. Dez. 2009 (CET)

Performance

Im Artikel steht etwas von 50% bis 80% der Ausführungsgeschwindigkeit des Host-Systems, die Werte des Benchmarks in der Qulle (Seite 2) entsprechen jedoch Werten zwischen (gerundet) 33% und 63%, daher sollte man die 50%-80% im Artikel am besten mit 30%-65% ersetzen. --80.109.39.94 13:36, 12. Jul. 2011 (CEST)

Teilweise kommt die Performance näher heran als 65%: Benchmarking Parallels, Fusion, and VirtualBox Against Boot Camp vom 17. September 2012. Teilweise ist die Performance dann aber gerade mal die Hälfte. ‣Andreas•⚖ 23:53, 28. Feb. 2013 (CET)

qemu

Auf der Basis von Bochs wurde damals qemu entwickelt, welches die Ausführungsgeschwindigkeit ca. 1/6 des Hostsystems hatte. Mit dem Kerneltreiber kqemu jedoch konnte diese Geschwindigkeit fast auf die des Hostsystems angehoben werden. Es würde mich freuen, wenn Qemu in dem Artikel nicht zu kurz wegkommt, bislang steht da nichts darüber.

Gruß (nicht signierter Beitrag von 46.115.21.66 (Diskussion) 14:04, 27. Mai 2012 (CEST))