Having trouble mapping multiple PML4 pages at boot time.

[minater247]

Recently I decided it was time to move my kernel to the higher regions of memory, and was able to successfully move it up to the 3GB region as I had done with 32-bit paging using the organization here (NASM code):

Code: Select all

section .data
align 4096 ; align to page size
global BootP4
global BootP3
global BootP2
global BootP1

PAGE_PRESENT equ 1
PAGE_WRITABLE equ 2
ENTRIES_PER_PT equ 512

BootP4:
    dq (BootP3 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq ENTRIES_PER_PT - 1
BootP3:
    dq (BootP2 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq 2
    dq (BootP2 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq ENTRIES_PER_PT - 4
BootP2:
    dq (BootP1 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq ENTRIES_PER_PT - 1
BootP1:
    %assign i 0
    %rep ENTRIES_PER_PT
        dq (i << 12) + (PAGE_PRESENT | PAGE_WRITABLE)
        %assign i (i+1)
    %endrep

So of course, the next step is since I'm in 64-bit mode, I move it up to 0xFFFFFFFF80000000. I started trying to map different places to search out which PML4 entry it should be placed in, but... nothing. It for whatever reason just doesn't want to map any other addresses in the PML4. Here's the code for the table now:

Code: Select all

BootP4:
    dq (BootP3 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq 4
    dq (BootP3 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq ENTRIES_PER_PT - 6
BootP3:
    dq (BootP2 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq ENTRIES_PER_PT - 1
BootP2:
    dq (BootP1 - 0xC0000000) + (PAGE_PRESENT | PAGE_WRITABLE)
    resq ENTRIES_PER_PT - 1
BootP1:
    %assign i 0
    %rep ENTRIES_PER_PT
        dq (i << 12) + (PAGE_PRESENT | PAGE_WRITABLE)
        %assign i (i+1)
    %endrep

So entries 0 and 5 should both point to 0x00000000, but in fact, nothing changes. It still maps the first entry in the PML4, but nothing else is mapped. No matter if I set it to map entries 0 and 1, 0 and 200, 0 and 511, nothing changes in the memory map. Here's what I'm getting through testing with Bochs (memory printed as 64-bit):

<bochs:5> info tab
cr3: 0x00000010c000
0x0000000000000000-0x00000000001fffff -> 0x000000000000-0x0000001fffff
<bochs:6> xp/10xg 0x10c000
[bochs]:
0x000000000010c000 <bogus+ 0>: 0x0010d003 0x00000000
0x000000000010c010 <bogus+ 16>: 0x00000000 0x00000000
0x000000000010c020 <bogus+ 32>: 0x00000000 0x0010d003
0x000000000010c030 <bogus+ 48>: 0x00000000 0x00000000
0x000000000010c040 <bogus+ 64>: 0x00000000 0x00000000

...and that looks right to me? Every 64-bit entry is either zeroed out (not present) or pointing to the same PML3. So both should map the same address range, right? The address at ~2.5TB should be mapped to the same location as 0, since they both point to the same PML3/PDPTE. I'm honestly stumped on this one, as it looks like I'm doing exactly as the manual says I should do - although I am pretty new to this type of paging. Any help would be much appreciated!

[Octocontrabass]

Which version of Bochs are you using? Some versions have a bug in "info tab" that hides any mappings with virtual addresses above 4GB.

[minater247]

Had a bit of a scare with the computer I was programming all this on quitting but now that it's back and I can test, that was pretty much the answer! I'm on v7.0, and it seems like it had just cached the previous tables? But after testing in QEMU and doing some further work in bochs it appears that there was in fact no problem at all! Thank you very much for the help!

[Octocontrabass]

I'm on v7.0,

Huh? There is no Bochs v7.0.

and it seems like it had just cached the previous tables?

If it's the bug I'm thinking of, it just stops printing information when it reaches virtual address 0xFFFFFFFF. The page tables are still there and still work.

But, if you're actually using Bochs 2.7, you might have a memory corruption bug.