Thema: APIC FIFO size

[Dimension]

Weiss jemand das Limit der Warteschlange für Interrupts im Local APIC? Also wenn

• IF gelöscht wird (mit CLI bzw. in einer Interrupt-Gate-ISR),
• daraufhin IRQs oder IPIs auftreten, bevor
• IF wieder gesetzt wird (mit! STI bzw. beim Verlassen der ISR), so dass
• die aufgetretenen Interrupts der Reihe nach abgearbeitet werden?

Die Spezifikationen von Intel geben leider keine Auskunft darüber.

Btw: Weiss jemand ein gutes Tutorial für SMP/APIC bootstrapping? Ich habe dieses hier gefunden: http://www.cheesecake.org/sac/smp.html

[Dimension]

Ich möchte IPC und Synchronisation über IPIs realisieren, indem alle Interrupts in Queues geschrieben werden. Softwareseitig denke ich an 64k slots in einem Ringspeicher. Wäre natürlich nett zu wissen, wie groß der APIC Queue genau ist, um im Zweifelsfall das Protokoll auf wiederholtes Senden der Requests auszulegen.

In "Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 3A" (ftp://download.intel.com/design/processor/manuals/253668.pdf),
steht auf Seite 503:

3. If the local APIC determines that it is the designated destination for the interrupt
but the interrupt request is not one of the interrupts given in step 2, the local
APIC looks for an open slot in one of its two pending interrupt queues contained
in the IRR and ISR registers (see Figure 10-20). If a slot is available (see Section
10.8.4, “Interrupt Acceptance for Fixed Interrupts”), places the interrupt in the
slot. If a slot is not available, it rejects the interrupt request and sends it back to
the sender with a retry message.

und auf Seite 506:

If more than one interrupt is generated with the same vector number, the local APIC
can set the bit for the vector both in the IRR and the ISR. This means that for the
Pentium 4 and Intel Xeon processors, the IRR and ISR can queue two interrupts for
each interrupt vector: one in the IRR and one in the ISR. Any additional interrupts
issued for the same interrupt vector are collapsed into the single bit in the IRR.
For the P6 family and Pentium processors, the IRR and ISR registers can queue no
more than two interrupts per priority level, and will reject other interrupts that are
received within the same priority level.

Was ganz danach aussieht, als ob die Länge der Queue 2 wäre.

naja, Bochs liefert mir für

Code: [Auswählen]

cli
mov ecx,0xFFFF
loop1:
int INTERRUPTNUMMER
loop loop1
sti
64k interrupt-nachrichten und eine Queue overflow warnung xD

[Svenska]

Könnte man das so interpretieren, dass die Queue-Länge abhängig vom Prozessor ist?

[Jidder]

naja, Bochs liefert mir für

Code: [Auswählen]

cli
mov ecx,0xFFFF
loop1:
int INTERRUPTNUMMER
loop loop1
sti
64k interrupt-nachrichten und eine Queue overflow warnung xD

Softwareinterrupts, die in einer Queue landen bzw. irgendwas mit APIC zu tun haben? Das ist mir neu. Was passiert da?

[Dimension]

Softwareinterrupts, die in einer Queue landen bzw. irgendwas mit APIC zu tun haben? Das ist mir neu. Was passiert da?

Nun, irgendwo müssen die Interrupts wohl in einer Art Queue gehalten worden sein, so dass diese nach dem STI jeweils den Aufruf ihrer ISR bewirken. In wie weit dies mit Bochs zusammenhängt und ob es mit IRQs/IPIs entsprechend funktioniert, muss ich noch prüfen. Ist vielleicht noch hilfreich zu erwähnen, dass ich bisher noch mit dem alten PIC arbeite.

Edit: seltsam, ich hätte schwören können, nach CLI keine Interrupts mehr empfangen zu haben. Ändert jedoch nichts an der eigentlichen Problemstellung. Zumindest was IRQs und IPIs betrifft.

Zum genaueren Verständnis: Die Queue wird atomisch vom Hauptteil der ISR, welche für alle ISR gleich  ist in die Queue geschrieben und im Scheduler beim Taskwechsel (bzw. bei mir im Hypervisor vor jedem Code-Block) atomisch gelesen und abgearbeitet. Mit diesem Prinzip würde ich dann ggf. eine zentrale Methodik zur Synchronisation relaisieren.

Wäre natürlich denkbar, dass sich die Queue-Register bzw. ihre Speicherlayouts je nach CPU-Modell unterscheiden. Falls irgendjemand, der den Thread liest genaue Zahlen hat, bitte hier posten!!!

[rizor]

Wenn ich das richtig deute, sind das keine echten Queues.
Sondern es kann passieren, dass wenn du in einem Interrupt-Handler einen STI machst, dass der selber Handler dann nochmal von der CPU aufgerufen werden kann (nested interrupts).
Mit der Einführung von Priority-Levels ändert sich das Konzept auch nicht großartig, außer dass das Ganze durch verschiedene Levels definiert werden kann.

Aber ein Software-Interrupt wird da mit Sicherheit nicht eingetragen.
Wieso solltest du im Kernel-Space einen Software-Interrupt machen?
Bei einem User-Space-Handler sind die Interrupts meistens aktiv und somit funktionieren dann auch wieder Software-Interrupts, die nicht gequeued werden müssen.

[Dimension]

Es sollte immer nur eine ISR exklusiv und in der Reihenfolge des Auftretens ausgeführt werden. Im Endeffekt wird es darauf hinauslaufen, dass ich keine Software-Interrupts, sondern ausschließlich IPIs verwende.

Im Wiki ist APIC/SMP noch etwas oberflächlich behandelt. Evtl. kann man einen Verweis auf das Tutorial aus meinem ersten Posting einfügen. Es beschreibt leider nur theoretisch und hat keine Code-Beispiele, hat einer guten (kompakten) SMP bootstrap code, evtl. aus einem der Kernel-Projekte im Wiki? Ich frage mich bspw., ob man Code aus GRUB verwenden kann, da jeder AP im RM startet.

[rizor]

Interrupts werden nicht der Reihenfolge nach abgearbeitet.
Bei Emulatoren vermutlich schon, aber ich bezweifel, dass die reale Hardware das garantiert.
Interrupts werden entsprechend ihres Levels abgearbeitet.

Du brauchst dafür keinen Grub-Code. Der macht viel zu viel Zeug.
Bau dir einfach kleinen Code, der sofort in den PM springt und dann den Scheduler anspringt oder auf einen Interrupt wartet.
Dann ist alles auch schon fertig.
Der Code muss halt nur gegen Adressen unterhalb der 1MB-Grenze gelinkt werden und dann vom Kernel auch an die entsprechende Stelle geladen werden.