Thema: Treiber bei einem Mikrokernel

[Svenska]

*seufz*

Sagen wir es mal so, wenn dein Hardwaretreiber die Hardware wirklich ansprechen möchte - und da mag es durchaus sein, dass die zu verwendenden Ressourcen eben nicht frei programmierbar sind - dann muss der Treiber in der Lage sein, einen bestimmten physischen Bereich mappen zu können. Dass er das kann, unterscheidet ihn von einem Userspace-Prozess.

Angenommen, für jede Hardware gibt es einen Treiber, dann ist jeder von einer Hardware genutzter physischer Speicher durch irgendeinen Treiber belegt. Wenn du also auf Doppelbelegungen prüfst, dann kann der Treiber schonmal per se nicht auf fremde Hardwareressourcen zugreifen - also keine Sicherheitslücke.

Wenn aber jedes Programm (oder auch jeder Treiber) jederzeit nachschauen kann, wo im physischen Speicher irgendwelche Systemteile rumliegen, dann kann er diese auch überschreiben. Das ist wiederum eine Sicherheitslücke. Oder andersrum: Es gibt Exploits für Netzwerkkartentreiber (Angriff via Netzwerk, also von remote), um Code im Kernelmodus zur Ausführung zu bringen. Basiert aber darauf, dass der (gehackte) Netzwerkkartentreiber die physischen Adressen des Kernels kennt und per DMA überschreiben lässt. (Im speziellen Falle irgendwie 4-16 Bytes je nach Zusammensetzung des Pakets und daher recht umständlich, aber geht.) Das Mapping von physisch nach irgendwo ist also zuviel Information und wird ohnehin nicht gebraucht.

Die Ressourcen, die ein Treiber möchte, sollte man ihm schon geben können, wenn sie denn noch frei sind - denn der Treiber muss ja wissen, welche Ressourcen die Hardware nun gern hätte. Genau diese Information möchtest du aber dem Bussystem entnehmen. Ich glaube nicht, dass das in jedem Fall funktioniert. (Bspw. sind manche Hersteller dafür bekannt, im PCI-Konfigspace komisches Zeugs stehen zu haben, was da nicht unbedingt hingehört.) Andererseits gibt es wieder Silicon Bugs, um die der Treiber evtl. herumarbeiten muss.

Wenn dein RAM fragmentiert ist, hast du halt Pech. Die Einstellung bleibt. Du könntest ihn dann höchstens defragmentieren - da die physischen Adressen ja im Userspace nicht vorhanden sind, reicht ein bisschen MMU-Guruguru. Im Zweifelsfall machst du, wenn das nicht geht, dein DMA halt nur mit 4K-Blöcken oder PIO als Rückfallstrategie. Das Problem ist das gleiche, wie RAM voll mit nicht-auslagerungsfähigem Speicher. Da kann man irgendwann nichts mehr tun.

Dein Ansatz, bei fragmentiertem physischem Speicher einfach die DMA-Zugriffe zu verteilen und dann virtuell einen zusätzlichen linearen Cache anzulegen, bringt wenig. Die Anwendungen müssen die Daten ohnehin im Block kriegen, da ist es auch einfach sinnvoller, es gleich im physischen Block zu reservieren und das zu übergeben. Sparst du dir einmal das Kopieren der Daten. Alternative: Ich habe nicht verstanden, was du meintest.

Ich denke, die einfachste Variante ist es, in jedem Treiber eine Rückfallstrategie zu haben. Das kann PIO sein, das kann aber auch einfach eine minimale Blockgröße von 4K sein. Oder aber - bei nichtkritischen Treibern - geht es dann einfach nicht. Wenn deine Webcam die Daten in ein System pumpt, was eh schon soweit hinüber ist, dass nichts mehr so recht geht, dann wird das auch bröckchenweise nicht unbedingt besser. Außerdem musst du deine Speicherverwaltung schon hinreichend verkorkst haben, dass du physisch jede zweite Page belegt hast und die dazwischen nicht. Die Wahrscheinlichkeit geht gegen null - das ist das gleiche wie mit Deadlocks. Eine sinnvolle Strategie ist den Kopf in den Sand zu stecken und zu sagen "passiert nicht - und wenn doch: Pech". Dann muss der User halt mal was ändern.

@taljeth: Und meine.

Gruß

[FlashBurn]

Wenn aber jedes Programm (oder auch jeder Treiber) jederzeit nachschauen kann, wo im physischen  Speicher irgendwelche Systemteile rumliegen, dann kann er diese auch überschreiben. Das ist wiederum eine Sicherheitslücke. Oder andersrum: Es gibt Exploits für Netzwerkkartentreiber (Angriff via Netzwerk, also von remote), um Code im Kernelmodus zur Ausführung zu bringen. Basiert aber darauf, dass der (gehackte) Netzwerkkartentreiber die physischen Adressen des Kernels kennt und per DMA überschreiben lässt. (Im speziellen Falle irgendwie 4-16 Bytes je nach Zusammensetzung des Pakets und daher recht umständlich, aber geht.) Das Mapping von physisch nach irgendwo ist also zuviel Information und wird ohnehin nicht gebraucht.

Nur um dem nochmal was entgegen zu setzen

Ich bi mir nicht sicher (und zu faul nachzugucken) ob ich es nicht schonmal erwähnt habe, aber ich würde dem Treiber nur gestatten die PTs zu parsen die den UserSpace betreffen. Somit kann er auch nicht in den KernelSpace gucken, aber das ist doch logisch!

Die Ressourcen, die ein Treiber möchte, sollte man ihm schon geben können, wenn sie denn noch frei sind - denn der Treiber muss ja wissen, welche Ressourcen die Hardware nun gern hätte. Genau diese Information möchtest du aber dem Bussystem entnehmen. Ich glaube nicht, dass das in jedem Fall funktioniert. (Bspw. sind manche Hersteller dafür bekannt, im PCI-Konfigspace komisches Zeugs stehen zu haben, was da nicht unbedingt hingehört.) Andererseits gibt es wieder Silicon Bugs, um die der Treiber evtl. herumarbeiten muss.

Also erstens, wenn er die Daten nicht aus dem PCI ConfigSpace bekommt wo soll er seine Adressen sonst herbekommen? Und das nächste Problem ist, was passiert wenn der Speicher den der Treiber (angeblich) will mit physischen RAM hinterlegt ist? Selbst wenn der Speicher gerade nicht in Benutzung ist, finde ich das doch eher problematisch.
Aber im Endeffekt ist es natürlich egal, selbst wenn man ihm die Ressourcen zuweist, kann er das System durch DMA zum Absturz bringen.

Dein Ansatz, bei fragmentiertem physischem Speicher einfach die DMA-Zugriffe zu verteilen und dann virtuell einen zusätzlichen linearen Cache anzulegen, bringt wenig. Die Anwendungen müssen die Daten ohnehin im Block kriegen, da ist es auch einfach sinnvoller, es gleich im physischen Block zu reservieren und das zu übergeben. Sparst du dir einmal das Kopieren der Daten. Alternative: Ich habe nicht verstanden, was du meintest.

Da hast du mich tatsächlich nicht verstanden. Ich meine das genau anders herum. Ich meinte das du einen Cache (mit zusammenhängendem Speicher) anlegst und dort per DMA reinschreiben lässt und dann in neuen (nicht zusammenhängenden Speicher) Speicher kopierst.
Aber wenn ich mir das Kopieren ersparen will (ich bin immernoch der Meinung dass das gerade beim Laden von langsamen optischen Speichern nicht wirklich was ausmacht) dann wird halt einfach in 4KB Blöcken geladen.

Außerdem musst du deine Speicherverwaltung schon hinreichend verkorkst haben, dass du physisch jede zweite Page belegt hast und die dazwischen nicht.

Wie kommst du darauf? Wenn du weißt wie ein Speichermanager funktioniert, dann kannst du die Situation bestimmt herbei führen. Ich sag mal so, so viel Speicher wie möglich anfordern und dann jede 2. Page wieder freigeben, sollte nicht das Problem sein und wenn das dann auch noch direkt nach dem Booten passiert, sollte die Wahrscheinlichkeit nicht schlecht sein, das du zusammenhängenden Speicher bekommst.

Dann muss der User halt mal was ändern.

Genau da liegt ja das Problem, der kann nichts ändern, das muss der Programmierer machen. Was willst du als User denn machen wenn irgendein Programmierer bei einem Treiber geschludert hat und dein System ständig zum Absturz bringt?

[erik.vikinger]

Hallo,


Worüber streitet Ihr eigentlich?
Es gibt bei halbwegs moderner Hardware absolut keine Notwendigkeit physischen Speicher zusammenhängend zu allozieren! Heutzutage gibt es das Zauberwort "Scatter/Gather", das seit Jahren jeder Hersteller von irgendwelcher PCI-Hardware in die Prospekte schreibt (in letzter Zeit hat das wieder nachgelassen weil langsam alle wissen dass das jeder kann).

LAN-Controller, USB-Host-Controller und AHCI-Controller können die Daten in kleinen, verteilten und unausgerichteten Häppchen quer über den RAM völlig problemlos zusammensuchen. Für Floppy-Controller, die auf einen ISA-DMA-Mechanismus angewiesen sind (der älter ist als ich), gilt das leider nicht aber ansonsten sehe ich da keine Probleme. Die überwiegende Mehrheit der Hardware kann sogar mit 64 Bit-Adressen umgehen so das es eigentlich keine Notwendigkeit gibt zur Kommunikation mit der Hardware bestimmte physische Speicherbereiche zu benutzen. Für Floppys, als einzige Ausnahme die (in noch nicht ganz verrosteten PCs) überhaupt noch existiert, könnte man ja beim booten einen Zwischenpuffer in den ersten 16MByte reservieren (64kBytes sollten reichen) der dann vom Treiber benutzt wird um darin die ISA-DMA-Aktivitäten zu fahren und die Daten händisch umzukopieren. Alle andere Hardware kann direkt mit den physischen Pages der User-Mode-Programme arbeiten, egal wie zerstreut die auch sind.

Virtuelle Adressen sind das, was das Programm sieht und bestehen aus einem Segment und Offset. An dieser Stelle haben wir die erste Übersetzung. Nachdem die Segmentierung erledigt ist, landen wir bei linearen Adressen. Und diese linearen Adressen wiederum werden mit Paging auf physische Adressen abgebildet.

mit Flat Memory ist virtuell und linear dasselbe.

Fürs Protokoll, beide Aussage sind absolut korrekt. Jegliche Form von Zweifel ist verboten!

Dafür sind meine Beiträge wenigstens kürzer als Eriks.

Was soll denn das Bitte heißen?


Grüße
Erik

[Programm Noob]

Erik deine Beiträge sind leider sehr lang sind dafür aber auch sehr leicht zu verstehen. Das gleiche gilt übrigens auch für die Beträge von Flashburn.

Programm Noob

[kevin]

Dafür sind meine Beiträge wenigstens kürzer als Eriks.

Was soll denn das Bitte heißen?

Im Zweifelsfall, dass ich tippfaul bin.

[Svenska]

Also erstens, wenn er die Daten nicht aus dem PCI ConfigSpace bekommt wo soll er seine Adressen sonst herbekommen? Und das nächste Problem ist, was passiert wenn der Speicher den der Treiber (angeblich) will mit physischen RAM hinterlegt ist? Selbst wenn der Speicher gerade nicht in Benutzung ist, finde ich das doch eher problematisch.

Wenn der Treiber Bereiche mit physischem RAM will, dann will er die vielleicht, um Daten auszutauschen. Und wenn er die Daten nicht aus dem PCI ConfigSpace bekommt, dann vielleicht aus der Dokumentation des Prozessors (z.B. Samsung S3C2410) - tut mir Leid, wenn ich darauf rumhacke, aber ich denke halt bissl weiter als nur PC-Plattform. Die finde ich inzwischen komplett überholt, mitsamt x86...

Aber im Endeffekt ist es natürlich egal, selbst wenn man ihm die Ressourcen zuweist, kann er das System durch DMA zum Absturz bringen.

Ja, aber gezielte Codeausführung durch Bugs/Angriffe im Kernel wird dadurch erschwert.

Da hast du mich tatsächlich nicht verstanden. Ich meine das genau anders herum. Ich meinte das du einen Cache (mit zusammenhängendem Speicher) anlegst und dort per DMA reinschreiben lässt und dann in neuen (nicht zusammenhängenden Speicher) Speicher kopierst.

Das ist doch der physisch zusammenhängende Speicherblock. Davon rede ich die ganze Zeit.

Außerdem musst du deine Speicherverwaltung schon hinreichend verkorkst haben, dass du physisch jede zweite Page belegt hast und die dazwischen nicht.

Wie kommst du darauf? Wenn du weißt wie ein Speichermanager funktioniert, dann kannst du die Situation bestimmt herbei führen. Ich sag mal so, so viel Speicher wie möglich anfordern und dann jede 2. Page wieder freigeben, sollte nicht das Problem sein und wenn das dann auch noch direkt nach dem Booten passiert, sollte die Wahrscheinlichkeit nicht schlecht sein, das du zusammenhängenden Speicher bekommst.

Es geht hier nicht um Speicher - es geht um physischen Speicher. Auf den hat eine Anwendung keinen Einfluss und auch keinen Zugriff, sollte im Normalfall nichtmal in der Lage sein, solche Adressen zu erhalten! Treiber sollten hingegen mit entsprechenden Privilegien ausgestattet sein, sodaß diese mit höherer Wahrscheinlichkeit eben nicht mit den getPhysMem-Funktionen spielen.

Als Anwendung den physischen Speichermanager so durcheinander bringen sollte nicht (oder nur sehr schwer) möglich sein.

Dann muss der User halt mal was ändern.

Genau da liegt ja das Problem, der kann nichts ändern, das muss der Programmierer machen. Was willst du als User denn machen wenn irgendein Programmierer bei einem Treiber geschludert hat und dein System ständig zum Absturz bringt?

Neues Gerät kaufen? Ist doch bei Windows genauso. Noch nie irgendwelche kaputten Treiber gehabt? Ich denke da an diverse DVB-C-Karten, die unter verschiedensten Umständen segfaulen/bluescreenen.

Außerdem ging es nicht um Systemabsturz durch geschluderte Treiber. Ich meinte an der Stelle, dass, wenn jede physische zweite Speicherseite belegt ist - aus welchen Gründen auch immer - der User halt mal ein paar Anwendungen schließen muss. Ich behaupte, dass menschenverstandsgeschriebene Treiber nicht solche verkorksten Dinge tun. Die sollen die Hardware ansteuern und ne API bereitstellen und mehr nicht.

Gruß

[FlashBurn]

Und wenn er die Daten nicht aus dem PCI ConfigSpace bekommt, dann vielleicht aus der Dokumentation des Prozessors (z.B. Samsung S3C2410)

Wenn der die Daten nicht von dort bekommt, dann kannst du das Gerät wegwerfen Denn du wirst dann keine Probleme haben einen PC zu finden der mit diesem Gerät nicht funktioniert. Bei PCI Geräten sollten fixe Adressen eigentlich Vergangenheit sein.

- tut mir Leid, wenn ich darauf rumhacke, aber ich denke halt bissl weiter als nur PC-Plattform. Die finde ich inzwischen komplett überholt, mitsamt x86...

Sorry, wenn ich das mal so sage, wird von Assembler auch schon seit Jahrzenten behauptet und es wird immernoch benutzt. Dazu kommt, das wir hier (wenn nicht extra genannt) von x86 ausgehen.

Es geht hier nicht um Speicher - es geht um physischen Speicher. Auf den hat eine Anwendung keinen Einfluss und auch keinen Zugriff, sollte im Normalfall nichtmal in der Lage sein, solche Adressen zu erhalten! Treiber sollten hingegen mit entsprechenden Privilegien ausgestattet sein, sodaß diese mit höherer Wahrscheinlichkeit eben nicht mit den getPhysMem-Funktionen spielen.

Du willst mir also erzählen das dein PMM irgendwelche zufällig ausgewählten Seiten herausgibt? Wenn auf meinen OS nur eine Anwendung läuft und so viel wie möglich Speicher anfordert, dann kannst du davon ausgehen, das der so ziemlich zusamenhängend rausgegeben wird und das ist kein Bug, das ist nunmal so, kurz nach dem Start.

Ich meinte an der Stelle, dass, wenn jede physische zweite Speicherseite belegt ist - aus welchen Gründen auch immer - der User halt mal ein paar Anwendungen schließen muss.

Genau da wiederspreche ich dir Es kann doch nicht sein, das wenn ich 1GB RAM frei habe, dass ich ne Meldung bekomme "nicht genügend Speicher". Da läuft dann wirklich was schief!

Es gibt bei halbwegs moderner Hardware absolut keine Notwendigkeit physischen Speicher zusammenhängend zu allozieren! Heutzutage gibt es das Zauberwort "Scatter/Gather", das seit Jahren jeder Hersteller von irgendwelcher PCI-Hardware in die Prospekte schreibt (in letzter Zeit hat das wieder nachgelassen weil langsam alle wissen dass das jeder kann).

Auf der einen Seite gut, nur blöd das ich auch alte Hardware unterstütze

Also um es festzuhalten, zusammenhängenden physischen Speicher braucht man nicht unbedingt.

Und ich gehe mal davon aus, wenn der Treiber nur die PTs von seinem UserSpace sieht, sollte das auch kein Problem darstellen!?

Edit::

tut mir Leid, wenn ich darauf rumhacke, aber ich denke halt bissl weiter als nur PC-Plattform. Die finde ich inzwischen komplett überholt, mitsamt x86...

Was mir noch eingefallen ist, ich denke du denkst noch zu sehr "Linux"

Wenn du von festen Adressen ausgehst, die der Treiber entweder durch ausprobieren rausbekommt oder die man beim Kompilieren festgelegt hat, was bringt dir das?
Als Bsp. mal die ganzen ARM-Boards, es ist immer die selbe CPU und viele zusätzliche Geräte sind auch gleich, aber die MMIO Adressen sind anders, d.h. bei Linux, für jedes Board muss der Kernel/Treiber neu komiliert werden, nur weil ein paar andere Geräte und ein paar andere Adressen vorhanden sind?! Was bitte soll das, das ist in meinen Augen unfug und alles anders als modern!
Ich habe meinen Device-Server auch im Hinblick auf solche ARM-Boards geplant, nämlich das der Treiber die Ressourcen zugewiesen bekommt. Was ich damit erreichen möchte ist, dass du für jedes neue Board nicht den Kernel oder den Treiber neu kompilieren musst, sondern das du einfach nur ein Skript änderst wo alle Geräte und Adressen (für das jeweilige Board) drin stehen. So kann ich einfach mein OS nehmen, ohne es neu kompilieren zu müssen und kann durch ne kleine Änderung an einem Skript mein OS auf nem neuen Board lauffähig machen. Das nenn ich vernünftig, modern und im Hinblick auf andere Architekturen entwickelt!

[Svenska]

Bei PCI Geräten sollten fixe Adressen eigentlich Vergangenheit sein.

Bei PCI-Geräten.

Ich meinte an der Stelle, dass, wenn jede physische zweite Speicherseite belegt ist - aus welchen Gründen auch immer - der User halt mal ein paar Anwendungen schließen muss.

Genau da wiederspreche ich dir Es kann doch nicht sein, das wenn ich 1GB RAM frei habe, dass ich ne Meldung bekomme "nicht genügend Speicher". Da läuft dann wirklich was schief!

Ich will dich sehen, wie du es in einer Anwendung (nicht Treiber!) hinkriegst, jede zweite physische Speicherseite zu belegen. Im virtuellen Adressraum spielt das schließlich überhaupt keine Rolle.

Also um es festzuhalten, zusammenhängenden physischen Speicher braucht man nicht unbedingt.

Wenn du damit zufrieden bist, dass du damit keine DMA-Zugriffe jenseits der 4K mehr garantieren kannst, dann stimmt das. Ich behaupte, es gibt Hardware, die größere DMA-Zugriffe braucht. (Und sei es die Netzwerkkarte, die einen 8K Jumbo-Frame wegspeichern will.)

Aber du magst mir nicht glauben.

Wenn du von festen Adressen ausgehst, die der Treiber entweder durch ausprobieren rausbekommt oder die man beim Kompilieren festgelegt hat, was bringt dir das?

Es gibt nunmal Geräte mit festen Adressen. Dazu gehören ISA-Geräte, aber auch CPU-interne Geräte. Fertig.

Als Bsp. mal die ganzen ARM-Boards, es ist immer die selbe CPU und viele zusätzliche Geräte sind auch gleich, aber die MMIO Adressen sind anders, d.h. bei Linux, für jedes Board muss der Kernel/Treiber neu komiliert werden, nur weil ein paar andere Geräte und ein paar andere Adressen vorhanden sind?! Was bitte soll das, das ist in meinen Augen unfug und alles anders als modern!

Wenn man jetzt die ganzen Bussysteme abstrahiert (und ich sehe MMIOs nunmal als Bussystem), dann kannst du das auch komplett dynamisch machen. Der Kernel bootet, sieht "oh, ich laufe auf einem Quanta IL1, also finde ich ab Adresse 0xblubber die GPIOs für das WLAN" und bindest das halt dynamisch an den Treiber an.

Was du prinzipiell vergisst, ist, dass du bei Geräten mit Spezialzweck (z.B. Navis) nur eine Serie hast, die du zuschneiden kannst. Das Problem ist bei MIPS noch viel schlimmer, aber grundsätzlich musst du manchmal proben (oder dich auf Tabellen verlassen), eben weil nicht jedes Bussystem auch einen Devicetree erzeugen kann!

Ich habe meinen Device-Server auch im Hinblick auf solche ARM-Boards geplant, nämlich das der Treiber die Ressourcen zugewiesen bekommt.

Ist ja auch vernünftig, zumindest für den Teil, der ohnehin fix (z.B. vom Bussystem her) ist.
Der Buffer für Netzwerkkarten ist jedoch dem System nicht unbedingt bekannt und/oder unterliegt Restriktionen der Hardware und/oder kann bei mehr RAM größer & effizienter gestaltet werden. Diese Entscheidung kann dein Device-Server nicht für jede Hardware optimal treffen, da er ja die Hardware nicht kennt. Er kennt höchstens das, was das Bussystem weiß.

Der Treiber weiß mehr. Und kann die Hardware an irgendwelche Begrenzungen anpassen.

Was ich damit erreichen möchte ist, dass du für jedes neue Board nicht den Kernel oder den Treiber neu kompilieren musst, sondern das du einfach nur ein Skript änderst wo alle Geräte und Adressen (für das jeweilige Board) drin stehen.

Also abstrahierst du das Bussystem. Einfache Systeme kennen keine Devicetrees, also musst du in der Lage sein, einen Treiber auch nachträglich zu laden - und ihm mitzugeben, wo er das Gerät findet. Solche Geräte, die nicht bereits initialisiert wurden (das betrifft beim PC z.B. auch sekundäre Grafikkarten, die nicht gebootet wurden!), müssen vom Treiber initialisiert werden - nicht vom Device-Server - und das betrifft insbesondere auch die Datenkommunikation mit dem Gerät.

So kann ich einfach mein OS nehmen, ohne es neu kompilieren zu müssen und kann durch ne kleine Änderung an einem Skript mein OS auf nem neuen Board lauffähig machen. Das nenn ich vernünftig, modern und im Hinblick auf andere Architekturen entwickelt!

Guck dir mal NetBSD an. Dort kannst du sämtliche Ressourcen im Bootloader angeben, sofern sie fix sind, und alles, was sich dynamisch ermitteln lässt, wird ermittelt. Und man kann dynamisch Geräte an Busse binden.

Warum ich mit Linux vergleiche, ist, dass ich Linux teilweise auf anderen Architekturen begutachte, wenn auch nicht viel, und weil Linux nunmal mehr Embedded-Bussysteme abstrahiert, wenn auch bei weitem nicht so schön wie NetBSD. Letztere kommen einfach nicht hinterher, so meine Einschätzung.

Aber ich schreibe wahrscheinlich eh gegen ne Wand.

Gruß

[FlashBurn]

Ich will dich sehen, wie du es in einer Anwendung (nicht Treiber!) hinkriegst, jede zweite physische Speicherseite zu belegen. Im virtuellen Adressraum spielt das schließlich überhaupt keine Rolle.

Hab ich dir doch geschrieben, wenn du bei meinem (ich weiß nicht wie das andere OSs machen) als Anwendung direkt nach dem Booten, wo der Speicher noch nicht fragmentiert ist, den ganzen physischen Speicher mappst. Dann kannst du davon ausgehen, das ein Großteil davon zusammenhängend ist. Einfach weil der PMM den Speicher so rausgibt. Ich suche ja die erste freie Page und wenn du aufeinanderfolgend dann ist der Speicher der rausgegeben wird halt zusammenhängend.

Wenn du damit zufrieden bist, dass du damit keine DMA-Zugriffe jenseits der 4K mehr garantieren kannst, dann stimmt das. Ich behaupte, es gibt Hardware, die größere DMA-Zugriffe braucht. (Und sei es die Netzwerkkarte, die einen 8K Jumbo-Frame wegspeichern will.)

Ich habe ja auch geschrieben "nicht unbedingt". Soll heißen, wenn ein Treiber das unbedingt benötigt, muss er sich bei der Initialisierung einen Cache anlegen der die Bedingungen erfüllt.

Aber du magst mir nicht glauben.

Ich sags mal so, ich lasse mich gerne eines besseren belehren, aber dann möchte ich das auch schwarz auf weiß

Es gibt nunmal Geräte mit festen Adressen. Dazu gehören ISA-Geräte, aber auch CPU-interne Geräte. Fertig.

Ich bin mir jetzt nicht sicher, aber gab es MMIO schon zu ISA Zeiten? Das einzige was da war, war doch das "Loch" zw. 15MB und 16MB oder?
Selbst wenn, dann kann ich da doch trotzdem in ein Skript eintragen und dem Treiber zuweisen.

Was du prinzipiell vergisst, ist, dass du bei Geräten mit Spezialzweck (z.B. Navis) nur eine Serie hast, die du zuschneiden kannst. Das Problem ist bei MIPS noch viel schlimmer, aber grundsätzlich musst du manchmal proben (oder dich auf Tabellen verlassen), eben weil nicht jedes Bussystem auch einen Devicetree erzeugen kann!

Ich kann dir nur das gleiche sagen, was ich auch schonmal erik gesagt habe, ich (und ich denke die Mehrheit der Anderen auch) schreibe ein "normales" (á la Windows/Haiku) OS und kein OS für irgendwelche Spezialhardware (wie z.B. ein Navi) und dann kommt noch hinzu das ich mich fürs erste auf die (veraltete) x86 Architektur beschränke und selbst wenn es mal soweit kommen sollte, wird wahrscheinlich "nur" ARM hinzukommen.
Selbst dann lässt sich das wunderbar mit einem Skript lösen und den Devicetree brauch ich doch gar nicht, genau deswegen will ich doch ein Skript haben.

Der Buffer für Netzwerkkarten ist jedoch dem System nicht unbedingt bekannt und/oder unterliegt Restriktionen der Hardware und/oder kann bei mehr RAM größer & effizienter gestaltet werden.

Hier würde ich halt auch gerne mal ne Quelle, wie eine Dokumentations sehen wollen. Denn an und für sich, müssten alle (und ich meine wirklich alle) vom Gerät verwendeten Ressourcen im PCI-ConfigSpace (ISA ist mal außen vor) stehen.
Ich habe mich mit Netzwerktreibern noch nicht wirklich beschäftigt, aber hat die Netzwerkkarte wirklich einen Buffer, den sie selbst zur Verfügung stellt und der nicht im PCI-ConfigSpace steht?

Also abstrahierst du das Bussystem. Einfache Systeme kennen keine Devicetrees, also musst du in der Lage sein, einen Treiber auch nachträglich zu laden - und ihm mitzugeben, wo er das Gerät findet. Solche Geräte, die nicht bereits initialisiert wurden (das betrifft beim PC z.B. auch sekundäre Grafikkarten, die nicht gebootet wurden!), müssen vom Treiber initialisiert werden - nicht vom Device-Server - und das betrifft insbesondere auch die Datenkommunikation mit dem Gerät.

Kann sein das ich hier einfach noch mit Unwissenheit glänze, aber sollte (um dein Bsp. aufzugreifen) nicht die 2. Graka auch bei der PCI Enumeration gefunden werden und somit sind ihre Ressourcen bekannt? Zumal was hat das Initialisieren mit den Ressourcen zu tun?

Ich gehe jetzt davon aus, das man entweder eine Möglichkeit hat, alle Geräte dynamisch zu "parsen" oder das alle Geräte, samt Ressourcen, vorher bekannt sind.
Wenn ich diese beiden Möglichkeiten betrachte reicht meine Skript Variante vollkommen aus. Selbst wenn der Treiber erst nachgucken (also proben) müsste ob ein Gerät vorhanden ist, dann könnte man diesen (den Treiber) mit allen möglichen Ressourcen doch in dem Skript eintragen.

Aber ich schreibe wahrscheinlich eh gegen ne Wand.

Wenn deine Argumente überzeugend sind, dann nicht

[erik.vikinger]

Hallo,

Also um es festzuhalten, zusammenhängenden physischen Speicher braucht man nicht unbedingt.

Genau!

Ich behaupte, es gibt Hardware, die größere DMA-Zugriffe braucht. (Und sei es die Netzwerkkarte, die einen 8K Jumbo-Frame wegspeichern will.)

Sehr viele Hardware benötigt größere Puffer aber die müssen eben nicht an einem Stück im physischen Speicher liegen. Ein Netzwerkkarte die wirklich Jumbo-Frames kann kann garantiert auch "Scatter/Gather", das heißt das empfangene Ethernet-Frame kann in einem aber auch in sehr vielen und sehr verteilten und unterschiedlich großen Häppchen über den physischen Speicher verstreut sein. Wer das nicht glaubt sollte sich mal die Datenblätter handelsüblicher Ethernet-Controller der letzten 15 Jahre ansehen. Oder die AHCI-Spezifikation und die EHCI-Spezifikation lesen. Keine dieser Hardware-Komponenten benötigt die Puffer (aus denen die Nutzdaten gelesen oder geschrieben werden) an einem Stück. Ein 512 Byte Sektor für ne Platte kann der AHCI-Controller auch in unausgerichteten 3 Byte Häppchen zusammensuchen (dass das nicht gerade performant ist ist jetzt mal unerheblich). Die Hardware-Entwickler wissen schließlich das übliche OSe Flat-Memory mit Paging benutzen und berücksichtigen das in ihrer Hardware.

aber hat die Netzwerkkarte wirklich einen Buffer, den sie selbst zur Verfügung stellt und der nicht im PCI-ConfigSpace steht?

Nein, der Puffer den der Netzwerk-Controller intern hat ist entweder selbst verwaltet (simpler FIFO) und nicht nach außen sichtbar (und ihm kann demzufolge auch nicht per BAR eine physische Adresse zugewiesen werden) oder er wird von der SW verwaltet und ist von außen sichtbar (und dann muss er auch per BAR eingerichtet werden können). Heutige PCI(-Express) Netzwerk-Controller fallen in die erste Kategorie, ist in den Datenblättern nachzulesen.

aber sollte (um dein Bsp. aufzugreifen) nicht die 2. Graka auch bei der PCI Enumeration gefunden werden und somit sind ihre Ressourcen bekannt?

Auf einem üblichen PC sollte das BIOS jeder PCI-Hardware die gewünschten Ressourcen zuweisen.

Zumal was hat das Initialisieren mit den Ressourcen zu tun?

Erst mal nichts, die Ressourcen werden vom BIOS zugewiesen und initialisiert wird das Gerät später vom Treiber (wenn das OS diesen lädt). Extra deswegen hat man den standardisierten Config-Space erfunden damit ein generisches BIOS auch einem ihm völlig unbekannten Gerät passende Ressourcen zuweisen kann und dieses Gerät somit von seinem Treiber initialisiert werden kann ohne das dieser sich um die Ressourcen-Zuweisung kümmern muss.

Ich gehe jetzt davon aus, das man entweder eine Möglichkeit hat, alle Geräte dynamisch zu "parsen" oder das alle Geräte, samt Ressourcen, vorher bekannt sind.

Ich denke mal das sollte auf jede Hardware zutreffen, was anderes kann ich mir jedenfalls nicht vorstellen (proben ist eigentlich ausgestorben).


Grüße
Erik


PS.: Ihr streitet Euch um nichts!

[FlashBurn]

PS.: Ihr streitet Euch um nichts!

Bis einer weint

die Ressourcen werden vom BIOS zugewiesen

Jein! Du kannst das im BIOS auch ausstellen (die Option heißt meistens "is a Plug&Play OS available") und dann müsste das vom OS gemacht werden, aber das wäre wirklich schlecht. Denn das würde einige Schwierigkeiten bedeuten (aber erst wenn soviel RAM vorhanden ist, das welcher davon von MMIO benutzt werden muss).

Was das "Proben" betrifft, wird von meinem OS dann einfach nicht unterstützt (ein paar Altlasten kann ich schon über Bord werfen).

Was mir aber noch nicht beantwortet wurde, gab es schon zu ISA Zeiten MMIO? War dafür nicht die Lücke im RAM zw 15MB und 16MB?

[erik.vikinger]

Hallo,

Jein! Du kannst das im BIOS auch ausstellen (die Option heißt meistens "is a Plug&Play OS available") und dann müsste das vom OS gemacht werden

Ich hätte gedacht das dies nur die ISA-PnP-Karten betrifft. Da das BIOS auf jeden Fall den HDD-Controller und die Graphikkarte in betrieb nehmen muss (und auch noch USB und ne reihe anderes Zeug) muss es eigentlich die Ressourcen-Zuweisung eh erledigen, die kann man nämlich nicht in mehreren Etappen ausführen (wegen den Bridges u.ä.). Ich persönlich hab es jedenfalls noch nie erlebt dass das BIOS nicht jeder (funktionierenden) PCI-Karte die Ressourcen zugewiesen hätte. Das einzigste was das OS später noch mal ändern kann sind die IRQ-Zuweisungen, wenn z.B. in den APIC-Mode gewechselt wird und mehr IRQs zur Verfügung stehen.

Was das "Proben" betrifft, wird von meinem OS dann einfach nicht unterstützt (ein paar Altlasten kann ich schon über Bord werfen).

Proben war mal zu ISA-Zeiten, wo man die Karten noch mit Jumpern auf ihre I/O-Ports konfiguriert hat, üblich ist aber seit vielen Jahren ausgestorben. Du machst ganz sicher keinen Fehler wenn Dein OS sowas nicht unterstützt.

Was mir aber noch nicht beantwortet wurde, gab es schon zu ISA Zeiten MMIO? War dafür nicht die Lücke im RAM zw 15MB und 16MB?

Ja es gab bereits zu ISA-Zeiten MMIO, was glaubst Du was an 0xA0000 oder 0xB8000 liegt. Es gab auch mal Karten die EMS in Hardware zur Verfügung gestellt haben (die hatten 1 oder 2 MB RAM drauf und konnten davon 4 beliebige 16 kByte Häppchen in ein 64 kByte Fenster einblenden, dieses Fenster lag irgendwo zwischen 0xC8000 und 0xF0000). Ansonsten kann ich mich aber nicht an eine konkrete Verwendung von MMIO bei ISA erinnern (wahrscheinlich bin ich dafür einfach nicht alt genug ), was natürlich nicht heißen soll das es das nicht gab schließlich muss ja diese Lücke von 15MB bis 16 MB irgendeinem Zweck gedient haben. Das große Problem mit ISA war eher das es nur einen sehr kleinen Speicher-Adressraum unterstützte (1 MB bei den kurzen Slots und 16 MB bei den langen Slots), da war nur selten viel Platz übrig um da wirklich sinnvolle Dinge rein zu legen.


Grüße
Erik

[Svenska]

Die BIOS-Einstellung "Plug'n'Play OS" gibt an, ob das BIOS jeder Hardware (disabled) die Ressourcen zuweisen soll oder nur der zum Booten benötigten Hardware (enabled). Das heißt konkret Grafik, HDD und (bei USB Legacy Enabled = true) den zum Booten benötigten USB-Geräten.

Zumindest war so die Ursprungsbedeutung. Ob die BIOSse das auch immer so machen, weiß ich nicht. Die Einstellung hat auf jeden Fall nichts mit ISAPnP zu tun, denn das ist immer eine Softwaregeschichte. Für Boot-Geräte (die eigentlich nie ISAPnP waren) ließ sich das auch im DOS-Programm abschalten und dort wurden dann fixe Ressourcen vergeben.

MMIO-Bereich ist wie gesagt der Bereich 640K-1M, sowie 15M-16M. Da der Platz allerdings dort recht klein ist, wurde das nicht von jeder Hardware unterstützt, meist irgendwelche Server-SCSI-Controller.

Scatter/Gather ist bei Netzwerkkarten eher vorgesehen, dass der Kernel den Header zusammenpopelt und dann im selben Paket die Nutzdaten aus dem Userspace hinterherschieben lässt, ohne die Daten in einen gemeinsamen Puffer kopieren zu müssen. Das ist eher nicht vorgesehen, dass der PMM so schlecht verwaltet wird, dass man die Pakete noch weiter splitten muss. Aber ich möchte nicht weiterstreiten.

Gruß

[erik.vikinger]

Hallo,

Die BIOS-Einstellung "Plug'n'Play OS" gibt an, ob das BIOS jeder Hardware (disabled) die Ressourcen zuweisen soll oder nur der zum Booten benötigten Hardware (enabled). Das heißt konkret Grafik, HDD

Das ist Quatsch! Man kann nicht nur einem Teil der PCI-Geräte die benötigten Ressourcen zuweisen und den Rest übergehen, dann hat man nämlich ein Problem wenn man den restlichen PCI-Geräten die gewünschten Ressourcen zuweisen will. Stell Dir mal vor hinter einer PCI-2-PCI-Bridge hängt ein HDD-Controller und ne Reihe anderes Zeugs (das ist absolut üblich, auch schon zu Zeiten des Pentium 1), wenn man nur dem HDD-Controller die Ressourcen zuweist und eine entsprechende Weiterleitung in der Bridge konfiguriert dann kann man den restlichen Geräten hinter dieser Bridge keine Ressourcen mehr zuweisen ohne die Weiterleitung zu ändern und wenn man die Weiterleitung ändert dann entstehen Kollisionen mit anderen Ressourcen/Weiterleitungen. Natürlich könnte das OS die Ressourcenzuweisung noch mal komplett von neuem durchführen aber dann würden sich einige Adressen ändern (von bereits zugewiesenen Ressourcen) und das dürfte unangenehme Nebenwirkungen haben (vor allem weil es sich ja um wichtige Boot-Geräte handelt). Schon um jedem PCI-Gerät die richtige PCI-Geräte-Adresse, also Bus/Device/Function, zuzuweisen muss man den gesamten PCI komplett traversieren (durch alle Bridges hindurch). Die PCI-Enumeration in mehreren Teilschritten zu erledigen ist einfach nicht vorgesehen (würde ja auch keinen Sinn ergeben).

<klug-scheiß-modus>

und (bei USB Legacy Enabled = true) den zum Booten benötigten USB-Geräten.

USB-Geräte bekommen keine Ressourcen wie Speicher, I/O-Ports oder IRQs, das bekommen nur die USB-Host-Controller. USB-Geräte bekommen eine ID im Bereich von 1...127.
</klug-scheiß-modus>

Scatter/Gather ist bei Netzwerkkarten eher vorgesehen, dass der Kernel den Header zusammenpopelt und dann im selben Paket die Nutzdaten aus dem Userspace hinterherschieben lässt, ohne die Daten in einen gemeinsamen Puffer kopieren zu müssen. Das ist eher nicht vorgesehen, dass der PMM so schlecht verwaltet wird, dass man die Pakete noch weiter splitten muss.

Wie Du ja selbst schreibst soll diese Technik es ermöglichen direkt die Daten der User-Space-Applikationen zu benutzen und die sind eben nicht ausgerichtet und können sich daher auch über mehrere Pages verteilen und diese Pages müssen nicht physisch zusammenhängend sein. Das hat nichts mit schlecht verwaltetem Speicher zu tun!


Grüße
Erik

[kevin]

Die PCI-Enumeration in mehreren Teilschritten zu erledigen ist einfach nicht vorgesehen (würde ja auch keinen Sinn ergeben).

Hm, ich habe davon ja keine Ahnung, aber wie funktioniert PCI-Hotplugging?

[FlashBurn]

Hm, ich habe davon ja keine Ahnung, aber wie funktioniert PCI-Hotplugging?

Dumme Antwort, aber die PCI Specs dürften da weiterhelfen

Natürlich könnte das OS die Ressourcenzuweisung noch mal komplett von neuem durchführen aber dann würden sich einige Adressen ändern (von bereits zugewiesenen Ressourcen) und das dürfte unangenehme Nebenwirkungen haben (vor allem weil es sich ja um wichtige Boot-Geräte handelt).

Warum sollte das unangenehme Nebenwirkungen ergeben? Oder um es anders zu Sagen, du wirst die Adresse/IO-Port mind. einmal ändern und zwar von jedem Gerät. Nämlich dann wenn du rausfinden willst wie groß der benutzte Bereich des Geräts ist. Da schreibt man üblicherweise 0xFFFFFFFF in das BAR um zu sehen, ob MMIO oder IO-Port und wie groß der Bereich halt ist. In dem Moment änderst du aber auch die Adresse.
Es ist also durchaus vorgesehen, das du das ganze selbst machst und taljeth Frage geht ja auch in die Richtung.

Schon um jedem PCI-Gerät die richtige PCI-Geräte-Adresse, also Bus/Device/Function, zuzuweisen muss man den gesamten PCI komplett traversieren (durch alle Bridges hindurch).

Was hat das mit den Ressourcen zu tun? Zumal ich mir nicht mal sicher bin, das du (als OS) da noch was dran ändern kannst.

[erik.vikinger]

Hallo,

aber wie funktioniert PCI-Hotplugging?

Das geht nur hinter einer Bridge und da reserviert das BIOS für die möglichen Geräte hinter der Bridge einfach etwas Speicher (und macht ne passende Weiterleitung in der Bridge), wenn die Geräte dann angeschlossen werden können die mit Ressourcen aus dieser Reserve konfiguriert werden. Falls die Geräte mehr benötigen ist das eben Pech.

aber die PCI Specs dürften da weiterhelfen

Leider nicht wirklich, Hot-Plugging ist bei PCI nicht standardisiert. Es gibt z.B. keinen einheitlichen Mechanismus mit dem man den Hot-Plug-Event mitgeteilt bekommt. Bei PCI-Express kann man sich damit behelfen in dem man einfach regelmäßig versucht die Serdes-Link-Ebene zu initialisieren bis was geht (eben pollen).

Warum sollte das unangenehme Nebenwirkungen ergeben? Oder um es anders zu Sagen, du wirst die Adresse/IO-Port mind. einmal ändern und zwar von jedem Gerät. Nämlich dann wenn du rausfinden willst wie groß der benutzte Bereich des Geräts ist. Da schreibt man üblicherweise 0xFFFFFFFF in das BAR um zu sehen, ob MMIO oder IO-Port und wie groß der Bereich halt ist. In dem Moment änderst du aber auch die Adresse.

Das ist was anderes, da ist hinterher ja wieder die selbe Adresse drin (falls Du alles richtig machst), aber wenn man die Ressourcenzuweisung wieder komplett von neuem laufen lässt ist hinterher eine andere Adresse drin (weil ja bei dem vorherigen Teildurchlauf, so wie Svenska ihn andeutet, eben nicht alle benötigten Ressourcen berücksichtigt wurden). Außerdem darf ein PCI-Gerät, während seine BARs analysiert werden, nicht benutzt werden und auch das decodieren von Zugriffen sollte disabled werden (siehe Wiki).

Schon um jedem PCI-Gerät die richtige PCI-Geräte-Adresse, also Bus/Device/Function, zuzuweisen muss man den gesamten PCI komplett traversieren (durch alle Bridges hindurch).

Was hat das mit den Ressourcen zu tun? Zumal ich mir nicht mal sicher bin, das du (als OS) da noch was dran ändern kannst.

Das hat mit den Ressourcen nicht direkt was zu tun aber um eben von jedem PCI-Gerät den Config-Space überhaupt ansprechen zu können muss auch jedem PCI-Gerät eine Geräte-Adresse (Bus/Device/Function) zugewiesen sein. Das OS könnte daran schon was ändern (wenn es die PCI-Enumeration + Ressourcen-Zuweisung noch mal neu durchführt) aber das sollte man besser lassen.


Grüße
Erik

[FlashBurn]

Das ist was anderes, da ist hinterher ja wieder die selbe Adresse drin (falls Du alles richtig machst)

Wie kann da hinterher die selbe Adresse drin sein? Dann würde dir das ja nichts bringen. Damit willst du ja das Alignment (und damit die Größe) feststellen. Wimre dann speichert man vorher den alten Wert um ihn hinterher wieder einzutragen.
Ich lasse mich aber gerne eines besseren belehren, aber so hatte ich die Specs verstanden.

[erik.vikinger]

Hallo,

Wie kann da hinterher die selbe Adresse drin sein?

Arrr ....  (ganz ruhig Erik, nicht aufregen)

Wimre dann speichert man vorher den alten Wert um ihn hinterher wieder einzutragen.

Eben deshalb ist hinterher (also nachdem man den BAR-Analyse-Vorgang komplett durchlaufen hat) wieder die selbe Adresse drin.


Grüße
Erik

[FlashBurn]

Arrr ....  (ganz ruhig Erik, nicht aufregen)

Der Punkt ist, ich habe trotzdem Recht  (Die Ressourcen können geändert werden und das ist auch vorgesehen)

Ich möchte sogar behaupten das Linux und Windows Code haben für eine neue Ressourcenzuweisung und das es halt den Fall gibt das die Ressourcen gar nicht oder fehlerhaft zugewiesen wurden.