Für diejenigen unter euch, die noch mehr Interesse am Betriebssystembau haben, bieten wir dieses Semester das erste Mal eine Erweiterung von OOStuBS zu MPStuBS mit Multiprozessorfähigkeit an. Dies hat zunächst Folgen für die benötigte Hardwareunterstützung durch das Betriebssystem, denn es muß für den Start der zusätzlichen CPUs und für die korrekte Interruptverteilung im System gesorgt werden. Für den Betriebssystemarchitekten spannend werden vor allem aber die erforderlichen Änderungen in Bezug auf die Interruptbehandlung und die Kernsynchronisation.
Wir stellen zunächst eine Basis für MPStuBS zur Verfügung, durch die ggf. vorhandene CPUs gebootet werden und eine Interruptbehandlung durch Verteilung auf die vorhandenen CPUs voreingestellt werden. Ihr seid allerdings explizit dazu aufgefordert, diese Teile zu verändern und damit zu experimentieren!
Vorgabe
Das MPStuBS-Basissystem findet sich unter /proj/i4bs/vorgaben/mpstubs_base.tar.gz. Dieses Archiv beinhaltet Implementierungen für neue Klassen (z. B. für die APICs) und veränderte Versionen schon in OOStuBS vorhandener Klassen, die die Multiprozessorunterstützung gewährleisten. Wenn ihr eine Revisionsverwaltung (z. B. SVN) für eure OOStuBS-Implementierung habt, dann könnt ihr die MPStuBS-Vorgabe einfach ueber einen Checkout auspacken und per svn diff anschauen, was die MPStuBS-Unterstützung mit sich bringt. Diese Änderungen sind im Folgenden auch kurz dokumentiert.
Änderungen zur Multiprozessorunterstützung
Geänderte Klassen und Funktionen
sections: Das neue Linkerfile sorgt dafür, dass setup_ap() an eine definierte Stelle gelinkt wird, die den zu startenden CPUs per Inter-Prozessor-Interrupt geschickt wird.
startup.asm: Enthält zusätzlichen Startup-Code für die Applikationsprozessoren (APs) in Form von startup_ap(), welcher u. a. den Stack richtig initialisiert und main_ap() aufruft.
guard/guardian.cc: Enthält eine Quittierung der Interruptabarbeitung beim lokalen APIC nach Ausführung des Prologs. Vorsicht: Die Epilogabarbeitung ist in der Vorgabe nicht enthalten! Außerdem wird die Nummer der ausführende CPU ausgegeben, um die Interruptverteilung zu untersuchen. (Vorsicht: Die Ausgabe ist nicht synchronisiert und kann natürlich ggf. auskommentiert werden.)
main.cc: Enthält die Startsequenz für die Erkennung eines SMP-Systems und das Booten der APs; außerdem werden die APICs initialisiert. Zusätzlich ist eine Funktion main_ap() definiert, die schließlich von den APs ausgeführt wird und am Anfang Code für das Rückmelden beim Bootstrapprozessor (BSP) enthält.
Neue Klassen und Funktionen
machine/smpsys.[cc,h]: Enthält den Hauptcode für das Erkennen und Starten eines SMP-Systems (per MSP und ggf. ACPI), der von dem BSP und den APs ausgeführt wird. Die meisten dieser Aufrufe passieren in den jeweiligen main()-Funktionen.
machine/acpi.[cc,h]: Enthält Hilfscode für die SMP-Erkennung und SMP-Konfiguration per ACPI.
machine/ioapic.[cc,h]: Steuert den bzw. die I/O-APICs im System. Wichtig ist vor allem die korrekte Initialisierung und die Möglichkeit zur Aktivierung und Deaktivierung von Interrupts zur Laufzeit.
machine/lapic.[cc,h]: Steuert die lokalen APICs im System (einen pro CPU). Die Register sind immer an der selben Stelle im Adressraum eingeblendet, sodass die Auswahl der Instanz des angesprochenen lokalen APICs implizit dadurch erfolgt, dass der Code auf der entsprechenden CPU ausgeführt wird. Der lokale APIC bietet u. a. Methoden zum Senden eines Interprozessorinterrupts (nötig u. a. für das Starten anderer CPUs) und zum Bestätigen eines Interrupts.
machine/setup_ap.asm: Enthält den Setup-Code für die APs, welcher u. a. die Segmente vorinitialisiert, die Deskriptortabellen lädt und in den Protected Mode umschaltet.
machine/spinlock.h: Eine kleine Spinlock-Implementierung, die sich eines GCC-Builtins bedient. Dieses Builtin wird abhängig von der Hardware kompiliert.
object/debug.h: Debug-Makros für die SMP-Entwicklung. Wird aktiviert z. B. per CFLAGS=-DDEBUG make.
Dokumentation
Die o. g. Implementierung richtet sich im Wesentlichen nach drei Spezifikationen; in diesen könnt ihr z. B. Anregungen finden, wie sich das Interruptverteilungsverhalten verändern lässt.
Bei Problemen steht euch die Mailingliste mpstubs [AT] i4.informatik.uni-erlangen.de zur Verfügung; bitte schreibt eine kurze Mail an Wanja, wenn ihr auf die Liste aufgenommen werden wollt. Dort können Probleme und Lösungsalternativen diskutiert werden; außerdem werden dort Bugfixes in unseren Vorgaben angekündigt.
Bekannte Probleme
IRQ-Routing
Voreingestellt haben wir eine Art Round-Robin-Routing fuer die IRQs. Laut Spezifikation sollten die IRQs also gleichmäßig auf alle CPUs verteilt werden. Das funktioniert auch wunderbar auf aktuellen Core-CPUs; bei P1- und P3-Dual-CPU-Systemen funktioniert es, allerdings nicht wirklich "gerecht"; in Qemu bekommt leider immer dieselbe CPU den IRQ. Zum Testen sollte das aber zunächst auch genügen.
MPS vs. ACPI
Ältere System (z. B. echte P1- und P3-Dual-CPU-Systeme) implementieren die Intel-Multiprozessor-Spezifikation komplett; dafür ist der von uns vorgegebene Basiscode auch ausgelegt. Die neuen Core-CPUs weichen jedoch in einigen Teilen davon ab und bieten dafür eine ACPI-Schnittstelle für diese Sachen an. Wir arbeiten im Moment an einer Implementierung dafür, die wir euch zu gegebener Zeit hier zur Verfügung stellen. Als Workaround hilft es im Moment, die SMP-Detektion zu übergehen und die Anzahl der zu bootenden CPUs in main() fest eingibt.
Die aktuelle Version des MPStuBS-Basiscodes enthält nun auch Code, um die ACPI-Tabellen auszulesen; damit funktioniert die SMP-Erkennung und SMP-Konfiguration auf allen uns bekannten Systemen. Wenn MPStuBS bei euch trotzdem nicht laufen sollte, schreibt uns bitte eine Mail, damit wir zusammen das Problem herausfinden können.
Aufgabe 1
Eure Aufgabe besteht zunächst darin, euch in das System einzuarbeiten und damit zu experimentieren, indem ihr z. B. verschiedene Anzahlen von CPUs bootet oder die Systemfunktion im Mono- und Multiprozessorbetrieb vergleicht und damit ein Gefühl für die Nebenläufigkeit bekommt. Auf welche Probleme stoßt ihr, wenn ihr das Pro-/Epilogmodell auf einem SMP-System umsetzen wollt?
