Message Signaled Interrupt — Änderungen 11252 → 11253

Zeile 5: Zeile 5:
  
 
== Message Signaled Interrupts bei PCI ==
 
== Message Signaled Interrupts bei PCI ==
−
Bei PCI müssen für die Benutzung von Message Signaled Interrupts eigentlich nur das Gerät und ein APIC dazu passend konfiguriert werden; alle anderen Komponenten (inklusive eventueller Bridges u.ä.) müssen keine speziellen Voraussetzungen erfüllen. Die Message Signaled Interrupts werden als ganz normale Speicher-Schreibzugriffe an eine bestimmte Adresse geschickt. Diese Adresse muss beim PC ein APIC zur Verfügung stellen. Bei Message Signaled Interrupts kann jede PCI-Funktion mehrere unabhängige Interrupts haben und es ist kein Interrupt-Sharing erforderlich. Bei PCI gibt es Message Signaled Interrupts in 2 verschiedenen Geschmacksrichtungen, einmal als einfaches MSI und einmal als erweitertes MSI-X. Das einfache MSI unterstützt bis zu 32 Interrupts pro PCI-Funktion und die gehen alle an den selben Interrupt-Controller, das verbesserte MSI-X unterstützt bis zu 2048 Interrupts pro PCI-Funktion die alle an unterschiedliche Interrupt-Controller gehen können.
+
Bei PCI müssen für die Benutzung von Message Signaled Interrupts eigentlich nur das Gerät und ein APIC dazu passend konfiguriert werden; alle anderen Komponenten (inklusive eventueller Bridges u.ä.) müssen keine speziellen Voraussetzungen erfüllen. Die Message Signaled Interrupts werden als ganz normale Speicher-Schreibzugriffe an eine bestimmte Adresse geschickt. Diese Adresse muss beim PC ein APIC zur Verfügung stellen. Bei Message Signaled Interrupts kann jede PCI-Funktion mehrere unabhängige Interrupts haben und es ist kein Interrupt-Sharing erforderlich. Bei PCI gibt es Message Signaled Interrupts in 2 verschiedenen Geschmacksrichtungen, einmal als einfaches MSI und einmal als erweitertes MSI-X. Das einfache MSI unterstützt bis zu 32 Interrupts pro PCI-Funktion, die alle an den selben Interrupt-Controller gehen; das verbesserte MSI-X unterstützt bis zu 2048 Interrupts pro PCI-Funktion, die an unterschiedliche Interrupt-Controller gehen können.
  
 
Einen speziellen Vorteil bieten die Message Signaled Interrupts bei PCI im Zusammenhang mit busmasterfähigen Geräten: bei den klassischen INTx-Signalen kann es sein, dass dieses eher bei der CPU eintrifft als die letzten Daten, die das Gerät in den Hauptspeicher geschrieben hat. Es ist also möglich, dass ein Gerät die letzten Daten in Richtung Hauptspeicher abschickt und unmittelbar danach das INTx-Signal generiert (weil aus Sicht des Gerätes der aktuelle Vorgang erledigt ist und nun der Treiber diese Daten verarbeiten soll) und während die Daten noch in den Puffern irgendwelcher Bridges darauf warten, irgendwann den Hauptspeicher zu erreichen, kann das INTx-Signal schon längst beim Interrupt-Controller angekommen sein und dieser könnte bereits die CPU unterbrochen haben, so dass der Interrupt-Handler vom Treiber die erwarteten Daten noch gar nicht im Hauptspeicher vorfindet. Da für die Message Signaled Interrupts normale Speicher-Schreibzugriffe benutzt werden und diese sich auf ihrem Weg nicht gegenseitig überholen dürfen, ist immer gewährleistet, dass der Interrupt (als Message) erst dann den Chipsatz erreicht, wenn auch die letzten zugehörigen Daten den Chipsatz passiert haben. Um diesem Problem bei den klassischen Interrupts vorzubeugen, wird empfohlen, einfach ein noncacheable Register des entsprechenden Gerätes zu lesen, da dieser Zugriff ebenfalls den gesamten Weg von der CPU bis zum Gerät und wieder zurück nehmen muss und so sichergestellt ist, das eben keine Daten mehr irgendwo auf dem Weg noch in Puffern feststecken. Dieses Problem lässt sich nicht debuggen, da es ein Hardware-Timing-Problem ist, und tritt bei den üblichen Emulatoren und Virtualisierern nicht auf.
 
Einen speziellen Vorteil bieten die Message Signaled Interrupts bei PCI im Zusammenhang mit busmasterfähigen Geräten: bei den klassischen INTx-Signalen kann es sein, dass dieses eher bei der CPU eintrifft als die letzten Daten, die das Gerät in den Hauptspeicher geschrieben hat. Es ist also möglich, dass ein Gerät die letzten Daten in Richtung Hauptspeicher abschickt und unmittelbar danach das INTx-Signal generiert (weil aus Sicht des Gerätes der aktuelle Vorgang erledigt ist und nun der Treiber diese Daten verarbeiten soll) und während die Daten noch in den Puffern irgendwelcher Bridges darauf warten, irgendwann den Hauptspeicher zu erreichen, kann das INTx-Signal schon längst beim Interrupt-Controller angekommen sein und dieser könnte bereits die CPU unterbrochen haben, so dass der Interrupt-Handler vom Treiber die erwarteten Daten noch gar nicht im Hauptspeicher vorfindet. Da für die Message Signaled Interrupts normale Speicher-Schreibzugriffe benutzt werden und diese sich auf ihrem Weg nicht gegenseitig überholen dürfen, ist immer gewährleistet, dass der Interrupt (als Message) erst dann den Chipsatz erreicht, wenn auch die letzten zugehörigen Daten den Chipsatz passiert haben. Um diesem Problem bei den klassischen Interrupts vorzubeugen, wird empfohlen, einfach ein noncacheable Register des entsprechenden Gerätes zu lesen, da dieser Zugriff ebenfalls den gesamten Weg von der CPU bis zum Gerät und wieder zurück nehmen muss und so sichergestellt ist, das eben keine Daten mehr irgendwo auf dem Weg noch in Puffern feststecken. Dieses Problem lässt sich nicht debuggen, da es ein Hardware-Timing-Problem ist, und tritt bei den üblichen Emulatoren und Virtualisierern nicht auf.