Thema: PCI BARs

[FlashBurn]

In einem anderem Forum geht es gerade darum ob es reicht wenn man die Adresse für Memory Mapped I/O in den BARs ändert oder ob man auch noch was in der Northbridge bzw. bei neueren CPUs in den MSRs ändern muss.

Ich dachte bisher eigentlich immer, dass das alles nur über die PCI BARs läuft? Wenn dem nicht so ist, kann ich mir den Gedanken, die PCI Geräte eventuell selbst zu initialiseren (und damit praktisch die BARs zu ändern) gleich sparen und mache mir da keine zusätzliche Arbeit.

[kevin]

Meines Wissens reicht es, die BARs zu ändern, aber praktisch habe ich das noch nicht gemacht (außer natürlich kurzzeitig, um die Größe der Region rauszufinden).

[FlashBurn]

Denke ich eigentlich auch, aber die Frage, wie der Memory-Controller das feststellt ist schon berechtigt. Weil Lese- und Schreiboperationen dürfen dann ja nicht mehr auf den Speicherbus geschickt werden.

Oder ist es sogar so, dass das PCI Gerät einfach nur den Speicher an der Stelle beobachtet? Was dagegen spricht, ist dass das alles auch funktioniert ohne das die Adressen mit Speicher hinterlegt sind.

[kevin]

Ich würde es als Aufgabe des PCI-Controllers ansehen, sich darum zu kümmern, dass die richtigen Speicherbereiche auf den Bus kommen. Wie es genau funktioniert, habe ich mir noch nicht angeschaut. Sollte aber eigentlich alles in der PCI-Spec stehen, oder?

[FlashBurn]

Das würde also heißen das der PCI Controller irgendwo zwischen dem Speicher und dem Memory Controller hören müsste. Ich weiß auch nicht in wie weit das in den Specs steht (kann gerade nicht nachgucken, da alle meine Bücher schon in Umzugskartons sind).

[erik.vikinger]

Hallo,


Die Sache mit dem Routing ist ein klein wenig komplexer. Zuerst muss mal zwischen 2 Abschnitten auf dem Weg von der CPU bis zur betreffenden Hardware-Komponente unterschieden werden:

• 1. von der CPU bis zum richtigen PCI-Root-Complex (an dem die betreffende Komponente hängt, es kann in einem Computer durchaus mehrere PCI-Root-Complexe geben)
• 2. vom Root-Complex bis zum eigentlichen PCI-Device

Der erste Abschnitt ist sehr plattformspezifisch und nicht durch die PCI-Spezifikation abgedeckt. Der zweite Abschnitt wird durch die PCI-Bridges geregelt (die übernehmen innerhalb des PCI-Systems das Routing) und natürlich durch die PCI-Spezifikation klar definiert.

Der zweite Wegabschnitt beginnt damit das der Zugriff an den betreffenden PCI-Root-Complex übergeben wird, der PCI-Root-Complex selber tritt aus PCI-Sicht nicht als Bridge in Erscheinung und hat demzufolge keine eigenen Routing-Config-Register sondern er nimmt den Zugriff und leitet ihn an seinen einen PCI-BUS weiter (beim klassischen PCI können da dran mehrere Devices und Bridges hängen und beim PCI-Express ist es immer nur ein Device also entweder eine PCI-Bridge zum Weiterverzweigen oder ein Device als End-Punkt). Diesen Zugriff des Root-Complex muss genau ein Device/Bridge entgegennehmen. Das bedeutet das wenn das eigentliche Device hinter einer der Bridges liegt dann muss die betreffende Bridge das auch wissen wozu deren Routing-Config-Register zu benutzen sind, das sind die Register 0x01C bis 0x033 im Header-Typ 0x01 http://www.lowlevel.eu/wiki/PCI#Header_Type_0x01 (von Secondary Status mal abgesehen). Wenn man eine Device-Ressource an eine neue Adresse platzieren möchte dann muss das in den Routing-Informationen aller davor befindlicher PCI-Bridges berücksichtigt werden. Da eine PCI-Bridge pro Ressourcen-Typ immer nur ein Routing-Register-Paar (Base + Limit) hat müssen alle dahinter liegenden Ressourcen in einem zusammenhängenden Adressbereich liegen. Deswegen kann man die Ressourcenzuweisung immer erst dann durchführen nachdem man den gesamten PCI-Baum komplett durchsucht hat und den Ressourcenbedarf aller PCI-Devices genau kennt. Diese Vorgänge sind nicht ganz trivial aber in der PCI-Spezifikation recht gut beschrieben.

Der erste Wegabschnitt ist anders aber doch recht ähnlich. Er dürfte über spezielle Routing-Register im Chip-Satz und den CPUs geregelt werden. Für das Hyper-Transport-Netzwerk der AMD-CPUs sind diese Routing-Mechanismen wimre recht gut dokumentiert, ich denke diese Informationen findet man auch für die Intel-Plattformen. Es bleibt aber dabei dass das sehr spezifisch ist und es extrem schwer sein dürfte dafür generische Treiber für ein OS zu bauen, diese Dinge sind im BIOS/Firmware IMHO ganz gut aufgehoben.

Das entscheidende ist aber das Ihr Euch von der BUS-Philosophie verabschieden müsst. In modernen Computern werden Zugriffe über geswitchte Netzwerke transportiert. Hypertransport und QPI (und auch PCI-Express) haben mehr mit Ethernet gemein als mit dem klassischen ISA-BUS!


Ich hoffe ich konnte etwas Klarheit bringen, wenn nicht dann ruhig noch mal nachfragen.


Grüße
Erik

[FlashBurn]

Danke erik, damit kann man also eigentlich festhalten, das aus Sicht eines Hobby-OS das Initialisieren von PCI Devices eigentlich eine sehr dumme Idee ist, weil man sich damit mehr Arbeit holt als alles andere. Denn wo soll man für alle Sachen die Dokus herbekommen und implementieren muss das dann auch noch einer.

Gibt es wenigstens eine Möglichkeit zu erfahren ob das BIOS alle PCI Devices initialisiert hat? Wie wird das ganze unter Windows gemacht? Weil ich mich nicht entsinnen kann jemeils einen richtigen Treiber für die Chipsätze installiert zu haben. Immer nur irgendwelche INF-Dateien, wo dann wahrscheinlich alles nötig drin stand (womit ein halbwegs generischer Treiber ja möglich wäre).

Wenn das so wäre, könnte man auch einfach versuchen die INF-Dateien zu parsen und sich so die nötigen Daten zu holen?!

[erik.vikinger]

Hallo,

damit kann man also eigentlich festhalten, das aus Sicht eines Hobby-OS das Initialisieren von PCI Devices eigentlich eine sehr dumme Idee ist ....

Also dieser Aussage kann ich nicht so ganz zustimmen, vor allem wenn Du mit "Initialisieren" nur das Zuteilen von Ressourcen meinst.

Gibt es wenigstens eine Möglichkeit zu erfahren ob das BIOS alle PCI Devices initialisiert hat?

Hä? Wieso sollte das BIOS irgendwelche PCI-Devices auslassen? Gerade deswegen gibt es doch diesen generischen PCI-Konfigurations-Mechanismus damit die Firmware/BIOS/sonstwas auch alle Devices mit Ressourcen versorgen kann. Es geht nicht darum das die Devices selber in Betrieb genommen werden sondern nur darum dass das OS das tun kann ohne sich um die globale Ressourcenzuweisung kümmern zu müssen. Das OS ist also in der Lage einzelne Devices zu benutzen ohne sich für andere Devices interessieren zu müssen.


Ich möchte hiermit offiziell vorschlagen das ein Wiki-Artikel "Missverständnisse und Irrtümer bei der PC-Architektur im Allgemeinen und PCI im Speziellen" erstellt wird.


Grüße
Erik


PS.:

ob es reicht wenn man die Adresse für Memory Mapped I/O in den BARs ändert

Warum sollte man überhaupt die einmal zugewiesene Adresse nachträglich ändern wollen?

[FlashBurn]

Irgendwann hatten wir das Thema doch mal, das man im BIOS auch das Ressourcenzuweisen ausstellen kann und dann das OS das überhnehmen müsste.

Ich gehe mal davon aus das Windows und Linux das können.

Mir geht es jetzt nur um das Ressourcenzuweisen und das ist ja wie du sagst sehr Hardwarespezifisch und dann bräuchte man ja für alle CPUs und Chipsätze spezielle Treiber und ich möchte mir das eigentlich nicht zumuten die alle zu schreiben und die ganzen Infos zu besorgen.

[kevin]

Ich möchte hiermit offiziell vorschlagen das ein Wiki-Artikel "Missverständnisse und Irrtümer bei der PC-Architektur im Allgemeinen und PCI im Speziellen" erstellt wird.

Gute Idee, mach mal.

Ich gehe mal davon aus das Windows und Linux das können.

Spätestens mit Hotplugging führt wohl kein Weg mehr dran vorbei, oder?

[erik.vikinger]

Hallo,

das man im BIOS auch das Ressourcenzuweisen ausstellen kann

Warum sollte man das? Wenn man das zuteilen der Ressourcen abschaltet dann gibt es auch keinen Zugriff auf die Devices und damit auch keinen Zugriff auf die Boot-Devices wie HDD usw. Ich halte es für extrem unwahrscheinlich das man auf einem x86-PC das Zuteilen der Ressourcen durch BIOS/UEFI/sonstwas unterbinden kann, so ein PC wäre nicht mehr bootfähig.

Ich gehe mal davon aus das Windows und Linux das können.

Sicher können Beide das, schon weil beide OSe auch auf Nicht-X86-System laufen können. Wenn das Zuteilen von Ressourcen nicht durch eine Firmware o.ä. durchgeführt wird dann muss das OS das übernehmen. Auf meiner Plattform soll es auch so sein das dieser Vorgang erst während des laufenden OS erledigt wird (vom pci-Service, einem Teil der User-Mode-Personality), trotzdem bleibt das ein "Alles oder Nichts"-Vorgang.

Spätestens mit Hotplugging führt wohl kein Weg mehr dran vorbei, oder?

Hotplugging ist da etwas anders. Dafür werden in den zugehörigen Bridges, welche die Schnittstelle zwischen dem fest verbauten System und dem externem System darstellen, einfach für jeden Ressourcen-Typ Bereiche mit festgelegter Größe (im BIOS von betreffenden Mein-Boards einstellbar) eingerichtet aus denen dann die hinzugekommenden Devices versorgt werden. Wenn das nicht mehr reicht dann hat das neue Device eben Pech gehabt, einer der Gründe für die Einführung von Resizable BARs. Entscheidend ist das die Ressourcen als eine Art Baum betrachtet werden müssen in dem jeder Zweig immer nur Teile seines übergeordneten Knotens belegen kann (wimre in der Baumansicht des Windows-Geräte-Managers recht anschaulich zu erkennen).


Grüße
Erik

[FlashBurn]

Wenn man das zuteilen der Ressourcen abschaltet dann gibt es auch keinen Zugriff auf die Devices und damit auch keinen Zugriff auf die Boot-Devices wie HDD usw. Ich halte es für extrem unwahrscheinlich das man auf einem x86-PC das Zuteilen der Ressourcen durch BIOS/UEFI/sonstwas unterbinden kann, so ein PC wäre nicht mehr bootfähig.

Ich erinnere mich wieder das du dich damals mit Svenska darüber unterhalten hast und guck dir mal folgenden Link an:

http://support.microsoft.com/kb/321779/de

Man kann im BIOS sagen ob man ein OS hat welches Plug&Play unterstützt und wenn das der Fall ist, initialisiert das BIOS nur die nötigen Geräte (Video, Tastatur, Boot-Medium).

Warum sollte man sowas machen?

MS geht davon aus, dass das BIOS nicht immer die optimale Konfiguration vornimmt (war vllt damals noch so, denke mal sollte heute nicht das Problem sein). Allerdings sollte man es trotzdem das BIOS machen lassen, da sonst BIOS Bugs zum Vorschein kommen (wozu dann das ganze?).

[erik.vikinger]

Hallo,

Man kann im BIOS sagen ob man ein OS hat welches Plug&Play unterstützt und wenn das der Fall ist, initialisiert das BIOS nur die nötigen Geräte (Video, Tastatur, Boot-Medium).

Von was genau schreibst Du da? Von der Ressourcenzuweisung durch generische PCI-Mechanismen oder von der Konfiguration der eigentlichen Geräte welche ja spezifisch ist? Ich glaube nicht das es ein PC-BIOS gibt das ersteres unvollständig macht (wohl noch nicht mal fehlerhaft da solche Fehler sicher ziemlich schnell auffallen müssten) aber beim zweiten kann man sicher sehr viele verschiedene Wege gehen (und auch exotische Bugs generieren).

Es ist sicher möglich das Windows oder auch Linux die Ressourcenzuweisung noch mal komplett neu macht wobei dann wirklich die Frage nach dem "Warum" berechtigt ist. Das dieser Vorgang ein "Alles oder Nichts"-Vorgang ist bleibt trotzdem bestehen, also wenn ein OS die Ressourcen-Zuteilung ändern möchte dann muss es das gesamte PCI-System komplett durchgehen. Bei der Zuweisung der Interrupts kann ich mir schon eher vorstellen das dort vom OS noch mal gedreht wird, auf Grund des IRQ-Sharings kann man ja problemlos den IRQ einer einzelnen physischen IRQ-Leitung ändern (im Chipsatz) ohne irgendetwas anderes anfassen zu müssen. Die IRQs sind auch nicht so baumartig voneinander abhängig. Auch ist es möglich das ein OS die klassischen IRQs abschaltet und komplett (oder auch nur mit einem Teil der Devices) auf MSI(-X) umsteigt um z.B. in einem System mit 8 CPUs der Netzwerkkarte 8 individuelle IRQs (die auch nicht geshared werden) zu geben.

MS geht davon aus, dass das BIOS nicht immer die optimale Konfiguration vornimmt

Auch hier muss man wieder zwischen der Ressourcen-Zuweisung (per generischer PCI-Konfiguration) und dem tatsächlichen Konfigurieren des eigentlichen Gerätes unterscheiden. Für die Verteilung der Ressourcen gibt es zwar theoretisch unendlich viele Kombinationsmöglichkeiten aber ist eine davon besser oder schlechter als die andere? IMHO nein, solange keine Fehler gemacht werden, also ist es egal wer das wie macht. Bei den eigentlichen Geräten kann es durchaus unterschiedliche Konfigurationen geben die unterschiedlich gut auf die Bedürfnisse unterschiedlicher Betriebssysteme zugeschnitten sind, ich denke das ist es was der MS-Artikel meint.


Grüße
Erik

[FlashBurn]

Ich weiß das die Bezeichnung "Plug&Play OS" sehr verwirrent gewählt ist, aber ich meine schon das Zuweisen der Ressourcen (Adressen im Speicher- und I/O-Raum).

Wenn ich in den Semesterferien die Zeit finde, werde ich mal überprüfen was das BIOS alles macht oder auch nicht, wenn man diese Option ändert.

Was das Zuweisen betrifft, klar kann man das sehr unvorteilhaft machen, z.B. indem man die Adressen so wählt das physisch vorhandender RAM verschwendet wird, aber trotzdem Lücken bleiben, wo kein RAM physisch vorhanden ist.

[FlashBurn]

Wenn ich davon ausgehe dass das BIOS alle Ressourcen zugewiesen hat, kann ich dann auch davon ausgehen, das kein PCI Gerät mehr zusammenhängenden Speicher (>4kb) braucht?

Ich frage deshalb, weil ich das ja auch bei meinem PMM einplanen muss, weil ich eigentlich nicht noch anfangen wollte das die Treiber dem PMM während der Laufzeit mitteilen müssen welchen Speicher sie für ihr Gerät beanspruchen und welcher dann ja nicht mehr als normaler Speicher rausgegeben werden darf.
Es ist halt einfacher wenn mein Bootloader den PCI Baum durchläuft und alle Geräte bzw. deren Speicher gleich in meine Memmap einträgt bzw. austrägt.

[erik.vikinger]

Hallo,

Wenn ich davon ausgehe dass das BIOS alle Ressourcen zugewiesen hat

Ich denke davon kannst Du aus gehen, egal was in den BIOS-Einstellungen konfiguriert ist.

kann ich dann auch davon ausgehen, das kein PCI Gerät mehr zusammenhängenden Speicher (>4kb) braucht?

Auf was zielt diese Frage ab?
Für Bus-Mastering können die meisten modernen PCI-Geräte mit fragmentiertem Speicher per Scatter-Gather ziemlich gut umgehen.
Für die Ressourcen eines PCI-Gerätes wird immer zusammenhängender physischer Adressraum benötigt.

Ich frage deshalb, weil ich das ja auch bei meinem PMM einplanen muss, weil ich eigentlich nicht noch anfangen wollte das die Treiber dem PMM während der Laufzeit mitteilen müssen welchen Speicher sie für ihr Gerät beanspruchen und welcher dann ja nicht mehr als normaler Speicher rausgegeben werden darf.

Den physischen Speicher der durch die Ressourcen aller PCI-Geräte belegt wird kann man beim Anlaufen des Kernels einmal statisch einlesen und fertig. Komplizierter wird das nur wenn auch Hot-Plugging unterstützt werden soll aber auch dann sind die spezial auf Vorrat gehaltenen physischen Adressräume bereits fest vergeben (sind üblicherweise den PCI-Bridges hinter welchen dann eingestöpselt werden kann zugeordnet). Da die Ressourcen ja Baumartig (jede Ebene enthält nicht nur die eigenen sondern auch alle untergeordneten Ebenen als einen zusammenhängenden Adressraum) vergeben werden müssen kann man sowas auch nicht einfach später zur Laufzeit erweitern.


Wenn meine Antwort nicht hilfreich war dann formuliere Bitte Deine Fragen etwas konkreter.


Grüße
Erik

[FlashBurn]

Deine Antwort war genau das was ich hören wollte

Mir ging es nur darum, das ich meinen PMM nicht noch so umbauen wollte, das er zur Laufzeit Bereiche von Speicher als benutzt bzw. gar nicht vorhanden markieren können muss, weil ein PCI Gerät noch Speicher für MMIO braucht. Weil es dann schwierig werden könnte z.B. zusammenhängende 64MB zu finden (zumal das mein PMM eh nicht kann).

Allerdings ist mir noch eingefallen dass das BIOS den Speicher ja schon aus SMAP rausnimmt und ich mich somit eigentlich gar nicht weiter darum kümmern muss.

Wenn du dann sogar sagst das sogar Hot-Plugging theoretisch funktionieren müsste, ist das doch top.

[erik.vikinger]

Hallo,


Ich weiß zwar nicht so ganz genau wie man auf x86 vom BIOS eine Memory-Map bekommt (das können hier andere sicher besser erklären) aber ich denke die physischen Adressräume hinter welchen sich laut dieser Memory-Map RAM verbergen soll enthalten auch nur RAM. Wenn Du nur diesen Speicher an den PMM gibst dann hat der bezüglich der Peripherie-Geräte keinerlei Extras zu berücksichtigen. Das einzigste was Du für Deine User-Mode-Treiber benötigst ist ein Map-Syscall der gezielt physischen Speicher, der gerade außerhalb des normalen RAM liegt, in den virtuellen Adressraum einblenden kann. Hierfür solltest Du das aber trotzdem etwas zentral verwalten damit nicht mehrere Treiber den selben physischen Adressraum mappen können und eventuell noch ein paar andere Sicherheitsprüfungen durchführen. Es wäre auch eine gute Idee wenn der Syscall nicht das explizite mappen von Adressräumen zulassen würde sondern wenn der Treiber sagt "ich möchte gerne das Gerät an Bus X / Device Y / Function Z haben" und der Syscall liefert dann eine Struktur zurück in der steht wie alle zugehörigen Geräte-Adressräume in den virtuellen Treiber-Adressraum eingeblendet wurden und das selbe auch für die IRQs usw., das hätte den Vorteil das die Treiber nichts vergessen und immer ganze Geräte einbinden und freigeben können und auch das Belegtmanagement auf Geräte-Ebene (eventuell mit ner simplen Bitmap) ausreichend ist.


Grüße
Erik

[FlashBurn]

Du hast fast genau das beschrieben was ich vor habe

Ich will mir ja einen Device-Server schreiben, der dann verschiedene Bus-Module hat (z.B. auf jeden Fall PCI). Diese Module wissen dann welche Geräte und welchen Ressourcen auf ihrem Bus sind und jeder Treiber läuft ja eh in seinem eigenen Prozess und bekommt auch nur genau diese Ressourcen zugewiesen, sprich er muss nicht mal unbedingt dafür anfragen (ob das dann genau so wird, bin ich mir noch nicht sicher).

Die Memory-Map zu bekommen ist kein Problem, das kann mein Bootloader schon alles. Eventuell will ich aber doch noch das Zuweisen der Ressourcen (zumindest für den PCI-Bus) selbst können und das werde ich dann wahrscheinlich im Bootloader machen (der wird auch immer mehr zu nem kleinen bzw. größeren OS) und entsprechend die Memory-Map, die der Kernel bekommt, anpassen.
So bleibt das alles transparent vom OS und ich kann dieses Feature später noch implementieren.

Um jetzt noch mal auf das BIOS und das Zuweisen der Ressourcen zu kommen. Das ist wirklich so, das es die Option gibt, dass das BIOS nicht alle Ressourcen zuweist. Denn Linux hatte damit wohl vor 2.4 auf einigen Systemen Probleme und Win9x war es wohl lieber wenn es die Ressourcen selbst zuweisen konnte.

[erik.vikinger]

Hallo,

Das ist wirklich so, das es die Option gibt, dass das BIOS nicht alle Ressourcen zuweist. Denn Linux hatte damit wohl vor 2.4 auf einigen Systemen Probleme und Win9x war es wohl lieber wenn es die Ressourcen selbst zuweisen konnte.

Also dass das BIOS nicht allen Geräten die benötigten Ressourcen zuweist kann ich mir beim besten Willen nicht vorstellen. Da die PCI-Ressourcenzuweisung ein "Alles oder Nichts"-Spiel ist könnte es passieren das sich z.B. die Speicher- oder I/O-Adressen eines USB-Host-Controllers ändern, wenn das OS die Ressourcen neu vergibt, und das würde u.a. einer Legacy-Emulation durch das BIOS den Boden unter den Füßen wegziehen. Insbesondere Win9X traue ich das nicht zu da gerade dort auch noch die Möglichkeit besteht auf Block-Devices per INT13h zuzugreifen, was ja nicht mehr funktionieren würde wenn die zugehörige Hardware plötzlich an einer anderen physischen Adresse liegt.

Mir fallen da noch eine Menge weiterer (Kompatibilitäts-)Probleme ein die auftreten würden wenn das OS die Ressourcen neu vergeben würde, dass das tatsächlich gemacht wird kann ich so einfach nicht glauben.


Grüße
Erik