Yet another paging issue

[Szustarol]

Hi!
My first page is mapped right, but remaining are not. I need more than 1gb mapped to acces linear framebuffer.
Please refer to the attachment. should be self-explanatory
Thanks for any help.

[iansjack]

Please refer to the attachment. should be self-explanatory

I'm afraid that it isn't.

It might help if you were to state what your problem is (and maybe show a small amount of the appropriate code - but don't paste pages of code, please, as that tends to be a turn off).

Whatever the problem is, have you examined the page table in memory to see if it looks correct? If not it should be fairly obvious what is wrong, and you then just need to determine why that is happening. Often you will find that once you state the problem clearly the cause becomes obvious. If not, single-stepping through the relevant code can work wonders.

[Szustarol]

So i just want my pages mapped one gigabyte after another.
First page maps 1 gb correctly - from 0 to 0x40000000
i create second page and make the physicall address start at 0x40000000 - to map another GB, sadly as you can see on the image it maps from
0x8000000000 instead of 0x40000000
here is the paging itself:

Code: Select all

align 4096 ;;align to 4 KB
    PML4:
        dq 0 or 1b or 10b or PDP;;present bit, r/w bit
        dq 0 or 1b or 10b or PDP
        dq 0 or 1b or 10b or PDP
        dq 0 or 1b or 10b or PDP
        dq 508 dup(PDP or 10b)
    PDP:
        dq 0 or 1b or 10000000b ;;dq zero, because we map memory from start so 0x0000, present bit
        dq 0x40000000 or 1b or 10000000b
        dq 0x80000000 or 1b or 10000000b
        dq 0xc0000000 or 1b or 10000000b
        ;dq 0x40000001 or 1b or 10000000b
        ;;PDPE.PS to indicate 1gb pages
        dq 508 dup(10000000b)

sorry for not specifying what the problem is

[Szustarol]

bump

[thepowersgang]

The four entries in `info mem` come from the four copies of `PDP` in the PML4.

`info mem` doesn't show you the virtual->physical mappings, just what regions exist. To get a dump of the mappings, use `info tlb`

I'm not sure why it's seemingly not using the other entries in the PDPT, a guess is that maybe you didn't recompile correctly?

[Szustarol]

Okay, this is actually even more weird.
I seriously have no idea why does it work like this,
and why the first region and any other seem to have 0 bytes.
Also, you said info mem is about existing regions- if i do not mark my PML4 pointer as active (for example
i have 509 blank entries instead of 508), amount of regions changes to 3- so it certainly has something to do with paging

[x64dev]

Could this be getting corrupted from elsewhere? Are you able to verify it immediately after you've set it up?

I tested the way you're setting the PDPTE by using a structure which maps the bits to their actual positions in a PDPTE just to make sure there wasn't a issue with the values specified and these worked as expected (I stepped through in the debugger to confirm). So either the code hasn't been built lately and is showing something earlier, or some other code is overwriting the entries after the table is setup.

So you likely want to confirm if this is correct immediately after setting it up and if it is somehow changed later.

I haven't yet taken the code and put it in a user-mode assembly program to verify that it works as expected, but you may want to do that too.

I also think that there's something wrong with the way you're or'ing PDP into the value since that should set all 4 to the first entry. I'd think you'd probably want to do PDP, PDP + 8, PDP + 16, PDP + 24 to get all the correct values in.

[iansjack]

Some comments (although I don't think any of them explain the results you are getting)

1. Your PML4 only needs one entry (unless you have more than 512GB of RAM), assuming you are aiming for identity mapping, pointing to the single PDP. This will contain an entry for each GB that you wish to map.

2. I'd suggest that you are missing many benefits of paging by identity mapping.

3. Although you don't show this, I presume that your code checks that the processor supports 1GB pages. This is greatly limiting the range of processors that your code runs on.

4. I think you should reconsider whether 1GB pages are a good solution. Using a smaller page size will give you far greater flexibility, let your code run on a a bigger range of processors, and allow you to use RAM more efficiently. Your current plan effectively rules out separate address spaces per task, which is a big restriction.

My advice would be to go back to basics and reconsider your strategy so that you can make best use of paging.

[Szustarol]

Okay, i have customised my paging, its now 2MB
this is my paging structure:

Code: Select all

align 4096
PML4:
    dq PDPT or 11b
    dq 511 dup (PDPT or 10b)
PDPT:
    dq 11b or PDP
    dq 11b or PDP2
    dq 11b or PDP3
    dq 11b or PDP4
    dq 11b or PDP5
    dq 11b or PDP6
    dq 11b or PDP7
    dq 11b or PDP8
    dq 504 dup(10b)
PDP:
    dq 512 dup(0x82)
PDP2:
    dq 512 dup(0x82)
PDP3:
    dq 512 dup(0x82)
PDP4:
    dq 512 dup(0x82)
PDP5:
    dq 512 dup(0x82)
PDP6:
    dq 512 dup(0x82)
PDP7:
    dq 512 dup(0x82)
PDP8:
    dq 512 dup(0x82)
;;MAPPING 8GB of RAM

thats how i fill first PDP in 32 bit mode:

Code: Select all

    mov ecx, 0
    .lp1:
        mov ebx, [PDP + ecx*8]
        mov eax, 0x200000
        mul ecx
        or ebx, eax
        or ebx, 1
        lea eax, [PDP + ecx*8]
        mov [eax], ebx
        inc ecx
        cmp ecx, 512
        jl .lp1

and remaining 7 GBs in long mode:

Code: Select all

mov r8, 1
        .lpp2:
            mov rcx, 0
            .lp2:
                mov rbx, [PDP + rcx*8]
                mov r10, rcx
                imul r10, 4096
                or rbx, r10
                mov rax, 0x200000
                mul rcx
                mov r10, 0x40000000
                imul r10, r8
                add rax, r10
                or rbx, rax
                or rbx, 1
                lea rax, [PDP + ecx*8]
                mov r10, rcx
                imul r10, 4096
                or rax, r10
                mov [rax], rbx
                inc rcx
                cmp rcx, 512
                jl .lp2
            inc r8
            cmp r8, 8
            jl .lpp2

info tlb maps memory to 0x3fe00000
info mem brings back attachment


something is really wrong here and i am not sure what, could you guys provide any help?
it seems to be no difference if i remove the 64-bit paging fill code, same as before with 1GB pages

[Szustarol]

i have just noticed my long mode function was wrong
changed it to:

Code: Select all

        mov r8, 1
        .lpp2:
            mov rcx, 0
            .lp2:
                mov r9, r8
                imul r9, 4096
                mov r10, rcx
                imul r10, 8
                add r9, r10
                lea r10, [r9 + PDP];;entry address
                mov r11, [r9 + PDP];;value to save
                or r11, 1;;active
                mov rax, 0x200000
                imul rax, rcx
                mov rbx, 0x40000000
                imul rbx, r8
                or rax, rbx
                or r11, rax
                mov [r10], r11
                inc rcx
                cmp rcx, 512
                jl .lp2
            inc r8
            cmp r8, 8
            jl .lpp2

and it seems to work now