Thema: Shared IRQs bei Micro-Kernel-OS

[erik.vikinger]

Hallo,


ich wüste gerne wie man in einem Micro-Kernel-OS mit shared IRQs umgeht.
Wenn ich das richtig verstehe sind in einem Micro-Kernel-OS die Device-Treiber auch nur ganz normale User-Space-Applicationen die den IRQ per RPC oder einem anderen Inter-Process-Comunication-Mechanismus erhalten müssen da sie ja nicht im Kernel-Space laufen. Ich wollte das so implementieren das ein User-Space-Treiber einen Signal-Handler registriert und diesen Signal-Empfänger nicht für andere Programme freigibt sondern einem IRQ zuweißt. Im Kernel gibt es dann einen (nicht mehrere) generischen IRQ-Handler der nachschaut für welchen IRQ er gerade aufgerufen wurde und dann für den entsprechenden Signal-Handler eine Nachricht generiert. Wenn nun aber mehrere physische Geräte sich einen IRQ teilen dann müsste man ja bei jedem IRQ an mehrere Signal-Handler eine entsprechende Nachricht schicken.

Habe ich da irgendwo einen Denkfehler oder wie löst Ihr dieses Problem?

Eigentlich wollte ich auf meiner Plattform shared IRQs generell verbieten und statt dessen konsequent auf MSI/MSI-X in Zusammenarbeit mit einem ordentlichen IRQ-Controller, der 4096 verschiedene IRQs (zumindest theoretisch, man muss es ja nicht vollständig implementieren) verwalten kann, bauen. Aber leider unterstützt nicht jede PCI/PCI-Express-Hardware MSI/MSI-X so das ich eventuell doch gezwungen bin shared IRQs zu unterstützen.


Grüße
Erik

[bluecode]

Ich würde den PCI-Bustreiber in den Kernel verschieben und den bei einem PCI-Interrupt nachschauen lassen (das müsste irgendwo im Configspace der Devices stehen), ob von einem bestimmten Device der Interrupt ausging und dann eben das an den jeweiligen Treiber schicken.

[erik.vikinger]

Hallo,

Ich würde den PCI-Bustreiber in den Kernel verschieben

Ich bin mir nicht sicher ob das eine gute Idee ist, es klingt eher nach einer Krückenlösung aber machbar sollte es sein.

das müsste irgendwo im Configspace der Devices stehen

Ja, ich glaube auch. Zugriffe auf den Config-Space sind aber recht langsam und müssen immer Atomar ausgeführt werden, es können also nicht mehrere CPUs gleichzeitig diesen einen generischen IRQ-Handler ausführen selbst wenn verschiedene IRQs betroffen sind.


Ein weiteres Problem sehe ich noch:
Wenn Device A einen IRQ auslöst und dieser im IRQ-Controller durch den IRQ-Handler abgehackt ist wartet der IRQ-Controller bis das IRQ-Signal wieder verschwindet. Wenn während dessen Device B, das leider am selben IRQ hängt, ebenfalls einen IRQ signalisiert sieht der IRQ-Controller das nicht das die beiden Signale ja verodert werden.
Wie kommt man aus so einem Deadlock wieder raus?
Mit MSI(-X) gibt es solche Probleme prinzipbedingt erst gar nicht.


Grüße
Erik

[kevin]

Ich würde den PCI-Bustreiber in den Kernel verschieben und den bei einem PCI-Interrupt nachschauen lassen (das müsste irgendwo im Configspace der Devices stehen)

Ja, das steht dort, aber sehr mikrokernelig ist der Ansatz nicht. Selbst bei unserer noch sehr weit gefassten Definition von Mikrokernel.

Wenn man PCI extern behält, sehe ich nur zwei Lösungen: Entweder direkt alle für den IRQ registierten Treiber benachrichtigen oder erstmal an den PCI-Treiber schicken und der verteilt dann weiter, wie es passt. Letzteres dürfte aber etwas langsam werden.

Wenn Device A einen IRQ auslöst und dieser im IRQ-Controller durch den IRQ-Handler abgehackt ist wartet der IRQ-Controller bis das IRQ-Signal wieder verschwindet. Wenn während dessen Device B, das leider am selben IRQ hängt, ebenfalls einen IRQ signalisiert sieht der IRQ-Controller das nicht das die beiden Signale ja verodert werden.

Wann wartet der Interruptcontroller worauf? Wie ich das verstanden habe: Wenn das Signal da ist und der Interrupt nicht maskiert ist, wird halt gefeuert, fertig. Nachdem der Treiber für A den IRQ verarbeitet hat, sendet er kein IRQ-Signal mehr (Kann mir mal jemand mit einer Übersetzung für "deassert" helfen? Danke. ), aber das Signal von B ist nach wie vor an. Sobald das OS den Interrupt also wieder demaskiert, feuert der Interruptcontroller nochmal.

Alles unter der Voraussetzung natürlich, dass alles level triggered ist. Bei edge triggered musst du wohl zwangsläufig alle Treiber informieren, die an dem IRQ hängen, und den EOI senden bevor du die Treiber aufrufst.

[erik.vikinger]

Hallo,

aber sehr mikrokernelig ist der Ansatz nicht.

ACK

Wenn man PCI extern behält, sehe ich nur zwei Lösungen:

Beide Lösungen sind nicht gerade sehr performant, ich möchte schon auf eine möglichst geringe IRQ-Latenz hinarbeiten und auch die Kernel-Funktionen möglichst einfach und schnell halten da diese nicht unterbrochen werden können. Wenn bei der ersten Variante ausgerechnet der richtige Device-Treiber als letztes vom Scheduler aufgerufen wird ist bereits ne menge Zeit vergangen und bei der zweiten Lösung kommt erstmal das langsame abfragen aller in Frage kommenden PCI-Devices im PCI-Handler wofür dieser die Ressource "PCI-Config-Space-Access" allozieren und hinterher wieder freigeben muss. Ich werde aber wohl in jedem Fall eine zusätzliche Ebene einbauen müssen um shared IRQs ordentlich hin zu bekommen oder ich bleibe bei meiner ursprünglichen Idee shared IRQs generell zu verbieten und kann dann eben bestimmte Hardware nicht einsetzen, das betrifft nur leider auch die typischen USB 1 und USB 2 Controller auf die ich eigentlich nur äußerst ungern verzichten würde.

Wann wartet der Interruptcontroller worauf?

Entschuldigt die blöde Frage. Ich hatte ja nicht daran gedacht das der IRQ-Controller das EOI erst nach dem richtigen IRQ-Signal-Handler bekommt, wenn das eigentliche Device seine IRQ-Leitung wieder deaktiviert (ich hoffe das passt für "deassert") haben sollte.
In meiner Plattform möchte ich das eigentlich anders machen. Dort soll der IRQ-Controller per MSI(-X) angetriggert werden, dieser meldet sich dann bei der CPU die holt dann den IRQ ab und führt anschließend den IRQ-Handler aus. Der IRQ wird im IRQ-Controller also quittiert sobald der IRQ-Handler des Kernels losläuft, völlig in Hardware ohne das die SW das selber machen müsste. Da MSI ja nicht level triggered ist sondern auf Messages basiert gibts da keine Probleme und wenn doch mal mehrere Messages kommen bevor die CPU den IRQ abgeholt hat dann ist das auch nicht schlimm. Nur dieses blöde IRQ-Sharing bereitet meiner ansich guten Idee einige Probleme.


Grüße
Erik

[bluecode]

Ich würde den PCI-Bustreiber in den Kernel verschieben

Ich bin mir nicht sicher ob das eine gute Idee ist, es klingt eher nach einer Krückenlösung aber machbar sollte es sein.

Der Vorschlag hat auch den Hintergrund, dass PCI m.E. mit ACPI relativ eng zusammenarbeiten muss, falls man das mal implementiert. Zumindest wird der PCI-Treiber sinnvoll erstmal über ACPI initialisiert (wenn man in den I/O APIC Modus schaltet). Deswegen war mein letztes gedankliches Ergebnis dazu PCI in den Kernel zu verschieben.

[erik.vikinger]

Hallo,

Der Vorschlag hat auch den Hintergrund, dass PCI m.E. mit ACPI relativ eng zusammenarbeiten muss, falls man das mal implementiert.

Ich finde eher ACPI bezieht sich sehr stark auf PCI, für Power-Management u.ä. gibt es ja entsprechende Capabilities im PCI-Config-Space. Wenn ich die ganze Device-Enumeration (und bei PCI-Express auch die Link-Konfiguration) eh komplett selber im OS machen muss (BIOS o.ä. gibt es auf meiner Plattform nicht), schon allein dafür wird es auf jeden Fall einen PCI-Treiber geben müssen, dann ziehe ich aus ACPI, was ich ja zusätzlich selber implementieren müsste, keinen großen Nutzen mehr. Ich nehme an Du beziehst Dich auf die normale PC-Plattform.

Trotz allem habe ich irgendwie Bauchweh bei dem Gedanken daran so umfangreiche Teile (die nicht wirklich was mit OS zu tun haben) in den Kernel zu verlagern, also wenn dann wird es auf einer der beiden Lösungen von taljeth hinauslaufen. Und für die klassischen PCI-Interrupt-Signale werde ich wohl einen zusätzlichen IRQ-Controller basteln müssen der dem richtigen IRQ-Controller dann per MSI meldet und von seinem SW-IRQ-Handler, in einem extra Treiber, das EOI zum richtigen Zeitpunkt bekommt. Mal schauen wie viel Aufwand das eigentlich wird, einen IRQ-Verteilungstreiber an den sich die Device-Treiber von Devices die kein MSI können anmelden sollte nicht so das Ding werden. Seht ihr da irgendwelche Denkfehler in diesem Konzept?

Zumindest wird der PCI-Treiber sinnvoll erstmal über ACPI initialisiert (wenn man in den I/O APIC Modus schaltet).

Was meinst Du damit? Was hat der I/O-APIC damit zu tun? Ich habe die ACPI-Spec noch nicht komplett gelesen, bekommt man vom ACPI eine Datenstruktur mit einer Art Device-Baum mit allen Ressourcen-Infos usw. die das BIOS verteilt hat?

Ein Frage hab ich noch :
Wie löst Ihr das Problem der shared IRQs? Mit einem der beiden Vorschläge von taljeth, einer Variante im Kernel oder gar so wie Windows und Linux das machen?


Grüße
Erik

[kevin]

Wie machen Linux und Windows das denn im Detail? Aber sind ja beides nicht wirklich Mikrokernel, insofern ist das Problem dort wahrscheinlich nicht ganz so hart. Meine Vermutung wäre, dass es in einem Monolithen am billigsten ist, einfach mal vorsorglich alle zu informieren.

[erik.vikinger]

Hallo,


In Windows und Linux soll/muss der Device-Treiber einen kleinen IRQ-Handler registrieren der prüft ob tatsächlich die eigene Hardware den Interrupt ausgelöst hat und das zurückmeldet. In den Design-Rules steht das dieser Handler wirklich nur ganz kurz die CPU belasten darf da er ja wirklich vom echten IRQ-Handler des OS aufgerufen wird. Der IRQ-Handler vom OS trägt jede positive Antwort, was durchaus mehrere pro IRQ sein können, in eine Liste ein die dann später in einem anderen Kontext abgearbeitet wird, unter Windows heißt das "Deferred-Procedure-Call". Das hat den Vorteil das der eigentliche IRQ-Handler vom Device-Treiber dann auch einige OS-Funktionen nutzen kann und sogar, um auf etwas zu warten, kurz pausieren kann. Unter Linux macht man das üblicherweise mit Kernel-Threads die dann vom kleinen vorgelagerten IRQ-Handler aufgeweckt werden. Das alles erfordert natürlich einen Monolithischen Kernel und wie das dann mit dem EOI funktioniert weis ich jetzt im Moment auch nicht mehr so genau (ist schon etwas her wo ich das letzte mal Treiber programmiert hatte).

Daher die Frage wie ihr das mit Micro-Kernel macht.


Grüße
Erik

[kevin]

In Windows und Linux soll/muss der Device-Treiber einen kleinen IRQ-Handler registrieren der prüft ob tatsächlich die eigene Hardware den Interrupt ausgelöst hat und das zurückmeldet.

Okay, das läuft also unter Kombination von "im Kernel" und "alle Treiber benachrichtigen". Nichts wirklich neues im Vergleich zu den schon genannten Alternativen.

Unter Linux macht man das üblicherweise mit Kernel-Threads die dann vom kleinen vorgelagerten IRQ-Handler aufgeweckt werden.

[edit: Ups, hab dich wohl falsch verstanden. Du redest ja genau davon, dass der Treiber das macht, während ich irgendwie beim Ausführen des eigentliches Handlers als Thread war. Ich lass das trotzdem mal hier stehen.]

Das ist, wenn ich mich recht erinnere, nur bei den Real-Time-Varianten so. Was er ansonsten macht, weiß ich nicht hundertprozentig, aber ich meine, dass tatsächlich alles direkt beim IRQ abgehandelt wird. Der Treiber könnte da natürlich nochmal seine eigenen Sachen hinbauen, um den eigentlichen Handler klein zu halten.

Das alles erfordert natürlich einen Monolithischen Kernel und wie das dann mit dem EOI funktioniert weis ich jetzt im Moment auch nicht mehr so genau (ist schon etwas her wo ich das letzte mal Treiber programmiert hatte).

Hm, den EOI will man vermutlich so früh wie möglich schicken. Wo genau im IRQ-Handler, ist wohl egal, weil Interrupts da sowieso deaktiviert sind, aber direkt anschließend hätte man sie eigentlich schon gern wieder.

[erik.vikinger]

Hallo,

Okay, das läuft also unter Kombination von "im Kernel" und "alle Treiber benachrichtigen".

Ja, nur das "alle" erstmal auf möglichst klein getrimmt wird und der eigentliche (nachgelagerte) Handler etwas später kommt. Von der Latenz her denke ich das eine Message zu einem schlafenden Handler-Thread in einem Micro-Kernel-OS nicht schlechter ist als das Zeugs von Windows. In Linux soll man das, meines Wissens nach, ähnlich machen aber es wird wohl nicht so strickt durchgesetzt. Man merkt dem Linux-Kernel auch in diesem Zusammenhang an das er oft in verschiedene Richtungen gewachsen ist.
Aber genau das (vor allem "im Kernel") geht bei einem echten Micro-Kernel nicht und daher möchte ich wissen wie ihr das nun gelöst habt, z.B. bei tyndur oder lightOS.

Hm, den EOI will man vermutlich so früh wie möglich schicken.

Ich hab noch mal nachgesehen, in den Windows-Driver-Design-Rules steht das der vorgelagerte IRQ-Handler den Zustand vom Device abspeichern soll (in einer passenden Datenstruktur auf die auch der DPC-Handler zugreifen kann) und dann das Interrupt-Signal im Device abschalten muss. Ich gehe davon aus das EOI am Ende vom generischen IRQ-Handler von Windows kommt. Abgearbeitet wird der Event vom Device dann vom DPC-Handler der sich die nötigen Infos aus der Datenstruktur holt. Dabei muss man aufpassen das der kleine IRQ-Handler nichts überschreibt was der große DPC-Handler eventuell braucht da der DPC-Handler ja durch den IRQ-Handler unterbrochen werden kann. Also ich persönlich empfinde dieses Konzept recht umständlich (mit shared und level triggered IRQs gehts eben nicht besser) und will daher auf meiner Plattform was grundlegend anderes (hoffentlich auch besseres). In der PCI-Spec wird ja auch ausdrücklich MSI bzw. MSI-X empfohlen und von dessen Vorteilen geschwärmt.


Grüße
Erik

[kevin]

Aber genau das (vor allem "im Kernel") geht bei einem echten Micro-Kernel nicht und daher möchte ich wissen wie ihr das nun gelöst habt, z.B. bei tyndur oder lightOS.

tyndur kann im Moment keine Interrupts sharen. Wenn ich mal davon ausgehe, dass in typischer tyndur-Manier die einfachste Möglichkeit gewählt wird, es ans Laufen zu bringen, würde das wohl einen RPC an jeden für den IRQ registrierten Treiber bedeuten. (Es gab sogar schonmal einen Patch, um das zu machen, aber der war leider kaputt. )

Bei lightOS weiß ich es nicht, aber wenn bluecode vorschlägt, das Zeug in den Kernel zu verschieben, dann vermute ich, dass er entweder kein IRQ-Sharing hat oder ihm auch nichts besseres als unsere Optionen eingefallen ist.

Ich hab noch mal nachgesehen, in den Windows-Driver-Design-Rules steht das der vorgelagerte IRQ-Handler den Zustand vom Device abspeichern soll (in einer passenden Datenstruktur auf die auch der DPC-Handler zugreifen kann) und dann das Interrupt-Signal im Device abschalten muss. Ich gehe davon aus das EOI am Ende vom generischen IRQ-Handler von Windows kommt.

Da gehört er ja auch hin.

Ohne EOI kriegst du ja auch keine anderen Interrupts mehr. Ihn nicht sofort zu senden, wäre also nicht so schlau. Mir fällt nichts gescheiteres ein als erstmal den IRQ zu maskieren bevor du den EOI sendest (also noch bevor die Treiber augerufen werden) und erst hinterher wieder zu aktivieren. Dann können wenigstens alle anderen Interrupts noch kommen. Beim Sharing müsste man dann halt warten, bis der letzte Treiber fertig ist, bevor man wieder demaskiert. Berauschend klingt das auch nicht gerade, aber geht wohl nicht besser.

[erik.vikinger]

Hallo,

tyndur kann im Moment keine Interrupts sharen.

Dann unterstützt Ihr wohl auch noch nicht allzu viele Hardware-Komponenten? Insbesondere die vielen Onboard-Controller (x-mal USB 1/USB 2/(S)ATA usw.) moderner Mainboards leben ja exzessiv vom IRQ-Sharing.

dass in typischer tyndur-Manier die einfachste Möglichkeit gewählt wird

Ist das Desing-Ziel? Da habe ich wirklich etwas Ehrfurcht wie weit Ihr damit gekommen seit. 

Ohne EOI kriegst du ja auch keine anderen Interrupts mehr. Ihn nicht sofort zu senden, wäre also nicht so schlau.

ACK
Daher möchte ich auf meiner Plattform jeden IRQ individuell behandeln und das zugehörige EOI sofort senden (in Hardware) sobald der generische IRQ-Handler vom OS losläuft, dann könnte nämlich sofort der nächste IRQ auf einer anderen CPU abgearbeitet werden (der generische IRQ-Handler vom OS soll "reentrant" sein).
Doof währe nur wenn ein Device wiederholt MSI-Messages sendet und der IRQ-Controller mehrmals den IRQ-Handler vom OS aufruft bevor der eigentliche IRQ-Signal-Handler vom Device-Treiber dran kommt, der stünde dann mehrmals in der Signal-Handler-Queue (aber so schlimm ist das bestimmt nicht).


Grüße
Erik

[kevin]

tyndur kann im Moment keine Interrupts sharen.

Dann unterstützt Ihr wohl auch noch nicht allzu viele Hardware-Komponenten? Insbesondere die vielen Onboard-Controller (x-mal USB 1/USB 2/(S)ATA usw.) moderner Mainboards leben ja exzessiv vom IRQ-Sharing.

Wer sollte auch die ganzen Treber schreiben? Aber ja, bei USB ist es uns aufgefallen, dass es vielleicht irgendwann mal ganz nützlich wäre, Sharing einzubauen. Hat halt nur noch keiner gemacht.

dass in typischer tyndur-Manier die einfachste Möglichkeit gewählt wird

Ist das Desing-Ziel? Da habe ich wirklich etwas Ehrfurcht wie weit Ihr damit gekommen seit. 

Explizites Designziel war es nicht, als ich das letzte Mal nachgeschaut habe.

Aber an vielen Stellen kommst du im OS-Dev halt nur vom Fleck, wenn du einfach mal irgendwas ans Laufen bringst und dich nach und nach vortastest. Davon abgesehen wäre es ja kein schlechtes Designziel, allles so einfach wie möglich zu halten - nur eben nicht noch einfacher.

Ich sähe auch keine echten Vorteile drin, die IRQs durch den PCI-Treiber zu leiten, insofern ist das einfache ja auch die logischste Möglichkeit.

Doof währe nur wenn ein Device wiederholt MSI-Messages sendet und der IRQ-Controller mehrmals den IRQ-Handler vom OS aufruft bevor der eigentliche IRQ-Signal-Handler vom Device-Treiber dran kommt, der stünde dann mehrmals in der Signal-Handler-Queue (aber so schlimm ist das bestimmt nicht).

Dann wird eben gequeuet. Und weiter? Ist doch nicht schlimm? Vielleicht kannst du ja für den Fall, dass mehrere Nachrichten aufgelaufen sind, dem IRQ-Handler des Treibers mehrere davon auf einmal übergeben, aber das sind wohl eher Details.

[erik.vikinger]

Hallo,

Explizites Designziel war es nicht, als ich das letzte Mal nachgeschaut habe.

Schon klar. Aus meiner Berufspraxis muss ich aber ganz ehrlich sagen das es besser ist sich erst mal mit mehreren Kollegen zusammen setzt und alle möglichen Lösungen diskutiert bis man sich auf die beste Lösung geeinigt hat, unter Berücksichtigung aller relevanten Erfordernisse zu dehnen natürlich auch eine bestimmte Deadline gehören kann die mit einer ordentlichen/besseren Lösung nicht haltbar ist. In privaten Projekten sollten aber Deadlines nicht so wichtig sein so das man auch manches etwas besser machen kann.
Wenn ich über die letzten 10 Jahre die Qualität meiner Projekte analysiere dann komme ich ganz klar zu dem Ergebnis das meine privaten Hobby-Projekte durchweg besserer Qualität sind, woran der Termindruck im Berufsleben natürlich einem erheblichen Anteil hat.

Dann wird eben gequeuet. Und weiter? Ist doch nicht schlimm?

Ist natürlich nicht schlimm. Auf SW-Ebene sollte das keine ernsten Probleme bereiten, trotzdem betrachte ich das als Fehler im Device der natürlich behoben werden sollte.

Für mein Projekt bedeutet dass das ich auf jeden Fall erst mal shared IRQs und die alten level triggered Signale verbieten werde und falls ich doch mal in die Not komme das zu unterstützen kann ich dann ein extra Device implementieren das diese alten IRQ-Signale entgegen nimmt und sie per MSI an den richtigen IRQ-Controller weiterleitet. Der zugehörige Treiber verteilt dann die IRQs auf alle angemeldeten Device-Treiber und liefert am Schluss das EOI an das extra Device. Ist zwar ne blöde Lösung aber ich denke sie wird nur die USB-Controller treffen alles andere kann üblicherweise MSI.


Grüße
Erik