Virtueller Speicher und MMU: Wann werden sie verwendet und wann nicht?

1331
iMineLink

Ich frage mich, wie ein virtuelles Speichersystem zusammen mit einer MMU verwaltet werden kann, wenn einige "feste" Adressen im Adressraum vorhanden sein müssen.

Wenn zum Beispiel eine Maschine hochfährt, beginnt die CPU mit dem Lesen der ersten Anweisung von einer festen Adresse (die einer Art von ROM zugeordnet ist), und gibt dann Adressen an Pheriperals (wenn das E / A-System mit Speicherzuordnung verwendet wird) und dann wird das Betriebssystem bootstrapped. Ich weiß auch, dass Interrupt-Routinen und solche Dinge an einer "festen" Position im Speicher sein müssen und diese Dinge vom Betriebssystem geladen werden.

Ich denke vielleicht, dass die MMU in einem solchen Prozess deaktiviert ist und nach dem Laden des Betriebssystems aktiviert wird.

Ich denke, dass die obigen Prozesse Systemadressraum verwenden und der Systemadressraum nicht virtualisiert ist, obwohl der Benutzeradressraum tatsächlich ist.

Dies führt zu einem Pool physikalischer Adressen, der gleich bleibt, um auf E / A-Peripheriegeräte zuzugreifen, Routinen usw. zuzulassen, und zu einem von der MMU verwalteten virtuellen Benutzerraum, in dem die Prozesse alle Daten verarbeiten können, die sie zur Verarbeitung benötigen, fordert das Betriebssystem den Zugriff auf E / A-Peripheriegeräte auf.

Aber ich bin mir dieser Dinge nicht sicher. Ich frage dich also, wann die MMU tatsächlich aktiviert ist? Handelt es sich um alle Adressen oder nur um die des Benutzerraums? Stimmt es, dass einige Adressen die MMU auch bei laufendem System umgehen können, um auf feste Speicherpositionen zuzugreifen? Oder vermisse ich wichtige Hinweise?

3

2 Antworten auf die Frage

1
Jamie Hanrahan

Tut mir leid, aber die Spekulation in der gewählten Antwort ist irreführend und lässt den wichtigsten Aspekt weg, nämlich die Adressübersetzung über Seitentabellen.

Es stimmt, dass beim Start einer PC-kompatiblen Maschine der "Real-Modus" gestartet wird. Und moderne 32-Bit-Betriebssysteme auf x86 laufen im "Protected Mode", zu dem die segmentierte Adressierung gemäß GDT gehört. Sie ermöglichen dann jedoch auch eine seitentabellenbasierte Adressumsetzung durch Setzen des PG (Paging) -Bits Bit 31 in CR0. Dies ist für die Dauer des Betriebssystems niemals deaktiviert.

In den meisten modernen 32-Bit-Betriebssystemen wird die GDT-basierte segmentierte Adressierung im Wesentlichen umgangen: Alle häufig verwendeten GDTEs werden mit der Basisadresse 0 und einer Größe von 4 Milliarden Byte eingerichtet. Obwohl die MMU jedoch die Bewegungen des Hinzufügens des relevanten Segments "Basisadresse" zu der "Verschiebung" durchführt, die von dem Befehl ausgeht, ist dies tatsächlich ein No-Op. Ein anderer Satz GDTEs wird für Ring 0 und Ring 3 verwendet, aber alle haben dieselbe Basisadresse und -größe. Die "Privileg Level" -Felder (0 vs 3) betreffen alles, was unterschiedlich ist. Dies ermöglicht, dass das Bit "privilegierter Zugriff" in den Seitentabelleneinträgen wirksam ist, wodurch der Speicher für den Kernelmodus oder den Benutzer- und Kernelmoduszugriff Seite für Seite geschützt werden kann. Das ist mit Segmentdeskriptoren nicht möglich. Sie sind viel zu grobkörnig.

Bei x64-CPUs verschwindet der Segmentierungsmechanismus im Langmodus im Wesentlichen. Die seitenbasierte Adressumsetzung geschieht natürlich immer noch, solange das PG-Bit gesetzt ist. Dies ist während der gesamten Lebensdauer des Betriebssystems der Fall. Die MMU ist im Kernelmodus nachdrücklich nicht deaktiviert, und die "SO" (oder irgendetwas) verwendet keine 1: 1-Zuordnung zwischen virtuellen und physischen Adressen.

Zugriffe auf bekannte physische Adressen, wie beispielsweise solche, die PCI-ähnlichen Peripheriegeräten zugewiesen sind, werden durch Zuweisen nicht verwendeter virtueller Adressen und Einrichten der entsprechenden Seitentabelleneinträge mit den erforderlichen physischen Seitennummern erreicht. Der Code in Gerätetreibern verwendet dann die virtuellen Adressen.

Ja, DMA arbeitet hauptsächlich mit physischen Adressen. Ein dummer / billiger DMA-Controller wird in der Tat einfach mit einer vorgegebenen Startadresse und Länge in einen physisch benachbarten Puffer übertragen. Um solche Geräte zu unterstützen, werden entweder das Betriebssystem oder der Gerätetreiber dem DMA-Gerät physikalisch benachbarte "Bounce-Puffer" zuweisen, auf die zugegriffen werden kann, und Daten zwischen diesem und dem Puffer des Benutzers zu kopieren.

Intelligente / teurere DMA-Controller können Puffer behandeln, die unzusammenhängende Bereiche physikalischer Adressen belegen (als "Scatter-Gather-Mapping" bezeichnet). Diese werden für Hochleistungsgeräte bevorzugt.

Eine IOMMU kann dummen / billigen DMA-Controllern den Zugriff auf einen physisch nicht zusammenhängenden Puffer ermöglichen, als wäre dieser zusammenhängend. Plattformen mit IOMMUs sind jedoch noch nicht allgegenwärtig genug, um zu sagen "Ihre Plattform muss eine IOMMU für unser Betriebssystem haben". Daher werden IOMMUs derzeit hauptsächlich von VM-Monitoren verwendet.

-1
LawrenceC

x86-CPUs starten in einem "Real-Modus" - im Grunde im 16-Bit-Modus, in dem die CPU nur die ersten 1 MB RAM sehen kann. Eine der ersten Aufgaben eines BIOS-Bootloaders (oder UEFI kann dies direkt tun) besteht darin, die CPU in den "geschützten" Modus zu schalten. In diesem Modus ist geschützter Speicher verfügbar, und die CPU verfügt in diesem Modus über Berechtigungsstufen - im Allgemeinen "Kernel" und "Benutzer".

Ich bin ein wenig unscharf, aber wie die Speicherabbildung der MMU durch die Global Descriptor Table (GDT) gesteuert wird. Der Kernel-Modus kann den GDT ändern, der Benutzermodus nicht.

Wenn also der Kernel-Modus aktiviert ist, kann der GDT auf eine Speicherzuordnung gesetzt werden, bei der entweder Identität allen Speicher zuordnet (dh sich so verhält, als wäre er überhaupt nicht zugeordnet) oder auf eine Art und Weise, die Zugriff auf alle Geräte usw. ermöglicht kehrt zum Benutzermodus zurück, es kann restriktivere GDT laden, bevor die Steuerung zurückgegeben wird.

Ich könnte falsch sein - wenn die CPU in den Kernel-Modus wechselt, wird die MMU einfach deaktiviert. Ich glaube jedoch, dass sie auch auf diese Weise vom Kernel-Modus verwendet werden kann.

Das macht Sinn! Entweder verwendet der SO also eine "1: 1" -Speicherzuordnung oder deaktiviert die MMU im Kernelmodus überhaupt ... Dinge wie DMAs-Controller, die eine Basisadresse und eine Puffergröße erhalten, um Daten direkt vom oder in den RAM zu übertragen Adressen, die sequentiell sind, werden also im Kernel-Space verwaltet? iMineLink vor 10 Jahren 0
Es gibt einige Details zum Windows-Bootloader in http://channel9.msdn.com/Shows/Going+Deep/Inside-Windows-8-Chris-Stevens-Boot-Environment David Marshall vor 10 Jahren 0
DMA funktioniert wahrscheinlich nur auf der physischen Adressebene - obwohl neuere CPUs über eine IOMMU verfügen, die eine Übersetzung von E / A-Adressen von Geräten zulässt. LawrenceC vor 10 Jahren 0
@DavidMarshall Danke für das Video, ich habe es heruntergeladen und ich werde es so bald wie möglich sehen. > ultraschallklinge interessant! iMineLink vor 10 Jahren 0