Wie "kennen" x86-Prozessoren mehrere Prozesse, die ausgeführt werden?

Question

Ich bin sicher, die Antwort auf diese Frage ist irgendwo im Internet (oder sogar stackoverflow), aber ich habe eine schwierige Zeit, die Frage zu formulieren, um gute Ergebnisse zu erhalten.

Ich habe in der letzten Woche x86 studiert und bin durch das Konzept der x86-Prozessoren verwirrt worden, die verschiedenen laufenden Prozessen "bewusst" sind. Wenn Sie beispielsweise im geschützten Modus arbeiten, kann der x86-Prozessor den Arbeitsspeicher begrenzen, auf den ein Prozess zugreifen kann. Dies lässt mich glauben, dass der Prozessor einige existierende Prozesse irgendwie kennt.

Das verwirrt mich. Aus der Perspektive des Prozessors würde ich annehmen, dass es nur eine Liste von Anweisungen erhält, die auszuführen sind, und es liegt in der Verantwortung des Betriebssystems, diese Anweisungen (über Zeitscheiben, Speicherverwaltung usw.) so zu ordnen, dass mehrere Prozesse ablaufen können. Aus der Prozessorperspektive gehe ich davon aus, dass es nur eine sequenzielle Liste von Anweisungen geben wird.

Aufgrund der Tatsache, dass ein x86-Prozessor Speicherzugriff durch Prozess beschränken kann, ist die CPU irgendwie bewusst, dass es mehrere Prozesse gibt.

Answer 1

Aus Hardware-Sicht haben Sie recht, dass alle CPUs "Anweisungen ausführen" nacheinander ausführen. In einem (vielleicht leicht vereinfachten) Sinne ist das alles, was vor sich geht.

Wenn Sie eine bestimmte Rechenaufgabe ausführen müssten, könnten Sie tatsächlich einen geeigneten Strom von Anweisungen schreiben, damit Sie Ihre Hardware einschalten, Ihre Anweisungen ausführen und dann anhalten oder herunterfahren oder was auch immer. So wurden sehr frühe Computer tatsächlich betrieben.

Allerdings ist diese Art des Betriebs eines Computers extrem unhandlich und skaliert überhaupt nicht, da es erfordert, dass ein einziger Bediener die Verantwortung alles übernehmen und dabei alle Arten von Rädern neu erfinden. Das ist, wo das Konzept eines Betriebssystems ins Spiel kommt: Das Betriebssystem ist eine bestimmte Art von Befehlsstrom, der beim Start geladen wird, der wiederum laden und andere Bits Anweisungen ausführen kann, dynamisch. Diese Unterteilung ermöglicht die Wiederverwendung der Kernfunktionalität (Gerätetreiber) und die dynamische Anpassung der Funktionalität der Maschine (d. H. Während sie läuft, im Gegensatz zur Neuprogrammierung und Rücksetzung). Darüber hinaus ermöglicht es, dass die Teile der Anweisungen, die dynamisch geladen werden, von verschiedenen Personen erstellt werden, so dass wir eine einzige Plattform haben, die "benutzerdefinierte Anweisungen" ausführen kann, d. H.was wir üblicherweise als "Programm" verstehen.

So, jetzt haben wir alle Teile: Der Code, den die CPU beim Einschalten ausführt, ist das Betriebssystem, und das Betriebssystem verwaltet dynamisch die Ausführung von weiterem Code. Die meisten dieser Ausführungseinheiten heißen Prozesse. (Aber nicht jeder Code ist so. Zum Beispiel werden ladbare Kernel-Module in Linux dynamisch geladen, stellen aber keinen Prozess dar.) Das heißt, ein Prozess ist ein abstraktes Konzept im Betriebssystem, das zwischen dem eigenen Code des Betriebssystems abgrenzt und der "gehostete" Code, den er auf Anfrage ausführt.

Abhängig von der Art des Betriebssystems kann die Ausführung von Prozessen interessante Funktionen wie virtuellen Speicher (jeder Prozess sieht eigenen, separaten Speicher) und Schutz haben (kein Prozess kann den Betrieb des Betriebssystems oder anderer Prozesse beeinträchtigen) . Betriebssysteme implementieren solche Features, indem sie CPU-Features verwenden: eine Speichermanagereinheit, die Adressumsetzung bereitstellt, und Schutzringe, die die für eine Ausführung verfügbaren Befehle begrenzen. Nicht alle Betriebssysteme tun dies jedoch; In DOS beispielsweise hat jeder Prozess vollen Zugriff auf den physischen Speicher und damit auf den Zustand des Betriebssystems. Ungeachtet dessen stellt ein OS typischerweise eine API für Prozesse (z. B. "Systemaufrufe") bereit, die wiederum Hardwarefunktionen (Unterbrechungen oder spezielle Systemaufrufbefehle) verwenden, und Benutzercode interagiert im Allgemeinen mit der Umgebung über diese API, anstatt mit Peripheriegeräten direkt zu sprechen. Dies bedeutet beispielsweise, dass Hardwaretreiber nur vom Betriebssystem implementiert werden und Benutzercode undurchsichtige "Druckausgabe" -Aufrufe ausführen kann, ohne die Details der verfügbaren Ausgabegeräte kennen zu müssen.

Beispiel: Vielleicht ist es sinnvoll, zu veranschaulichen, welche Prozesse auf dem beliebten Linux-Betriebssystem ist, auf x86-Hardware ausgeführt werden: Ein neuer Prozess gestartet wird, wenn ein bestehender Prozess (zB eine Schale oder init) ruft den clone Systemaufruf , indem der Interrupt 128 ausgelöst wird. Der Interrupt veranlaßt die CPU, die Steuerung an die Interrupt-Handler-Routine zu übertragen, die vom Betriebssystem während des Hochfahrens eingerichtet wurde. Wenn der Interrupt-Handler eingegeben wird, wechselt die CPU zu Ring 0, privilegierter Modus. Der Interrupt-Handler veranlasst den Kernel, den neuen Prozess zu erstellen, und überträgt die Kontrolle dann zurück an den aufrufenden Prozess (was bedeutet, dass er zu Schutzring 3 wechselt, nicht privilegiert; Prozesse werden nur in Ring 3 ausgeführt). Zur Erstellung des neuen Prozesses legt der Kernel die relevanten internen Buchhaltungsstrukturen an, richtet neue Seitentabellen in der MMU ein und übergibt dann die Kontrolle an den Einstiegspunkt für den Aufruf clone, ähnlich wie der ursprüngliche Aufruf zurückkehrt. (Ich beschönige hier alle Aspekte der Planung; es findet nur eine Kontrolle statt, und die anderen werden später geplant.) Die Tatsache, dass jetzt ein neuer Prozess existiert, spiegelt sich nur in den internen Buchhaltungsdaten des Kernels wider . Die CPU weiß nichts darüber; Alles was es sieht ist, dass Interrupts gefeuert werden und Seitentabellen regelmäßig geändert werden.

Answer 2

Die CPU ist sich der Prozessplanung nicht bewusst, letztere kann auf viele verschiedene Arten implementiert werden, während die erstere ein allgemeiner Chip sein muss.

Was geschieht, ist dies

1. Das OS in Kontrolle ist (sprich: die CPU ein Betriebssystem-Routine ausgeführt wird) und Setups eine Sandbox A verwendet werden, um ein Quantum der Prozess A.
2. Prozess auszuführen A wird innerhalb dieser Sandbox ausgeführt.
3. Eine periodische Unterbrechung tritt auf, die Routine, die diesen Interrupt bedient, gehört dem Betriebssystem und befindet sich außerhalb der Sandbox.
4. Das Betriebssystem steuert und richtet eine Sandbox B ein, die verwendet wird, um ein Quantum von Prozess B auszuführen.
5. Prozess B wird in dieser Sandbox ausgeführt.

Der Vorgang wird wiederholt. Der Protected-Modus lässt das Betriebssystem Sandboxes erstellen, insbesondere definiert es Privilegien (im Real-Modus hat jedes Programm die gleichen Rechte), so dass Process A und Process B die Sandbox nicht verlassen können (zB indem sie die Interrupts deaktivieren und für immer laufen) .

Die CPU ist nicht bewusst, was passiert, es sieht nur eine Folge von Anweisungen unter verschiedenen Privilegien und "Einschränkungen" ausgeführt.
Es ist das Betriebssystem, das die CPU vor dem Ausführen eines anderen Programms anders konfiguriert.
Dies hilft auch, den Unterschied zwischen Threads und Prozessen zu erklären: Threads Scheduling ändert nicht die Sandbox.

Als Jester mich in den Kommentaren erinnerte, hat x86 Unterstützung für die Aufgabenverwaltung.
Eine HW-Task wird jedoch nicht eins zu eins einem OS-Prozess zugeordnet (IIRC wird von den Hauptbetriebssystemen kaum verwendet).

Lesen Intel Manual 3 hilft Ihnen zu verstehen, was die CPU kann und wo die Verantwortung für ein sicheres Betriebssystem von der CPU auf den Kernel verlagert wird.

Answer 3

Die CPU sieht EINEN Prozess auf einmal. Die CPU hat nur dann Kenntnis von einem Prozess, wenn sie ausgeführt wird.

Zum Beispiel kann der x86-Prozessor im geschützten Modus den Arbeitsspeicher begrenzen, auf den ein Prozess zugreifen kann.

Was Sie beschreiben, ist die logische Adressübersetzung. Das Betriebssystem definiert eine Reihe von Seitentabellen für einen Prozess, der die Zuordnung von einer logischen Seite zu physischen Seitenrahmen bereitstellt. Die Seitentabellen definieren auch den für diese Seiten zulässigen Zugriff. Jeder Prozess hat seinen eigenen Satz von Seitentabellen (in einigen Fällen können die Teile des Satzes geteilt werden).

Die Struktur der Seitentabellen wird vom Prozessor definiert. Der Inhalt dieser Tabellen wird vom Betriebssystem festgelegt. Das "Limit" des Speichers kommt also vom Betriebssystem.

Ein Teil der Prozedur zum Ändern des aktuellen Prozesses (ausgelöst durch das Betriebssystem) besteht darin, die Seitentabellen für den neuen Prozess anstelle der alten auszutauschen.

Die Prozessoren sehen diese "Grenzen" für den Speicherzugriff aus der Perspektive des gerade ausgeführten Prozesses und haben zu keiner Zeit Kenntnis von den äquivalenten "Grenzen" (Seitentabellen) irgendeines anderen Prozesses.

Aufgrund der Tatsache, dass ein x86-Prozessor Speicherzugriff durch Prozess beschränken kann, ist die CPU irgendwie bewusst, dass es mehrere Prozesse gibt.

Die CPU kennt nur die Seitentabellen des aktuellen Prozesses. Es kennt nur die "Grenzen" des Prozesses, der ausgeführt wird. Der aktuelle Seitentabellensatz definiert, auf welchen physischen Speicher der Prozess zugreifen kann und wie er darauf zugreifen kann (Lesen/Schreiben/Ausführen + Einschränkungen nach Modus).

Aus der Prozessorperspektive nehme ich an, dass alles, was es sehen würde, eine sequenzielle Liste von Anweisungen ist.

Plus-Interrupts, die ein wichtiger Teil der Prozessplanung sind.