Hallo, ist es möglich auf einem 32Bit hostsystem ein 64 bit system zu emulieren? also mit vm ware oder ähnlichem? genauso andersrum?
ich schrieb: > Hallo, ist es möglich auf einem 32Bit hostsystem ein 64 bit system zu > emulieren? also mit vm ware oder ähnlichem? Nein, nicht mit effizienter Virtualisierung wie VMware&Co, nur mit sehr ineffizienter Vollemulation wäre das möglich.
Ja und jein, "richtige" Simulation ala Bochs geht immer. VirtualBox kann bspw. seit der 2.1 auch auf einem 32-Bit Host-Betriebssystem ein 64-Bit Gastsystem emulieren, wenn der Prozessor 64-Bit unterstützt und Hardwarevirtualisierung unterstützt (also Intel VT-x bzw. AMD-V kann). http://forums.virtualbox.org/viewtopic.php?t=8669
Eine kleine Frage, die ich nicht beantwortet haben muss... Ein 32 bit System hat maximal 3Gyte RAM und emuliert ein 64bit System mit zB 8GByte. Wo wird da die Geschwindigkeit sein ? Das wird dann alles auf die Platte ausgelagert...
Wer redet hier über 8GB? Scheinbar nur Du ... VMware kann das auch - zumindest VMware server V2. Also 64bit Guest auf 32-Bit Host, wenn die CPU 64bit unterstützt
qemu kann sowas, bei einigermaßen brauchbarer Performance.
Hey noch Was schrieb: > Ein 32 bit System hat maximal 3Gyte RAM 4GB > und emuliert ein 64bit System mit zB 8GByte. Wie soll es das denn machen? > Wo wird da die Geschwindigkeit sein ? Das wird dann alles auf die > Platte ausgelagert... Nein. Es geht einfach gar nicht.
klar gehen mehr als 4 Gb mit 32 Bit System nur XP kann es z.b. nicht Server 2000, 2003 usw. kann das schon lange
Der Speicher oberhalb 4 GM wird allerdings nur noch mit Tricks erreicht, denn mehr als 4 GB kann man mit 32 Bit nicht adressieren.
Zwischen der Grösse des physikalischen Adressraums und der Bitbreite eines Prozessors mit MMU besteht nicht notwendigerweise ein Zusammenhang, auch wenn das bei 386 noch auf 4GB rauslief. Seit dem Pentium Pro ist das Paging der x86 über den PAE-Modus in der Lage, ohne Tricks problemlos mehr als 4GB Speicher zu adressieren. Seit SP2 verwendet XP routinemässig PAE (wg. DEP) und erbt damit eine Speicherverwaltung aus manchen Server-Versionen, die technisch nicht auf 4GB beschränkt sein müsste - aber es aus politischen Gründen und evtl. auch zur Vermeidung von Treiberproblemen weiterhin ist.
user schrieb: > klar gehen mehr als 4 Gb mit 32 Bit System > nur XP kann es z.b. nicht > > Server 2000, 2003 usw. kann das schon lange Aber nicht in einem Prozess.
> Aber nicht in einem Prozess.
das war auch nicht die Frage
und die nutzbaren 2 Gb pro Prozess reichen sicher meist aus
user schrieb: >> Aber nicht in einem Prozess. > > das war auch nicht die Frage Die Frage war, ob mit einer Virtualisierungs-Software auf einem 32-Bit-System ein 64-Bit-System mit 8 GB RAM emuliert werden kann. Diese Software läuft aber auch nur in einem Prozess und hat daher nicht mehr als 4 GB Adressraum zur Verfügung. > und die nutzbaren 2 Gb pro Prozess reichen sicher meist aus Das wiederum war überhaupt nicht die Frage.
Rolf Magnus schrieb: > Die Frage war, ob mit einer Virtualisierungs-Software auf einem > 32-Bit-System ein 64-Bit-System mit 8 GB RAM emuliert werden kann. Diese > Software läuft aber auch nur in einem Prozess und hat daher nicht mehr > als 4 GB Adressraum zur Verfügung. Wenn ein Hypervisor auf einem 32-Bit Host einen 64-Bit Gast realisieren kann, wie das bei VirtualBox und einer CPU mit Virtualisierungssupport offenbar möglich ist, dann sehe ich keinen Zusammenhang zwischen dem logischen oder physikalischen 4GB-Adressraum des 32-Bit Hosts und dem als physikalisch vorhanden scheinenden Speicher aus Sicht des Gastes, sofern die Virtualisierungs-Software Swapping-Mechanismen enthält. Ich weiss nicht wie sich das bei VirtualBox verhält, aber der VMware ESX Hypervisor kann dem Gast via Swapping mehr physikalischen Speicher suggerieren, als dem Gast insgesamt real zur Verfügung gestellt wird. Wenngleich das keine anzustrebende Betriebsart ist, das ist eher ein Fallback wenn's kurzzeitig mal eng wird.
A. K. schrieb: > sofern die Virtualisierungs-Software Swapping-Mechanismen enthält. Noch nichtmal das ist nötig. Eine der (Haupt-)Aufgaben des Hypervisors bei AMD-V bzw. Intel VT ist die Verwaltung der Pagetables für die CPU, die Pagetables vom Gastsystem werden nicht mehr direkt benutzt, sondern stellen nur noch die Informationsbasis für den Hypervisor dar. Damit braucht der Hypervisor "nur" PAE benutzen, und kann so dem Gastsystem ohne weiteres mehr als 4GB Speicher zuweisen. Das geht prinzipiell sogar für einen 32bit-Gast, wenn dieser selbst PAE benutzt. Auch wenn man einen der im Host-OS eingebetteten Hypervisoren benutzt (VMware mit VT, KVM), wo der Gast im Host-OS als Prozess auftaucht, hat dieser Prozess (unter anderem) in Punkto Speicherverwaltung nicht mehr viel mit einem normalen Prozess gemeinsam. Die Beschränkung auf 4GB pro Prozess (bzw. ca. 3GB nach Abzug des Kernel-Adressraumes) kommt ja im wesentlichen daher, dass die vom Userspace verwendeten "Pointer" nur 32bit-Adressen darstellen können[1]. Bei Virtualisierung sind die relevanten "Pointer" an der Schnittstelle zum Hypervisor aber die "physikalischen" Adressen aus der Gast-Pagetable, und mit diesen können mehr als 4GB adressiert werden. Andreas [1] mit geschickter Kombination von Segmentierung, "Not Present"-Bit in den Segmentdeskriptoren und mehreren Pagetables pro Prozess könnte prinzipiell auch ein 32bit-OS einem normalen Prozess auf x86 mehr als 4GB Speicher zur Verfügung stellen, allerdings unter Aufgabe des Flat-Speichermodells und ggf. verbunden mit Performanceeinbussen
A. K. schrieb: > Wenn ein Hypervisor auf einem 32-Bit Host einen 64-Bit Gast realisieren > kann, wie das bei VirtualBox und einer CPU mit Virtualisierungssupport > offenbar möglich ist, dann sehe ich keinen Zusammenhang zwischen dem > logischen oder physikalischen 4GB-Adressraum des 32-Bit Hosts und dem > als physikalisch vorhanden scheinenden Speicher aus Sicht des Gastes, > sofern die Virtualisierungs-Software Swapping-Mechanismen enthält. Swapping erweitert nicht den logischen Adressraum eines Prozesses. Andreas Ferber schrieb: > Auch wenn man einen der im Host-OS eingebetteten Hypervisoren benutzt > (VMware mit VT, KVM), wo der Gast im Host-OS als Prozess auftaucht, hat > dieser Prozess (unter anderem) in Punkto Speicherverwaltung nicht mehr > viel mit einem normalen Prozess gemeinsam. > > Die Beschränkung auf 4GB pro Prozess (bzw. ca. 3GB nach Abzug des > Kernel-Adressraumes) kommt ja im wesentlichen daher, dass die vom > Userspace verwendeten "Pointer" nur 32bit-Adressen darstellen können[1]. > Bei Virtualisierung sind die relevanten "Pointer" an der Schnittstelle > zum Hypervisor aber die "physikalischen" Adressen aus der > Gast-Pagetable, und mit diesen können mehr als 4GB adressiert werden. Wird dass wirklich so gemacht oder könnte es nur theoretisch gemacht werden? Das scheint mir nämlich ein ziemlich tiefer Eingriff ins System. Im Prinzip müßte ja dafür z.B. der Speichermanager des Host-Systems durch einen vom Hypervisor bereitgestellten ersetzt werden, denn sonst würde ja spätestens bei der Schnittstelle zum System wieder die Begrenzung auf 32-Bit-Pointer zuschlagen.
Rolf Magnus schrieb: > Swapping erweitert nicht den logischen Adressraum eines Prozesses. Der ist in diesem Fall nicht relevant. Der Hypervisor muss den "physikalischen" Speicher des Gastes nicht unbedingt vollständig am Stück in seinem eigenen logischen Adressraum sehen können.
Rolf Magnus schrieb: > Im Prinzip müßte ja dafür z.B. der Speichermanager des Host-Systems > durch einen vom Hypervisor bereitgestellten ersetzt werden Um Manipulation der Speicherverwaltung kommt er sowieso nicht herum. Page faults sind ein essentieller Bestandteil der Arbeitsweise eines nicht vollständig emulierenden Hypervisors wie VMware oder VirtualBox. Weshalb die wirklich konsequent implementierte Version von Hypervisorn nicht auf einem Host-Betriebssystem drauf sitzt oder sich partiell integriert (VMware Workstation/Server), sondern unten drunter sitzt (VMware ESX, IBM VM/CMS). Virtualisierende Rootkits machen das ebenfalls: http://www.heise.de/security/meldung/Rootkit-verschiebt-Windows-in-virtuelle-Maschine-173214.html
Rolf Magnus schrieb: > Das scheint mir nämlich ein ziemlich tiefer Eingriff ins System. > Im Prinzip müßte ja dafür z.B. der Speichermanager des Host-Systems > durch einen vom Hypervisor bereitgestellten ersetzt werden, denn sonst > würde ja spätestens bei der Schnittstelle zum System wieder die > Begrenzung auf 32-Bit-Pointer zuschlagen. Im Kernel ist das nicht so wild wie es erstmal klingt. Die Speicherverwaltung von Linux z.B. stellt mit page_alloc()&Co. schon seit langem (und zwar lange vor der Entwicklung von AMD-V/Intel-VT) die Möglichkeit zur Verfügung, physikalische Pages zu allozieren, ohne sie gleichzeitig in einen Adressraum zu mappen. Die Verwaltung der Pagetables muss der Hypervisor sowieso im wesentlichen selbst machen, solange ein Gast gerade auf der CPU läuft, da er ja die Gast-Pagetables "übersetzen" muss. Die Host-OS-Funktionen dafür kann er nicht benutzen, da der Gast erwartet, den kompletten linearen Adressraum selbst verwenden zu können, das würde aber dann mit dem von den meisten Betriebssystemen für den Kernel reservierten Teil des Adressraumes kollidieren. Andreas
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.