The Place to Start for Operating System Developers
http://f.osdev.org/
Code: Select all
EAX=00000011 EBX=00007d3c ECX=0000f000 EDX=0000830d
ESI=00000000 EDI=00000000 EBP=0008ffa0 ESP=0008ff90
EIP=00008505 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT= 0000b060 00000027
IDT= 0000b0a0 000007ff
CR0=00000011 CR2=00000000 CR3=0000d000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000Thank you. Our first note here is the values of EBP and ESP. Do your identity page tables cover memory up to 0x8XXXX (above 512KB)?BluCode wrote:Here are the register values before enabling paging:I could not figure out how to scroll the QEMU monitor, as ctrl+alt+pgup/pgdown didn't work, so I redirected it, but any input there would help as well.Code: Select all
EAX=00000011 EBX=00007d3c ECX=0000f000 EDX=0000830d ESI=00000000 EDI=00000000 EBP=0008ffa0 ESP=0008ff90 EIP=00008505 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 0000b060 00000027 IDT= 0000b0a0 000007ff CR0=00000011 CR2=00000000 CR3=0000d000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 EFER=0000000000000000 FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
Code: Select all
(gdb) x 0xD000
0xd000: 0x0000f007
(gdb) x 0xf000
0xf000: 0x00000007
(gdb) x 0xf03c
0xf03c: 0x0000f007
(gdb) x 0xf040
0xf040: 0x00000000The way you allocate your stack depends on your design philosophy, which is very subjective by its nature. But anyway, the problem here is that it is assigned a memory range that is higher than placement_address, in which case a PAGE FAULT will happen whenever your CPU tries to access the stack. Your identity maps should cover the stack as well, not just the kernel code and data.BluCode wrote:Given that my first (and only) page table only has 16 frames, I would think not.I set up the stack to be very far from the kernel, and therefore very far from placement_address (_end from the linker). Is that good or bad, and why?Code: Select all
(gdb) x 0xD000 0xd000: 0x0000f007 (gdb) x 0xf000 0xf000: 0x00000007 (gdb) x 0xf03c 0xf03c: 0x0000f007 (gdb) x 0xf040 0xf040: 0x00000000
Code: Select all
void switch_page_directory(page_directory_t *dir)
{
current_directory = dir;
asm volatile("mov %0, %%cr3":: "r"(&dir->tablesPhysical));
u32int cr0;
asm volatile("mov %%cr0, %0": "=r"(cr0));
cr0 |= 0x80000000; // Enable paging!
asm volatile("mov %0, %%cr0; jmp .":: "r"(cr0)); // <-- can you see it? :D
}
Code: Select all
void switch_page_directory(page_directory_t *dir)
{
current_directory = dir;
asm volatile("mov %0, %%cr3":: "r"(&dir->tablesPhysical));
u32int cr0;
asm volatile("mov %%cr0, %0": "=r"(cr0));
cr0 |= 0x80000000; // Enable paging!
asm volatile("cli; mov %0, %%cr0; jmp .":: "r"(cr0)); // <-- disable interrupts; store cr0, then jmp forever.
}
According to the values of EBP and ESP, it seems that the stack (at the moment of setting cr0) is at 0x8FFFF, not at 0x7BFF. I suggest you check it out. We can conclude now that infinitely recursive page fault (IRPF) leads to CPU reset. However, I am still not sure about it. Needs more digging.BluCode wrote:It works! Turns out I just wasn't mapping enough of ram, even though the stack is under the kernel, and so was mapped. I tried disabling interrupts before enabling and that worked, but then I re-looked over my code and it turned out that my stack was at 7BFF and my kernel started at 7E00. Anyways I just identity mapped up to 16MB and now its working. Thanks for all your help!