OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 12:12 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Yet another paging issue
PostPosted: Tue Apr 25, 2017 1:55 pm 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
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.


Attachments:
Zrzut ekranu z 2017-04-25 21-53-00.png
Zrzut ekranu z 2017-04-25 21-53-00.png [ 113.84 KiB | Viewed 3412 times ]
Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Wed Apr 26, 2017 1:32 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Szustarol wrote:
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.


Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Wed Apr 26, 2017 6:37 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
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:
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


Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Fri Apr 28, 2017 5:07 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
bump


Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Fri Apr 28, 2017 5:40 am 
Offline
Member
Member
User avatar

Joined: Tue Dec 25, 2007 6:03 am
Posts: 734
Location: Perth, Western Australia
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?

_________________
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc


Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Fri Apr 28, 2017 9:08 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
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


Attachments:
Zrzut ekranu z 2017-04-28 17-06-36.png
Zrzut ekranu z 2017-04-28 17-06-36.png [ 3.42 KiB | Viewed 3236 times ]
Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Fri Apr 28, 2017 10:01 am 
Offline

Joined: Sun Feb 26, 2017 4:42 pm
Posts: 16
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.


Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Sat Apr 29, 2017 12:35 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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.


Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Sat Apr 29, 2017 6:37 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
Okay, i have customised my paging, its now 2MB
this is my paging structure:
Code:
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:
    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:
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


Attachments:
Zrzut ekranu z 2017-04-29 14-36-32.png
Zrzut ekranu z 2017-04-29 14-36-32.png [ 578 Bytes | Viewed 3160 times ]
Top
 Profile  
 
 Post subject: Re: Yet another paging issue
PostPosted: Sat Apr 29, 2017 6:57 am 
Offline

Joined: Fri Mar 17, 2017 6:21 am
Posts: 20
i have just noticed my long mode function was wrong
changed it to:
Code:
        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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot], Octocontrabass and 96 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group