Auf 32 Bit 64 Bit emulieren?

#1752475
Lesenswert?

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.
Gast #1753357
Lesenswert?

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.
#1753372
Lesenswert?

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.
#1753893
Lesenswert?

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
Gast #1754372
Lesenswert?

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.
#1754392
Lesenswert?

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
#1754741
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren