crash when loading PML4 to cr3 [paging]

[austanss]

I am working on getting paging done as a part of a larger memory management project.

I choose to just identity map.

I have written a page allocator, as well as a page table manager.

However, my OS resets without fault when I load PML4 into the cr3 register.

Source file where cr3 is loaded: https://github.com/microNET-OS/microCOR ... /kmain.cxx
Source file where general paging code is contained: https://github.com/microNET-OS/microCOR ... memory.cxx
Header file where paging structures are defined: https://github.com/microNET-OS/microCOR ... memory.hxx

Does anyone have any ideas?

[Octocontrabass]

Examine the contents of your new page tables right before you load CR3. Do the values make sense?

You can use a virtual machine to log which exception is occurring when the CPU resets. This might help you figure out where you need to look.

[austanss]

Examine the contents of your new page tables right before you load CR3. Do the values make sense?

You can use a virtual machine to log which exception is occurring when the CPU resets. This might help you figure out where you need to look.

That's the issue. There is no exception.

[Octocontrabass]

Yes there is. Why do you think there isn't?

[austanss]

Because my exception handlers didn't run.

[Octocontrabass]

The CPU can't find your exception handlers when your page tables are messed up.

[austanss]

I suppose that is a good point, I didn't think about that. Let me run QEMU with `-d int` and get back to you in 1-3 minutes.

[austanss]

QEMU -d int information (I don't know how to read this except for the registers):

Code: Select all

check_exception old: 0xffffffff new 0xe
    95: v=0e e=0010 i=0 cpl=0 IP=0008:0000000000100779 pc=0000000000100779 SP=0010:0000000000110fd0 CR2=0000000000100779
RAX=0000000000000108 RBX=00000000801d6000 RCX=0000000000002003 RDX=0000000000001000
RSI=000ffffffffff000 RDI=0000000000000000 RBP=000000001f0efe18 RSP=0000000000110fd0
R8 =0000000000000001 R9 =0000000000000030 R10=0000000000000017 R11=0000000000400000
R12=0000000000000014 R13=00000000801d6000 R14=0000000000000004 R15=000000001f0efe18
RIP=0000000000100779 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
CS =0008 0000000000000000 f0000fff 00af9a00 DPL=0 CS64 [-R-]
SS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
DS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
FS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
GS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     0000000000102341 00000017
IDT=     0000000000111040 00000fff
CR0=80010033 CR2=0000000000100779 CR3=0000000000001000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000801d6000 CCD=0000000000000000 CCO=SUBQ    
EFER=0000000000000d00
check_exception old: 0xe new 0xe
    96: v=08 e=0000 i=0 cpl=0 IP=0008:0000000000100779 pc=0000000000100779 SP=0010:0000000000110fd0 env->regs[R_EAX]=0000000000000108
RAX=0000000000000108 RBX=00000000801d6000 RCX=0000000000002003 RDX=0000000000001000
RSI=000ffffffffff000 RDI=0000000000000000 RBP=000000001f0efe18 RSP=0000000000110fd0
R8 =0000000000000001 R9 =0000000000000030 R10=0000000000000017 R11=0000000000400000
R12=0000000000000014 R13=00000000801d6000 R14=0000000000000004 R15=000000001f0efe18
RIP=0000000000100779 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
CS =0008 0000000000000000 f0000fff 00af9a00 DPL=0 CS64 [-R-]
SS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
DS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
FS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
GS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     0000000000102341 00000017
IDT=     0000000000111040 00000fff
CR0=80010033 CR2=0000000000111120 CR3=0000000000001000 CR4=00000668
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000801d6000 CCD=0000000000000000 CCO=SUBQ    
EFER=0000000000000d00
check_exception old: 0x8 new 0xe

Don't know how to read this information, like I said, but I assume 0xe is the exception code which would be page fault (makes sense)

The specific line of assembly where exception is thrown:

Code: Select all

  10076b:	48 8b 45 08          	        mov    0x8(%rbp),%rax
  10076f:	48 8b 15 d2 18 01 00 	mov    0x118d2(%rip),%rdx        # 112048 <_ZN6memory6paging5pml_4E>
  100776:	0f 22 da             	        mov    %rdx,%cr3                      //<-- inlined assembly from kernel_main
  100779:	48 8b 10             	        mov    (%rax),%rdx                   //<-- this line, but could be related to above line
  10077c:	48 89 15 7d 1a 01 00   	mov    %rdx,0x11a7d(%rip)        # 112200 <_ZN3gfx3gopE>

[xeyes]

Don't know how to read this information

It's easy, just read the v=<x> e=<y> part at the beginning as a starting point.

Code: Select all

v=0e e=0010

page fault, instruction fetch, page not present

Code: Select all

CR2=0000000000100779

Bonus info (not sure if applies to x64, at least on x86 this is the case), this is the virtual address of the faulted fetch

Code: Select all

v=08 e=0000

double fault, the ec for this one is always 0

So, indeed you want to double check your pagetable setup.

One way to check pagetable is to write a pagetable walker if you haven't, and use it to walk the faulted address before you set CR3. You probably need such a walker sooner or later anyways for debugging or for kernel's own use.

[austanss]

Don't know how to read this information

It's easy, just read the v=<x> e=<y> part at the beginning as a starting point.

v=0e e=0010

page fault, instruction fetch, page not present

v=08 e=0000

double fault, the ec is always 0 for this one so no other info

Thanks for that info, that's definitely useful.

I have a feeling this isn't a simple error...

[iansjack]

Unless something is overwriting your page table it should be a very simple error. As has been said many times, just inspect the page table to see whether it is what you expect (and check that what you expect is correct). It should then be easy to determine where you are going wrong. It's slightly more difficult if something is overwritng the constructed page table. In that case, set a watch on the memory location that is being overwritten to find out what bit of code is doing so.

[Gigasoft]

In Bochs you can easily see all page levels for a page using the "page" command, or you can show the entire page table with "info tab". In QEMU you can do the same thing with "info pg" and "info mem".