<a href="https://forum.lowlevel.eu/index.php?PHPSESSID=74f13434b0ed66a8cd4edf5cabd8dd42&amp;">Lowlevel

Schon allein weil es damit eher machbar sein sollte, eine relativ performante CPU-Emulation hinzukriegen als mit einem simplen Interpreter.

Ob ich auch den CPU-Emulator von QEMU nutzen möchte weiß ich noch nicht, klar dürfte der signifikant schneller sein als mein Interpreter aber ob der dann auch alles das kann was ich will (Segmente oder meine Controll-Register oder PCI-Config-Space-Zugriffe oder ....) wage ich dann doch zu bezweifeln, zumindest würde es wohl erhebliche Arbeiten am Code bedeuten die fehlenden Dinge nachzurüsten.

dein Board an sich wirst du selber programmieren müssen

Hm, mir wäre es zwar lieber wenn man das einfach mit einer Konfigurationsdatei erledigen könnte aber so schwer wird dieser Punkt hoffentlich nicht werden. Und bis ich wirklich soweit bin hat sich QEMU vielleicht sogar noch ein wenig weiter entwickelt.

aber PCI und andere schon vorhandene Komponenten (z.B. ein UART) sollten halbwegs schmerzfrei zu integrieren sein.

Auch PCI-2-PCI-Bridges und andere elementare Komponenten?

Zitat von: erik.vikinger am 08. November 2011, 20:59

Wie hast du vor, das in deinem CPU-Emulator zu machen?

Ich habe vor die Zugriffe meiner CPU so umzusetzen wie die CPU das vorgibt, wenn ein Zugriff keine Attribute hat dann wird der Simulator auch einfach nur in den simulierten Speicher greifen, aber wenn die CPU z.B. das Attribut "atomic" angibt dann wird der Simulator wohl die entsprechende Ressource locken. Ob das auch bei Speicher funktioniert der auf PCI-Geräten sitzt (was bei mir eigentlich auf jeden Speicher zutrifft weil selbst meine CPUs den angeschlossenen RAM als PCI-Device anbieten) hab ich noch nicht entschieden aber das PCI-Express-Protokoll unterstützt zumindest atomares XCHG (und auch atomares CMPXCHG) so das ich das eigentlich auch gerne nutzen möchte (in meiner Plattformspezifikation steht aber drin dass das implementierungsspezifisch ist

).

Grüße
Erik

kevin · « **Antwort #10 am:** 08. November 2011, 21:14 »

Ob ich auch den CPU-Emulator von QEMU nutzen möchte weiß ich noch nicht, klar dürfte der signifikant schneller sein als mein Interpreter aber ob der dann auch alles das kann was ich will (Segmente oder meine Controll-Register oder PCI-Config-Space-Zugriffe oder ....) wage ich dann doch zu bezweifeln, zumindest würde es wohl erhebliche Arbeiten am Code bedeuten die fehlenden Dinge nachzurüsten.

Ich will ja nicht an deinem Bild kratzen, dass du was ganz besonderes machst, aber ich bezweifle, dass irgendwas an deiner CPU fundamentale Änderungen verlangen würde. Ich gehe sogar davon aus, dass du sie einfach nur implementieren musst, ohne irgendwas am Backend zu verändern.

Was ist an deinen Segmenten so schwierig, dass TCG das nicht hinkriegen sollte? Oder an Kontrollregistern? Selbst für die PCI-Config-Space-Zugriffe, die als native Instruktion ja wirklich ein bisschen schräg sind, dürfte das leicht gehen. Ist halt ein Funktionsaufruf irgendwo in den PCI-Code rein, nehme ich an. Vielleicht musst du die Funktion erst noch exportieren, weil so ein direkter Zugriff von außen noch nicht vorgesehen ist, aber sonst?

Zitat

Hm, mir wäre es zwar lieber wenn man das einfach mit einer Konfigurationsdatei erledigen könnte aber so schwer wird dieser Punkt hoffentlich nicht werden. Und bis ich wirklich soweit bin hat sich QEMU vielleicht sogar noch ein wenig weiter entwickelt.

Ich glaube, ein bisschen Chipsatzlogik wird immer bleiben, oder?

Zitat

Auch PCI-2-PCI-Bridges und andere elementare Komponenten?

PCI-to-PCI-Bridges halte ich nicht wirklich für elementar, aber ja, sollte entweder schon gehen oder ist aktiv in Entwicklung.

Zitat

Ich habe vor die Zugriffe meiner CPU so umzusetzen wie die CPU das vorgibt, wenn ein Zugriff keine Attribute hat dann wird der Simulator auch einfach nur in den simulierten Speicher greifen, aber wenn die CPU z.B. das Attribut "atomic" angibt dann wird der Simulator wohl die entsprechende Ressource locken.

Hm, ja, mit einem stupiden Interpreter ist das natürlich einfach. Wirklich kompliziert wird es vermutlich auch mit TCG nicht, höchstens etwas langsam, weil du für jede atomare Operation in einen Helper callen musst, der das Lock nimmt. Wenn du nur für wenige Operationen garantierst, dass sie atomar sein können, dann wäre das aber wahrscheinlich eine Möglichkeit.

Aber ansonsten würde ich an deiner Stelle einfach erstmal auf Multithreading verzichten. Oder ist das für irgendeinen deiner Einsatzzwecke wirklich essentiell?

erik.vikinger · « **Antwort #11 am:** 09. November 2011, 17:06 »

Hallo,

Ich will ja nicht an deinem Bild kratzen, dass du was ganz besonderes machst, aber ich bezweifle, dass irgendwas an deiner CPU fundamentale Änderungen verlangen würde. Ich gehe sogar davon aus, dass du sie einfach nur implementieren musst, ohne irgendwas am Backend zu verändern.

Für nur die CPU allein betrachtet könnte das tatsächlich stimmen, im Endeffekt koche ich auch nur mit Wasser, aber gerade was die Verbindung zwischen Chip-Satz und CPU angeht denke ich müsste man QEMU erheblich umbauen. Mein IRQ-Controller meldet z.B. IRQs nicht an eine bestimmte CPU sondern immer an alle CPUs (es wird auf der physischen Implementierung nur eine einzige IRQ-REQ-Leitung geben) und alle CPUs prüfen dann ob die Priorität des gemeldeten IRQs höher ist als die aktuell ausgeführte User-Mode-Software (im Kernel-Mode oder bei gesperrten IRQs wird das IRQ-REQ-Signal immer ignoriert) und nur die CPUs bei denen das so ist bemühen sich dann auch diesen IRQ abzuholen. Dabei können sogar mehrere CPUs erfolgreich sein wenn z.B. mehrere IRQs mit gleicher Priorität pending waren oder wenn während dessen ein neuer IRQ mit einer höheren Priorität noch beim IRQ-Controller ankommt. Ein anderes Beispiel ist mein Paging das immer über alle CPUs und auch den Chipsatz synchron arbeitet (mein CR3-Äquivalent wird über alle Teilnehmer vom CPU-Netzwerk geshared). Ich denke einfach das es da zu viele Dinge gibt die existierende Emulatoren/Simulatoren nicht ohne weiteres bieten können.

Was ist an deinen Segmenten so schwierig, dass TCG das nicht hinkriegen sollte? Oder an Kontrollregistern?

An meinen Segmenten dürfte es sicher nicht scheitern, macht bestimmt nur die Mini-Programme zur Simulation etwas komplexer als normale Speicherzugriffe bei x86. Bei den Kontrollregistern bin ich mir nicht sicher da ich es ja ermöglichen möchte das jede CPU auch an die lokalen Kontrollregister anderer CPUs ran kommt, nebst dessen das manche global sind oder auch im Chipsatz liegen. Ich hab vor ner Weile mal das Kommunikationsprotokoll zwischen CPUs und Chipsatz spezifiziert und da sind doch ein paar Dinge drin die es so bei ähnlichen Protokollen (wie PCI-Express oder Hypertransport) nicht gibt, das ist alles keine Hexerei aber es gibt eben doch einige erhebliche Unterschiede die QEMU und Co sicher nicht auf Anhieb emulieren/simulieren können.

Selbst für die PCI-Config-Space-Zugriffe, die als native Instruktion ja wirklich ein bisschen schräg sind, dürfte das leicht gehen. Ist halt ein Funktionsaufruf irgendwo in den PCI-Code rein, nehme ich an. Vielleicht musst du die Funktion erst noch exportieren, weil so ein direkter Zugriff von außen noch nicht vorgesehen ist, aber sonst?

Warum ist ein im Befehlssatz integrierter PCI-Config-Space-Zugriff schräg? Jede CPU bietet den physisch lokalen Speicher als PCI-Device an, nur so ist es möglich das der OS-Boot-Code erst die physische Adresse des normalen RAM beim Booten des OS festlegen kann, also ist es IMHO naheliegend das die zugehörigen Zugriffe auch als native Instruktionen vorliegen. Wenn das z.B. über den Chipsatz ginge müsste die CPU mehrere Zugriffe (mindestens 2) in den Chipsatz generieren (was schon mal 4 Pakete (2 Anfragen + 2 Antworten) im CPU-Netzwerk sind) und der Chipsatz muss da mittendrin auch noch mal eine passende Anfrage an die betreffende CPU absetzen und die Antwort entgegennehmen, das ganze wäre so auf jeden Fall deutlich langsamer (was ansich noch nicht mal schlimm wäre, passiert ja nur während des Bootens) und diese Chipsatz-Komponente wäre dann eine Ressource die mit einem Lock gegen mehrfache Parallel-Nutzung abgesichert werden müsste, nebst dessen das ich dann keinen PCI-Config-Space-Zugriff mehr für den User-Mode anbieten kann.

Ich glaube, ein bisschen Chipsatzlogik wird immer bleiben, oder?

Ja, das auf jeden Fall. Vor allem wenn man so viele schräge Dinge vor hat wie ich.

Da fällt mir ein: wie sieht es mit Dingen wie einer I/O-MMU aus?
In meinem Simulator wollte ich das so machen das für die HW-Geräte und für die CPUs zwei verschiedene Interfaces am zentralen Speicher-Manager zur Verfügung stehen und das Interface für die HW-Geräte macht dann gegebenenfalls noch Paging bevor die Zugriffe wirklich an die Komponenten gehen die den Speicher anbieten.

PCI-to-PCI-Bridges halte ich nicht wirklich für elementar, aber ja, sollte entweder schon gehen oder ist aktiv in Entwicklung.

PCI-to-PCI-Bridges sind für das Ressourcen-Management und Routing im PCI-Universum sehr wichtig (bei PCI-Express sogar noch mehr als beim klassischen PCI), von daher sind die IMHO doch recht elementar wichtig.

höchstens etwas langsam, weil du für jede atomare Operation in einen Helper callen musst, der das Lock nimmt.

Äh, also das verstehe ich nicht. Könntest Du das Bitte etwas klarer beschreiben.

Wenn du nur für wenige Operationen garantierst, dass sie atomar sein können, dann wäre das aber wahrscheinlich eine Möglichkeit.

Im Prinzip kann bei mir fast jeder Speicherzugriff atomar sein, auf jeden Fall müssen alle nach außen sichtbaren Zugriffsvarianten auch alle Attribute unterstützen, aber dafür habe ich nur recht wenige Befehle die auf den Speicher zugreifen können (eben klassisches RISC). In meiner jetzigen Implementierung werden diese Attribute immer als Parameter beim Zugriff mitgegeben und die Komponente im Simulator die diesen Zugriff letztendlich bearbeitet muss diese Attribute dann umsetzen. Sowas wie z.B. ein Bus-Locking (was es früher bei den x86-CPU-Fronside-Bussen gab) wird es auf meiner Plattform nicht geben, bei PCI-Express steht das auch auf "depricated" und ist nur deswegen vorhanden weil der klassische PCI das mal spezifiziert hat (es gibt aber kaum HW die das tatsächlich unterstützt, auf den meisten PCI-Karten ist das entsprechende PIN gar nicht vorhanden und auch viele Chipsatze können das gar nicht).

Zitat von: erik.vikinger am 09. November 2011, 17:06

Aber ansonsten würde ich an deiner Stelle einfach erstmal auf Multithreading verzichten. Oder ist das für irgendeinen deiner Einsatzzwecke wirklich essentiell?

Naja, ich hätte gerne das sich das Verhalten des Simulators möglichst gut mit dem der realen HW deckt und wenn auf der realen HW Race-Conditions auftreten können dann soll das im Simulator grundsätzlich auch möglich sein. Auch gehört bei mir SMP elementar zum Design dazu, meine Plattform kann nicht als Single-CPU existieren. Es wird schon genug Unterschiede im Verhalten geben weil die reale CPU z.B. einen komplexen Segment-Descriptor-Cache hat aber der Simulator das nicht bieten kann (Cache, der in HW parallel durchsucht wird wogegen in SW nur sequentielles Suchen möglich ist, macht im Simulator nicht viel Sinn).

Grüße
Erik

kevin · « **Antwort #12 am:** 09. November 2011, 17:50 »

Für nur die CPU allein betrachtet könnte das tatsächlich stimmen, im Endeffekt koche ich auch nur mit Wasser, aber gerade was die Verbindung zwischen Chip-Satz und CPU angeht denke ich müsste man QEMU erheblich umbauen. Mein IRQ-Controller meldet z.B. IRQs nicht an eine bestimmte CPU sondern immer an alle CPUs (es wird auf der physischen Implementierung nur eine einzige IRQ-REQ-Leitung geben)

Und warum sollte das schwer umzusetzen sein? Wenn du einen eigenen Interruptscontroller haben willst, musst du den natürlich implementieren, klar. Aber warum sollte der nicht alle CPUs unterbrechen können?

Du kommst natürlich auf einige Details zu sprechen, von denen ich nicht sicher sagen kann, was wie einfach geht, weil ich mich damit selber noch nie befasst habe (warum auch, für x86 haben das ja andere schon erledigt).

Zitat

An meinen Segmenten dürfte es sicher nicht scheitern, macht bestimmt nur die Mini-Programme zur Simulation etwas komplexer als normale Speicherzugriffe bei x86.

x86 hat meines Wissens auch Segmentierung...

Zitat

Bei den Kontrollregistern bin ich mir nicht sicher da ich es ja ermöglichen möchte das jede CPU auch an die lokalen Kontrollregister anderer CPUs ran kommt, nebst dessen das manche global sind oder auch im Chipsatz liegen. Ich hab vor ner Weile mal das Kommunikationsprotokoll zwischen CPUs und Chipsatz spezifiziert und da sind doch ein paar Dinge drin die es so bei ähnlichen Protokollen (wie PCI-Express oder Hypertransport) nicht gibt, das ist alles keine Hexerei aber es gibt eben doch einige erhebliche Unterschiede die QEMU und Co sicher nicht auf Anhieb emulieren/simulieren können.

Ja, solche ungewöhnlichen Features sind schon eher was, wo man mal schauen müsste, wie das klappt. Im aktuellen Single-Threaded-TCG dürfte es leicht sein, weil ja nur eine CPU gleichzeitig läuft und damit der Zustand der anderen CPUs konsistent sein müsste. Wenn man mit Multitasking anfängt, müsste man dazu wieder die andere CPU locken (andererseits ist das dann nicht viel anders als atomare Speicherzugriffe und das muss man sowieso lösen).

Wie das Lowlevel-Protokoll zwischen Chipsatz und CPU aussieht, spielt aber wahrscheinlich keine Rolle, weil es für die Software unsichtbar ist. Das muss dann im Emulator nicht genau so implementiert sein wie in Hardware, es muss nur das gleiche Ergebnis liefern.

Zitat

Warum ist ein im Befehlssatz integrierter PCI-Config-Space-Zugriff schräg?

Weil ich es außer bei dir noch nirgends gesehen habe.

Zitat

Da fällt mir ein: wie sieht es mit Dingen wie einer I/O-MMU aus?
In meinem Simulator wollte ich das so machen das für die HW-Geräte und für die CPUs zwei verschiedene Interfaces am zentralen Speicher-Manager zur Verfügung stehen und das Interface für die HW-Geräte macht dann gegebenenfalls noch Paging bevor die Zugriffe wirklich an die Komponenten gehen die den Speicher anbieten.

IOMMU ist auch noch in Arbeit. Sobald die Hardware mal durch die passenden Interfaces geht, sollte sich leicht alles implementieren lassen, was man haben will. Auch hier gilt wieder im Zweifelsfall, dass nur das sichtbare Ergebnis zählt und die tatsächliche Implementierung in der Hardware keine Rolle spielt.

Zitat

PCI-to-PCI-Bridges sind für das Ressourcen-Management und Routing im PCI-Universum sehr wichtig (bei PCI-Express sogar noch mehr als beim klassischen PCI), von daher sind die IMHO doch recht elementar wichtig.

Aber nur, wenn du mehrere PCI-Busse hast, was in einfachen Fällen nicht so ist.

Zitat

Im Prinzip kann bei mir fast jeder Speicherzugriff atomar sein

Wovon hängt das ab, ob er es wirklich ist?

Zitat

Naja, ich hätte gerne das sich das Verhalten des Simulators möglichst gut mit dem der realen HW deckt und wenn auf der realen HW Race-Conditions auftreten können dann soll das im Simulator grundsätzlich auch möglich sein.

Ja, das ist der Nachteil ohne Multithreading.

erik.vikinger · « **Antwort #13 am:** 09. November 2011, 20:03 »

Hallo,

Und warum sollte das schwer umzusetzen sein? ..... Aber warum sollte der nicht alle CPUs unterbrechen können?

Keine Ahnung, das war eigentlich die Frage an Dich. Von uns zweien bist Du doch derjenige der sich besser mit QEMU auskennt. Wenn Du sagst dass das alles kein Problem ist dann glaube ich Dir das vorbehaltlos. Am IRQ-Controller selber sehe ich auch kein Problem, mal davon abgesehen das den Code jemand tippen muss, ich dachte eher dass das Abholen der IRQs komplexer ist weil ich davon ausgegangen bin das sich QEMU da weitestgehend an das Konzept von x86 hält (mit dem meine Plattform nicht viel gemeinsam hat).

x86 hat meines Wissens auch Segmentierung...

Oh, hm, das hatte ich ja fast vergessen.

Dafür können meine Segmente deutlich mehr, es gibt z.B. nicht nur ein Limit sondern auch ein Minimum, es gibt bei mir auch keinen Adressüberlauf (zumindest wenn die Offset-Berechnung im Speicherzugriffsbefehl passiert) und ich hab getrennt nach Kernel-Mode und User-Mode spezifische Zugriffsrechte. Außerdem erinnere ich mich daran mal irgendwo gelesen zu haben das QEMU die x86-Segmente nicht zu 100% korrekt unterstützt (auch aus Gründen der Performance) und deswegen einige ältere OSe die von den Segmenten recht regen Gebrauch gemacht haben (wie z.B. OS/2) nicht zuverlässig funktionieren bzw. mache Fehler in der Software nicht zuverlässig erkannt werden.

.... es muss nur das gleiche Ergebnis liefern.

Richtig, aber zum gleichen Ergebnis gehört u.U. auch das selbe Zeitverhalten. Du hast aber schon Recht das die SW-Implementierung nicht sehr viel mit der HW-Implementierung gemeinsam haben muss, aber zumindest der Umfang der unterstützten Features muss gleich sein.

Weil ich es außer bei dir noch nirgends gesehen habe.

Gut, das ist natürlich ein absolut klarer Grund, dann betrachte ich das Attribut "schräg" als Qualitätsmerkmal.

Aber nur, wenn du mehrere PCI-Busse hast, was in einfachen Fällen nicht so ist.

Bei PCI-Express hat man eigentlich immer mehrere Busse (da ist im Prinzip jeder Link ein eigener Bus). Dass das bei QEMU noch nicht so ist liegt bestimmt auch daran das QEMU wohl keinen so ganz aktuellen Chipsatz emuliert oder?

Zum Thema PCI fällt mir noch was ein: theoretisch ist es ja möglich das ein busmasterfähiges PCI-Gerät auch die (Speicher-)Ressourcen von anderen PCI-Geräten ansprechen kann, beim klassischen PCI funktioniert das innerhalb des selben Bus-Segments immer (weil ja alles an der selben Leitung hängt, eben ein klassischer Bus) und nur wenn es über mehrere Busse geht muss die PCI-to-PCI-Brindge passend routen können. Die PCI-Spezifikation sagt dazu "implementation defined" und bei den meisten PCI-to-PCI-Bridges ist es über irgendeinen proprietären Mechanismus konfigurierbar ob auch zwischen verschiedenen South-Ports geroutet wird (wird eigentlich nur für spezielle Industrielle Anwendungen benutzt). Die meisten x86-Chipsatze können das nicht und in meiner Plattform-Spezifikation steht ebenfalls "implementation defined" (warum soll ich mir auch was aufhalsen was wohl eh nicht benötigt wird). Wie sieht es damit in QEMU aus? Wenn alle Speicherzugriffe durch einen zentralen Speicher-Dispatcher (an dem sich alle Module anmelden die physischen Speicher anbieten) gehen dann könnte es fast komplizierter sein sowas zu verhindern als zu erlauben (zum Verhindern müsste der Dispatcher ja wissen von wem ein Zugriff initiiert wird und dabei auch noch die simulierte Struktur beachten, was sicher nicht ganz trivial ist).

Wovon hängt das ab, ob er es wirklich ist?

Die Attribute der Speicherzugriffe werden im OpCode mit kodiert. Bei den Befehlen die komplexere Adressierungsarten können fehlen dafür oft die nötigen Bits so das dort mit den Default-Attributen (also gar keinen Attributen) gearbeitet wird aber nach außen hin muss jede mögliche Zugriffsart alle Attribute unterstützen.

Zitat von: erik.vikinger am 09. November 2011, 20:03

Ja, das ist der Nachteil ohne Multithreading.

Das ist aus meiner Sicht ein erheblicher Nachteil. Nebst dessen das es mir nicht gefallen würde wenn ich ein 4 oder 8 CPU-System simulieren würde und dafür auf dem Host-PC nur ein einziger Core benutzt wird, vor allem weil hier ja doch erheblich von Multithreading profitiert werden könnte. So ein Simulator ist IMHO ein gutes Beispiel dafür wo es sich lohnen würde die Threads die die CPUs simulieren auch auf jeweils individuelle Host-CPUs festzupinnen, so das jede simulierte CPU auch vom individuellem Cache der jeweils fest zugeordneten Host-CPU profitieren kann. Mag ja sein das der TCG von QEMU um einiges schneller ist als ein simpler Simulator aber wenn letzterer dafür das Host-System voll ausreizen kann dann könnte er doch im Vorteil sein. Auch müsste man dafür kein User-Mode-Multithreading realisieren, das ist ja das was QEMU letztendlich macht, nur um X verschiedene und unabhängige Aktionen quasi gleichzeitig laufen zu lassen. Ich kann mir vorstellen dass das den Code von QEMU komplizierter macht als nötig wäre, aber wissen tu ich das nicht. Wie fein wird denn in QEMU unterteilt?

Grüße
Erik

Svenska · « **Antwort #14 am:** 10. November 2011, 01:58 »

Wenn der TCG die Performance verzehnfacht, dann müsste dein Simulator schon auf 10 Cores gleichzeitig laufen, um gleichwertige Performance zu liefern. Dann baue deinen Simulator lieber mit Qemu auf und bringe dem gleichzeitig Multithreading bei, dann hätte ich auch was davon.

Du solltest grundsätzlich zwei Simulationen bauen. Eine, bei der du jedes Signal simulierst (wird natürlich unglaublich langsam) und damit dein Design verifizieren kannst und eine, bei der nur noch die Logik "nach außen" (also CPU und Peripherie) simuliert wird. Bei letzterem ist es dann auch mehr oder minder egal, ob der Multithreading nutzt oder nicht.

Qemu simuliert eine PIIX3 Southbridge auf einem Intel 440FX Chipsatz. Der ist im Original von 1996 und unterstützt Pentium Pro und Pentium II.

OS/2 (zumindest die Versionen 2.1 und Warp 3) läuft in Qemu inzwischen zuverlässig. Soweit ich weiß, liegt die schlechte Emulierbarkeit nicht an der Segmentierung, sondern an der Verwendung der Ringe 1 und/oder 2. Außerdem geht OS/2 etwas seltsam mit der Hardware um, was aber auch auf realer Hardware stört.

Gruß,
Svenska

kevin · « **Antwort #15 am:** 10. November 2011, 10:52 »

Keine Ahnung, das war eigentlich die Frage an Dich. Von uns zweien bist Du doch derjenige der sich besser mit QEMU auskennt.

Ja, schon, aber in Bezug auf CPU-Emulation und direkt damit zusammenhängendes Lowlevel-Zeug kenne ich mich auch nicht im Detail aus. Ich habe zwar schon mal ein, zwei Fixes für den i386-Emulator gebastelt, aber das war es mehr oder weniger.

Zitat

Wenn Du sagst dass das alles kein Problem ist dann glaube ich Dir das vorbehaltlos. Am IRQ-Controller selber sehe ich auch kein Problem, mal davon abgesehen das den Code jemand tippen muss, ich dachte eher dass das Abholen der IRQs komplexer ist weil ich davon ausgegangen bin das sich QEMU da weitestgehend an das Konzept von x86 hält (mit dem meine Plattform nicht viel gemeinsam hat).

qemu hat im Moment 20 verschiedene *-softmmu-Verzeichnisse, das sind die Architekturen, die es als Systememulator unterstützt. Natürlich sind da ein paar "doppelte" dabei (i386/x86_64, mips64/mips64el/mips/mipsel, ...), aber x86-spezifisch kannst du da nichts machen.

Bei klassischen Interrupts habe ich zumindest eine Vorstellung, wie das in qemu ungefähr läuft, aber du benutzt ja MSI. Das habe ich noch nicht angefasst.

Zitat

Dafür können meine Segmente deutlich mehr, es gibt z.B. nicht nur ein Limit sondern auch ein Minimum, es gibt bei mir auch keinen Adressüberlauf (zumindest wenn die Offset-Berechnung im Speicherzugriffsbefehl passiert) und ich hab getrennt nach Kernel-Mode und User-Mode spezifische Zugriffsrechte. Außerdem erinnere ich mich daran mal irgendwo gelesen zu haben das QEMU die x86-Segmente nicht zu 100% korrekt unterstützt (auch aus Gründen der Performance) und deswegen einige ältere OSe die von den Segmenten recht regen Gebrauch gemacht haben (wie z.B. OS/2) nicht zuverlässig funktionieren bzw. mache Fehler in der Software nicht zuverlässig erkannt werden.

TCG ignoriert die Limits, eben wegen der Performance. Aber es ist möglich (und gab auch mal einen Patch), das zu implementieren. Letztendlich ist es nur ein Implementierungsdetail in deinen load/store-Befehlen, die eben ein paar Checks mehr machen müssen.

Zitat

Bei PCI-Express hat man eigentlich immer mehrere Busse (da ist im Prinzip jeder Link ein eigener Bus). Dass das bei QEMU noch nicht so ist liegt bestimmt auch daran das QEMU wohl keinen so ganz aktuellen Chipsatz emuliert oder?

Ja. Aber wie gesagt, im Moment wird an einem Q35-Chipsatz gewerkelt, für den muss das dann wahrscheinlich alles da sein.

Zitat

Zum Thema PCI fällt mir noch was ein: theoretisch ist es ja möglich das ein busmasterfähiges PCI-Gerät auch die (Speicher-)Ressourcen von anderen PCI-Geräten ansprechen kann, [...] Wie sieht es damit in QEMU aus? Wenn alle Speicherzugriffe durch einen zentralen Speicher-Dispatcher (an dem sich alle Module anmelden die physischen Speicher anbieten) gehen dann könnte es fast komplizierter sein sowas zu verhindern als zu erlauben (zum Verhindern müsste der Dispatcher ja wissen von wem ein Zugriff initiiert wird und dabei auch noch die simulierte Struktur beachten, was sicher nicht ganz trivial ist).

Im Detail keine Ahnung, tut mir leid. Was ich weiß, ist dass solches Zeug vor kurzem diskutiert wurde und dass das Ziel ist, die Struktur schon richtig zu emulieren (was andererseits bedeutet, dass das heute nicht der Fall ist).

Zitat

Die Attribute der Speicherzugriffe werden im OpCode mit kodiert. Bei den Befehlen die komplexere Adressierungsarten können fehlen dafür oft die nötigen Bits so das dort mit den Default-Attributen (also gar keinen Attributen) gearbeitet wird aber nach außen hin muss jede mögliche Zugriffsart alle Attribute unterstützen.

Das heißt, "atomar" ist so ein Attribut?

Wenn ja, dann wird es ja vermutlich eher selten gesetzt werden (eben dort, wo man es wirklich braucht). Dann dürften sich auch die Performanceeinbußen in der Emulation im Ganzen in Grenzen halten.

erik.vikinger · « **Antwort #16 am:** 10. November 2011, 12:16 »

Hallo,

Wenn der TCG die Performance verzehnfacht

Ob der TCG wirklich zehn mal so schnell ist würde ich dann doch bezweifeln, so arg stupide werde ich meinen CPU-Simulator auch nicht bauen. Nebst dessen das die CPUs ja nicht alles sind, jedes HW-Gerät benötigt schließlich auch mindestens einen eigenen Thread (in echt arbeiten ja auch alle Transistoren in einem PC gleichzeitig und nicht einer nach dem anderen). Wenn mein Simulator für jede simulierte CPU auch eine eigene echte CPU nutzen kann wird schon allein das eine deutlich bessere Effizienz bei der Cache-Nutzung bringen was wohl bestimmt schon mal Faktor 2 oder noch mehr bringen kann. Wenn mein Host-System über genügend CPUs verfügt dann denke ich ist da noch sehr viel mehr drin auch ohne was tolles programmieren zu müssen.

Dann baue deinen Simulator lieber mit Qemu auf und bringe dem gleichzeitig Multithreading bei, dann hätte ich auch was davon.

Das mache ich definitiv nicht alleine! Wenn Du mit hilfst, und auch noch ein paar Kumpels hast, können wir gerne noch mal drüber diskutieren.

Auf der anderen Seite erscheint mir das TCG-Konzept auch gar nicht so arg komplex, ich hab ja bei meiner CPU immer Befehlspakete und ich denke das es gar nicht so komplex wäre aus jedem Paket ein Bündel x86-Assembler-Code zu machen der direkt mit dem CPU-Zustand (also dem Register-File) im Speicher arbeitet. Zumindest die einfachen und mathematischen Befehle sollte so zu erledigen sein, schwieriger sind da wohl eher die Speicherzugriffe und die ganzen anderen System-Befehle aber die könnte man einfach als CALL auf eine in C++ geschriebene Simulation umsetzen (nur die Calling-Convention muss dafür passen). Ich denke der Vorteil meiner CPU ist das sie RISC ist und damit Speicherzugriffe (die ja in jedem Fall durch den eigentlichen Simulator müssen) von den simplen Rechenbefehlen usw. sauber getrennt sind. Vermutlich ist eine simple eigene TCG-Umsetzung leichter als QEMU auf Multithreading umzubauen.

Du solltest grundsätzlich zwei Simulationen bauen. Eine, bei der du jedes Signal simulierst (wird natürlich unglaublich langsam) und damit dein Design verifizieren kannst

Das mach der VHDL-Simulator der wirklich jedes interne Signal und auch jedes Signal auf der Platine simuliert (letzteres muss ich als Test-Umgebung auch in VHDL nachbilden). Und sowas ist wirklich extrem langsam, ich hab mal vor ein paar Jahren ein komplexeres FPGA-Design auf einem P4 2,4GHz simuliert und der hat für etwas über 2 ms simulierter Zeit fast 3 Stunden gebraucht. Mein System mit mehreren CPUs und dem Chipsatz und eventuell noch einem primitiven PCI-Device am South-Port werde ich wohl höchstens für ne halbe Millisekunde simulieren lassen so das ich dort nur mit extra Test-Code verifizieren kann. Wenn ich wirklich in einer Simulation mein OS testen und entwickeln möchte dann geht das nur mit einer rein funktionalen Simulation.

Qemu simuliert eine PIIX3 Southbridge auf einem Intel 440FX Chipsatz. Der ist im Original von 1996 und unterstützt Pentium Pro und Pentium II.

Ich weiß, deswegen sind da ja auch keine PCI-to-PCI-Bridges im simulierten System nötig. Meine CPUs werden aber auf jeden Fall nicht mit einem 440FX zusammenarbeiten können und deswegen werde ich wohl besseren Support der PCI-Infrastruktur benötigen.
Mich macht eigentlich immer stutzig das die normalen OSe das so einfach fressen, wundern die sich nicht wenn eine aktuelle 64Bit-CPU emuliert wird und diese nur einen 440FX zur Seite gestellt bekommt?

OS/2 (zumindest die Versionen 2.1 und Warp 3) läuft in Qemu inzwischen zuverlässig....

Aha, dann ist mein Wissen offensichtlich veraltet.

aber in Bezug auf CPU-Emulation und direkt damit zusammenhängendes Lowlevel-Zeug kenne ich mich auch nicht im Detail aus.

Okay. Gibt es denn irgendwo eine gute/detaillierte Dokumentation zum QEMU-Quell-Code in der steht welche Funktionalität sich in welchem Verzeichnis (oder gar in welcher Datei) befindet oder andersherum? Oder kann man solche Fragen auf einer Mailling-Liste o.ä. loswerden (möglichst in Deutsch)?

aber du benutzt ja MSI

Das sollte zwischen IRQ-Controller und CPU das selbe sein, MSI betrifft ja nur den Weg von den HW-Geräten bis zum IRQ-Controller (und bedeutet im wesentlichen das der IRQ-Controller ein kleines bisschen Speicher anbieten muss, so ne Art Drop-Target das bei mir wieder per PCI-Config-Space (in der Host-Bridge) verwaltet wird, und jeden Schreibzugriff aber nicht wie bei normalen Speicher behandelt sondern ihn auswertet und eine entsprechende Aktion auslöst).

TCG ignoriert die Limits, eben wegen der Performance. Aber es ist möglich (und gab auch mal einen Patch), das zu implementieren. Letztendlich ist es nur ein Implementierungsdetail in deinen load/store-Befehlen, die eben ein paar Checks mehr machen müssen.

Okay, ich denke auch das TCG ansich kein Kriterium gegen den Einsatz von QEMU für meine gesamte Plattform darstellt. Was mich eher stört ist das QEMU nur rein singlethreaded ist, das betrachte ich eigentlich als echtes KO-Kriterium. Für irgendwelche HW-Geräte hinter dem Chipsatz ist mir das relativ egal aber für den Kernbereich meiner Plattform möchte ich auf jeden Fall Multithreading.

im Moment wird an einem Q35-Chipsatz gewerkelt, für den muss das dann wahrscheinlich alles da sein.

Das klingt doch sehr gut.

Was ich weiß, ist dass solches Zeug vor kurzem diskutiert wurde und dass das Ziel ist, die Struktur schon richtig zu emulieren (was andererseits bedeutet, dass das heute nicht der Fall ist).

Okay, im Prinzip ist es mir auch egal ob die simulierten HW-Geräte miteinander kommunizieren können oder nicht. Für die eigentliche Plattform und auch das OS ist das völlig egal, sowas würde eigentlich auch nur auf echter Hardware ein Sicherheitsproblem darstellen. Solange eine eventuelle I/O-MMU nicht umgangen werden kann ist mir dieser Punkt wursch, es ist mir nur gestern Abend noch eingefallen weil ich dieses Thema vor einer Zeit bei der Suche nach geeigneten PCI-Bridges an der Hand hatte.