Thema: Virtual Mode 8086

[ChristianF]

Hi
Ich habe eben mal aus interesse den Artikel über den vm86 aus der Wiki gelesen.
Dort steht, dass dieser das erste Megabyte benutzt.
Nun habe ich den Kernel von "Bran's Kernel Development" und da wird der Kernel an die Stelle 0x00100000 geladen (das erste MB).
Kann ich die Adresse aus dem Linkerscript einfach ändern, also z.B.: von 0x00100000 nach 0x00200000?
Oder wird da nur der Speicher von 0x00000000 bis 0x00100000 benutzt? (Mir ist klar, dass das dann 16Bit Adressen sind)
 
Gruß
Christian

[bluecode]

Dort steht, dass dieser das erste Megabyte benutzt.

Den Speicher zwischen 0 und 0x100000.

Nun habe ich den Kernel von "Bran's Kernel Development" und da wird der Kernel an die Stelle 0x00100000 geladen (das erste MB).

Genau an der 1MB Marke.

Kann ich die Adresse aus dem Linkerscript einfach ändern, also z.B.: von 0x00100000 nach 0x00200000?

Wenn Bran's Tutorial grub benutzt, dann auf jeden Fall. Anderen Bootloadern wirst du das evtl. erst beibiegen müssen.

Oder wird da nur der Speicher von 0x00000000 bis 0x00100000 benutzt?

Korrekt. Das hast du doch oben bereits indirekt zitiert?

Sry, aber ich versteh nicht wirklich wo du ein Problem siehst.

[ChristianF]

Guten Morgen,
meine eigentliche Frage war nur, ob ich, falls ich solche vm8086 Tasks jemals einbauen werde,
ob ich da erst meinen Kernel nach oben verschoben werden, bzw. eine Überprüfung auf eine
Kollision einbauen muss, weil der Stack ja nach unten wächst.
(Oder verwechsle ich da mal wieder was  )
 
Gruß
Christian

[bluecode]

Ehrlich gesagt verstehe ich nicht wirklich wie du darauf kommst

Ich erklär einfach mal ein paar Sachen zum Virtual 8086 Mode, vielleicht erledigen sich dann die Fragen. Also: Der v86 ist ein Untermode des Protected-Mode, d.h. konkret, dass die Schutzmechanismen des Protected-Mode (ich mein jetzt im speziellen Paging) aktiviert sind. Hardwareinterrupts und Exceptions werden weiterhin über die IDT und deinen Kernel abgearbeitet. Wobei beim Wechsel zu deinem Kernel im vom v86 zurück in den Protected-Mode geschaltet wird. Im v86 selbst führst du dann eigentlich nur 16bit [BIOS]-Code aus. Dieser Code kann natürlich nur auf 1MB RAM zugreifen (plus 63kb oder so), wobei dazu zu sagen ist, dass dieser Code nur Zugriff auf den virtuellen Adressraum bis 1MB hat, nicht direkt auf den physischen. Der 16bit Code hat auch da nur Zugriff auf die Seiten die als 'user' gekennzeichnet sind, wenn er auf andere Speicherseiten zugreift, dann fliegt genau wie im usermode/cpl3 einfach der allseits bekannte/beliebte Pagefault. Auch wenn der 16bit Code Softwareinterrupts, cli/sti oder in/out ausführen möchte wird in den Kernel gesprungen (diesmal über den General Protection Fault), damit diese Instruktionen vom Kernel emuliert werden können. Teilweise kann man das den Prozessor auch automatisch über das IOPL, die I/O Bitmap im TSS und die VME (Virtual 8086 Mode Extensions, seit dem pentium) machen lassen.

Ich hoffe, dass dir das jetzt weitergeholfen hat

[ChristianF]

Hi
Das würde dann heißen, ich mappe meinen Kernel an die Virtuelle Adresse 0xC0100000 o.ä. und mappe dann den entsprechenden Speicher
vom vm86-Task an irgendeine Stelle unter dem ersten MB (virtuell).
 
Die Frage kommt deswegen, weil ich grad eine virtuelle Adresse für den Heap suche, die im Moment 0xC0000000 ist.
Wenn das so ist, wie ich das oben geschrieben habe, würde ich das halt auf 0xD0000000 ändern, usw.
 
Gruß Christian
 
*EDIT*
Mein Kernel wird nun nach 0xC0000000 gemappt. Der Kernel Heap kommt dann nach 0xD0000000.
Ich kann dann einfach Speicher unterhalb 1MB reservieren und muss keine Rücksicht nehmen, wegen den VM8086 Threads

[ChristianF]

Es ist mal wieder soweit und ich denke darüber nach zumindest einen System Call einzubauen, mit dem ich Real Mode Interrupts ausführen kann. Muss ich dazu wirklich einen extra vm86-task aufbauen? Wenn ich dass alles korrekt verstanden habe, führt der Task den Code aus, z.B. "int 0x10". Dann kommt durch den GPF der Kernel ins Spiel und emuliert diesen Interrupt.
Das würde aber doch heißen, dass ich diese Interrupts auch gleich emulieren kann. Sprich, ich bekomme über den System Call und die Register die Werte, z.B. eax=5, ebx=0x10, ecx=0x13. Es soll also der System Call 5 ausgeführt werden, der den Interrupt in ebx mit den Werten danach emuliert. Oder spricht da etwas dagegen, das gleich zu emulieren, anstatt erst auszuführen?

[kevin]

Ich glaube, du hast nicht ganz verstanden, was emuliert wird. Wenn du den kompletten Interrupt emulieren würdest, dann würdest du ja direkt einen Treiber schreiben - also kein Bedarf für VM86.

Was du wirklich machen willst, ist BIOS-Code auszuführen, weil das BIOS für dich einen Treiber bereithält. Das BIOS ist Real-Mode-Code, also brauchst du VM86, um es auszuführen. Gleichzeitig willst du ja nicht komplett die Kontrolle über den Rechner verlieren, deswegen darf der VM86 grundsätzlich erstmal nicht mehr als ein ganz normaler Usermode-Task im Protected Mode. Das heißt, du bekommst jedesmal einen GPF, wenn das BIOS eine privilegierte Instruktion ausführt, z.B. auf einen IO-Port zugreift. Diese Instruktion wird dann emuliert, anschließend geht es zurück in den BIOS-Code.

[ChristianF]

Dann habe ich das falsch verstanden.
Das würde dann bei mir so aussehen, dass es maximal einen Virtual 8086 Mode-Task gibt, der dafür zuständig ist, Interrupts aufzurufen, um z.B. die Auflösung zu ändern.
Dieser wird bei Bedarf per System Call generiert, ausgeführt und wieder gelöscht. Während dieser Zeit sind auch alle anderen Prozesse blockiert, damit der Interrupt ausgeführt werden kann.
 
Ich müsste also bei jedem GPF prüfen, ob der Virtual 8086 Mode-Task läuft und dann entweder die Instruktion ausführen (in,out,pushf,...) oder eben den Prozess, der diesen ausgelöst hat, entfernen...
 
Danke für die hilfreiche Antwort.