Mein momentanes Interessenfeld bezieht sich ja sehr stark auf alles, was mit System- und Hardwarenaher Programmierung zu tun hat.
Da ich auf der Zugfahrt zum 26c3 nicht besonders viel zu tun hatte und die AMD und Intel Dokumentationen auf meinem Rechner hatte, habe ich mal angefangen mich um die Virtualisierungsfunktionen, die diese beiden Hersteller da so in ihre Prozessoren verpflanzen, zu kümmern.

Nachdem ich dann auch irgendwann mal raushatte, wie ich das vierstufige (!) Paging mit 4KB großen Pages beim Booten zusammenbauen konnte, um so einen Prozessor in den Long Mode zu bekommen, hab ich mich mal an die Virtualisierung machen wollen.
Zu diesem Zeitpunkt saß ich allerdings schon im Hackcenter.

Wie ich dann, mal wieder, feststellen musste, hat so ein Low Level Zeug einen unglaublichen Rattenschwanz, den man immer wieder hinter sich herzieht. In diesem konrekten Fall brauchte ich also ein vernünftiges Interrupthandling. Ist ja schnell implementiert, dachte ich mir und kopier mir meinen Code aus meinen anderen Projekten fröhlich zusammen.

Interrupts konnte ich dann handlen. Problem war jetzt nur, dass 2 Instruktionen nach dem Aktivieren der Interrupts sofort der Interrupt #8 auftrat, was nach Dokumentation ein Double Fault gewesen sein müsste. Dieser tritt aber nur nach einer fatalen, vorhergegangenen Exception auf, wovon ich aber nichts mitbekommen habe. Wieso fliegt da also ein Double Fault? Nichtmal die 2 Instruktionen, die nach dem setzen des Interrupt Enable Flags ausgeführt wurden konnten einen solchen Interrupt auslösen, weil es Sprünge zu sich selbst waren, um die CPU in einer Endlosschleife zu halten.

Kommen wir zurück zum Rattenschwanz: Nachdem ich dann die Interrupt Handler und die Verwaltung der IDT hatte, habe ich noch Routinen zur Verwaltung der GDT implementiert. Es funktionierte immernoch nicht, was allerdings zu erwarten war, da es mehr eine Verzweifelungstat war als ein richtiger Lösungsansatz. Wir sind zu diesem Zeitpunkt bei Tag 3 des Kongresses.
Allerdings war das ja auch nicht das Einzige, was ich da gemacht habe. Gab ja noch Vorträge.

Danach gings ans Debuggen. Ich habe VMware probiert, um zu sehen, was das Ding sagt. Wie erwartet: nichts. Es fehlen einfach die Debuggingmöglichkeiten unter Mac OS mit VMware.
Dann gibts noch Qemu, an den man einen GDB klemmen kann. Gesagt getan. Nach wie vor nichts gefunden.
Als letztes bin ich mit dem integrierten Debugger in Bochs dem Kram zu Leibe gerückt, mit dem man seinen Code auf Assemblerebene Debuggen konnte. Auch hier habe ich wieder nichts gefunden.

Was war das Ende vom Lied? Es gibt einen extra Chip auf x86 Systemem, der externe Interrupts handlet. Früher war das der PIC (Programmable Interrupt Controller) und heute ist es der APIC (Advanced Programmable Interrupt Controller), der auch Mehrprozessorsysteme ohne Gefrickel unterstützt.
Diese Chips kann man so konfigurieren, dass jeder externe Interrupt (Tastatur, Floppy, Timer etc) auf einen der 256 Interrupts der CPU gemappt werden kann.

Irgendein Stück Software vor meinem Kernel hat genau das anscheinend mit dem Timerinterrupt gemacht und ihn auf Interrupt #8 gelegt.
Das würde dann auch erklären, warum bei einem Double Fault eigentlich ein Errorcode auf den Stack gepusht werden sollte, was bei mir aber nie passiert ist. Es war schlicht und ergreifend kein Double Fault.

Also hab ich dann doch, entgegen meiner vorherigen “Brauchste eh nich”-Meinung, auch noch Code hinzugefügt, der den PIC (eigentlich sind es 2 PICs) entsprechend konfiguriert und die 16 Interrupts, die er verwalten kann, hinter die Exceptions mappt.

Was ist? Es funktioniert endlich.

Und so kann man sich wunderschön auf die Fresse legen und Zeit verbraten.
Ich will nicht sagen ich hab nichts gelernt, genervt hat es aber doch schon ziemlich. Gedauert hat der ganze Prozess jetzt 6 Tage. Und ich hab immernoch keinen virtualisierten Code laufen.

Development, OS, OSDev, Virtualisierung