Autor Thema: APIC-Konfiguration  (Gelesen 6972 mal)

rizor

  • Beiträge: 521
    • Profil anzeigen
Gespeichert
« am: 18. January 2010, 13:17 »
Hallo zusammen,

ich habe mal eine kurze Frage.
Kann man die APIC so konfigurieren, dass bestimmte IRQs nur an bestimmte CPUs geschickt werden?
Wie sieht das eigentlich aus wenn man mehrere identische Hardware hat?

Zum Beispiel.
Ein System hat mehr als eine Netzwerkkarte, bekommte jede Karte dann ihren eigenen IRQ oder teilen die sich einen?

Danke.

Gruß
rizor
Programmiertechnik:
Vermeide in Assembler zu programmieren wann immer es geht.

XanClic

  • Beiträge: 261
    • Profil anzeigen
    • github
Gespeichert
« Antwort #1 am: 18. January 2010, 14:36 »
Zitat von: rizor
Ein System hat mehr als eine Netzwerkkarte, bekommte jede Karte dann ihren eigenen IRQ oder teilen die sich einen?
Soweit ich weiß, hat IRQ-Sharing nichts mit dem Hardwaretyp zu tun. Wenn genügend IRQs vorhanden sind, dann bekommt jedes Gerät einen eigenen, wenn nicht, dann kann es auch passieren, dass eine Netzwerkkarte den gleichen IRQ wie z. B. ein USB-Controller bekommt.

Zitat von: rizor
Kann man die APIC so konfigurieren, dass bestimmte IRQs nur an bestimmte CPUs geschickt werden?
Obwohl ich mich noch nicht sehr weit damit beschäftigt habe, glaube ich das schon, nur weiß ich nicht, wie. :-D

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 18. January 2010, 17:40 »
Hallo,


Kann man die APIC so konfigurieren, dass bestimmte IRQs nur an bestimmte CPUs geschickt werden?
Soweit ich mich korrekt erinnere gibt es in den IO-APICs dafür Bitmasken o.ä. an wen ein IRQ zu senden ist. Oder der Local-APIC in der CPU selektiert welche IRQs er annimmt.

Ein System hat mehr als eine Netzwerkkarte, bekommte jede Karte dann ihren eigenen IRQ oder teilen die sich einen?
Das IRQ-Sharing hängt vom Routing der IRQ-Signal-Leitungen auf dem Mainboard ab und nicht vom Hardwaretype. Wenn zwei PCI-Karten direkt neben einander stecken ist es sehr unwahrscheinlich das sie den selben IRQ bekommen weil die 4 Leitungen so komisch verdreht von einem Slot zum nächsten geführt werden.
http://www.coreboot.org/Creating_Valid_IRQ_Tables
Bei PCI-Express ist es ähnlich nur das es in Logik in den PCI2PCI-Bridges erledigt wird und nicht per physischer Leitung.
Dem IRQ-Sharing kannst Du aus dem Weg gehen in dem Du MSI http://en.wikipedia.org/wiki/Message_Signaled_Interrupts verwendest.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #3 am: 20. January 2010, 12:12 »
Kann man die APIC so konfigurieren, dass bestimmte IRQs nur an bestimmte CPUs geschickt werden?
Soweit ich mich korrekt erinnere gibt es in den IO-APICs dafür Bitmasken o.ä. an wen ein IRQ zu senden ist. Oder der Local-APIC in der CPU selektiert welche IRQs er annimmt.
Siehe I/O APIC Spezifikation (die auf der Wikiseite verlinkt ist) in Kapitel 3.2.4 Bits 56-63 sind das Destination Field, da kommt normalerweise die LAPIC ID rein (dort ist auch was mit Logical Mode und Processor Sets beschrieben, aber was genau das ist und wie das geht weiß ich ehrlich gesagt nicht), d.h. man gibt in der I/O APIC an, wer es erhält.
Wenn ich mich ganz recht entsinne, dann braucht man aber um die L zw. I/O APIC zu initialisieren die SMP- oder ACPI-Tabellen, ohne die könnte das schwieriger werden, da (hier bin ich mir nicht sehr sicher) die IRQ-Nummern die die I/O APIC verwenden überhaupt nicht die der normalen PIC sein müssen. Aber auf jeden Fall braucht man die Tabellen um die neuen IRQs auszunutzen, die I/O APIC unterstützt ja normalerweise mehr als 16 IRQs. Und in den Tabellen steht dann zB drin, dass z.B. die PIC-Geräte - ich glaub da steht nur drin, dass PCI-Interrupt-Pin #A (der steht im PCI-Config Space des Geräts) z.B. auf 17 mappt oder sowas - auf IRQs über 16 mappen, das wird man aber dem 'Interrupt Line' Register aus dem Config Space der Geräte nicht entnehmen, denn da steht soweit ich das verstanden habe nur der IRQ unter Verwendung der PIC drin.

Zitat
Dem IRQ-Sharing kannst Du aus dem Weg gehen in dem Du MSI http://en.wikipedia.org/wiki/Message_Signaled_Interrupts verwendest.
Das ist aber ziemlich neu - sogar für mein Verständnis von neu. Außerdem: ist das überhaupt Pflicht bei PCI-Express und bei PCI-Express Geräten? Wenn ich mich recht entsinne ist das über Capabilities geregelt und die können ja schlicht und ergreifend bei Geräten fehlen, va. wird das sicherlich in keinem Emulator tun. Die andere Sache ist, wie stell ich denn überhaupt fest ob das Mainboard das kann? Über die Bridges?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 20. January 2010, 17:24 »
Hallo,


Und in den Tabellen steht dann zB drin, dass z.B. die PIC-Geräte - ich glaub da steht nur drin, dass PCI-Interrupt-Pin #A (der steht im PCI-Config Space des Geräts) z.B. auf 17 mappt oder sowas - auf IRQs über 16 mappen, das wird man aber dem 'Interrupt Line' Register aus dem Config Space der Geräte nicht entnehmen, denn da steht soweit ich das verstanden habe nur der IRQ unter Verwendung der PIC drin.
Ja, im PCI-Config-Space steht nur die klassische IRQ-Nummer drin, wird vom BIOS bei der Ressourcen-Zuteilung dort eingetragen. Der Grund warum man diese Informationen heutzutage aus Tabellen raus suchen muss ist der dass das ganze vom physischen Routing der IRQ-Leitungen auf dem Main-Board abhängt, eben welche PCI-INT-Leitung an welchem INT-Eingang vom Chipsatz angeklemmt ist. Das weiß nur der Layouter und der sagts dem BIOS-Programmierer welcher aus diesen Infos eben eine Tabelle baut die das OS dann verwerten muss.

Zitat
Dem IRQ-Sharing kannst Du aus dem Weg gehen in dem Du MSI http://en.wikipedia.org/wiki/Message_Signaled_Interrupts verwendest.
Das ist aber ziemlich neu - sogar für mein Verständnis von neu. Außerdem: ist das überhaupt Pflicht bei PCI-Express und bei PCI-Express Geräten? Wenn ich mich recht entsinne ist das über Capabilities geregelt und die können ja schlicht und ergreifend bei Geräten fehlen, va. wird das sicherlich in keinem Emulator tun. Die andere Sache ist, wie stell ich denn überhaupt fest ob das Mainboard das kann? Über die Bridges?
Das MSI-X ist von 2003, das einfache MSI müsste (glaube ich) mindestens 2 Jahre älter sein. Der Grund das es sich kaum verbreitet hat liegt darin das seit Win XP das IRQ-Sharing doch recht gut funktioniert und damit der Leidensdruck nicht mehr so deutlich da war. Außerdem stehen die klassischen IRQ-Weiterleitungsmechanismen der etablierten PC-Architektur dem MSI entgegen. MSI basiert darauf dem IRQ-Controller direkt mitzuteilen welche HW-Komponente Aufmerksamkeit benötigt, die I/O-APICs sollten das eigentlich können. MSI ist leider optional und wird daher oft nur von besseren Geräten unterstützt. Wenn ein Emulator eine HW unterstützt die MSI kann (z.B. Intel-E1000 in VMware) sollte eigentlich auch MSI funktionieren. Das tolle an MSI ist dass das Mainboard oder die PCI2PCI-Bridges dafür überhaupt nichts besonderes können müssen. Das ist eine Angelegenheit zwischen dem IRQ-Controller, welcher die MSI-Messages (simple Schreibzugriffe) entgegennehmen muss, und den PCI-Geräten. Natürlich muss der IRQ-Controller diese IRQs passend weiterleiten können aber das ist außerhalb der PCI-Spec und sollte den BIOS-Tabellen entnehmbar sein oder in irgendwelchen CPU-Initialisierungs-Guides o.ä. stehen. Auf meiner Plattform ist das Teil der Plattform-Spezifikation.


Grüße
Erik
« Letzte Änderung: 20. January 2010, 17:36 von erik.vikinger »
Reality is that which, when you stop believing in it, doesn't go away.

 

Einloggen