das gastsystem läuft auf der realen cpu im user-mode, nicht im privelegierten modus. befehle, die dem privelegierten modus vorbehalten wind werden nicht etwa vom wirtssystem gefiltert und in veränderter weise (workaround oder sowas) an die cpu geleiget, sondern das gastsystem versucht, sie aus zu führen, dies schlegt fehl, die cpu wirt nen interrupt, vmware fängt den interrupt ab, wertet ihn aus und startet dann erst seine workaround. ist so wesentlich effitienter als alle befehle die das gastsystem ausführen will durch den vmware prozess zu schleusen.
dass das der fall ist zieht allerdings nach sich, dass das gastsystem nicht etwa eine virtuelle cpu zu gesicht bekommt (wie es bei allen anderen komponenten des virtuellen rechners der fall ist), sondern die reale cpu.
und das wiederum schließt die möglichkeit aus, betriebssysteme andserer rechnerarchitekturen laufen zu lassen. wenn du ein betriebssystem hast dass nicht auf i32 (sofern du nen 32bit rechner hast) oder i64 (sofern du nen 64bit rechner hast, wenn ich mich nicht verlesen hab ist das ne neuerung der 5.5er version) läuft kriegst du das auch nicht durch vmware geregelt. genauso wie du windows oder linux nicht auf einer anderen als der i32 oder i64 architektur durch ein virtualisierungstool zum laufen kriegst.
ein mittelweg sind die neuen macs mit intel cpu. hier könnte unter umständen linux, mit viel trickserei auch windows laufen, genauso wie momentan schon auf nem i32 oder i64 rechner mac os-x zum laufen gebracht werden kann.
ich hoffe ich hab hier keinen stuss erzählt, das ist jedenfalls die grundlage jeder virtualisierung. vmware wird da ja wohl hoffentlich keinen eigenen weg gegangen sein
