In dieser Aufgabe kümmern wir uns um asynchrone Ereignisse, Unterbrechungen durch externe Geräte,

in unserem Fall primär doch die Tastatur, aber optional auch die Maus.

Wie wir in der Musterlösung sehen, unterbrechen die Tastaturereignisse abwechselnd alle Kerne,

erkennbar an den unterschiedlichen Farben.

Dieses Verhalten konfigurieren wir mittels den IoA-Pick.

Damit tauchen nun auch Synchronisationsprobleme auf.

Diese kritischen Abschnitte können wir mit Ticket oder Spinlocks schützen.

Optional gibt es die Möglichkeit einen GDB-Stab einzubauen, welcher zusammen mit der seriellen

Schnittstelle ein Remote-Debugging erlaubt.

Dazu müssen die Gerätetreiber wie Keyboard implementiert werden, welche sich dann bei

der Plugbox für gewisse Interrupts registrieren.

Die Unterbrechungsbehandlung Interrupt-Händler soll dann diese Plugbox nutzen, um das Geräteobjekt

zum jeweiligen Interrupt-Vektor zu bekommen.

Daneben muss noch der PS2-Controller an den Interruptbetrieb angepasst werden und die

IoA-Pick-Konfiguration implementiert werden.

Und wie konfiguriere ich diesen Advanced Programmable Interrupt Controller?

Nun dazu muss ich wissen, wo an welchen der 24 Eingänge ein Gerät am IoA-Pick angeschlossen

ist.

Was aber je nach Rechner unterschiedlich sein kann.

Abhilfe schafft die Systemkonfiguration ACPI.

Diese besteht aus vielen Tabellen, in welcher auch die gesuchten Informationen stehen.

Diese Angaben über die Verdrahtung der angeschlossenen Geräte aus den ACPI-Tabellen werden während

der Initialisierung von unserer APIC-Klasse eingelesen und über die Funktion GetIoAPIC-Slot

zur Verfügung gestellt.

Ebenfalls kommt da auch die noch zusätzende ID des IoA-Pick her.

Nun müssen wir auch noch einstellen, wer bei Interrupts benachrichtigt werden soll.

Im Gegensatz zu O-Stubs ist das bei MP-Stubs nicht so einfach.

Wir wollen zu Übungszwecken eine Gleichverteilung auf alle Kerne.

Dazu setzen wir die Priorität eines jeden LAPIC bei der Initialisierung auf Null, das

ist bereits so implementiert, und wählen im IoA-Pick die niedrigste Priorität als

Zustellmodus.

Außerdem verwenden wir die logische Adressierung für die Ziel-CPUs.

Damit können mittels Bitmaske alle CPUs angegeben werden.

Das sieht dann im Redirection-Table Eintrag so aus.

Gleich oben sieht man die Bitmasken für die Ziel-CPUs.

Das kann man auch dynamisch machen, aber man solle keinesfalls nicht existente CPUs adressieren.

Das mag zumindest die Testart wie überhaupt nicht.

Dazu muss natürlich auch Delivery und Destination Mode entsprechend gesetzt sein.

Ob der Interrupt aktiv ist und falls ja, ob er flanken oder pegelgesteuert ist, hängt

vom jeweiligen Slot bzw. Gerät ab.

Die Tastatur ist z.B.

pegelgesteuert.

Die Felder Remote Interrupt Request Register und Delivery Status können wir nicht ändern.

Und für den Interrupt Vector sollte man sich systemweit einig sein, welches Gerät was

verwendet.

Entsprechend gibt es unter Maschinen im Header CPU Interrupt ein Inam dafür.

Wenn ihr das nun in KVM testet, kann es sein, dass die Tastatur Interrupts immer auf der

gleichen CPU ankommen.

Das könnte auch am Vector Hashing liegen.

Die Interrupt Nummer wird bei neueren KVM Versionen modulo Anzahl CPUs genommen und zugeteilt.