Page 1 of 1
Yet another paging issue
Posted: Tue Apr 25, 2017 1:55 pm
by 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.
Re: Yet another paging issue
Posted: Wed Apr 26, 2017 1:32 am
by iansjack
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.
Re: Yet another paging issue
Posted: Wed Apr 26, 2017 6:37 am
by 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
Re: Yet another paging issue
Posted: Fri Apr 28, 2017 5:07 am
by Szustarol
bump
Re: Yet another paging issue
Posted: Fri Apr 28, 2017 5:40 am
by 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?
Re: Yet another paging issue
Posted: Fri Apr 28, 2017 9:08 am
by 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
Re: Yet another paging issue
Posted: Fri Apr 28, 2017 10:01 am
by 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.
Re: Yet another paging issue
Posted: Sat Apr 29, 2017 12:35 am
by 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.
Re: Yet another paging issue
Posted: Sat Apr 29, 2017 6:37 am
by 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
Re: Yet another paging issue
Posted: Sat Apr 29, 2017 6:57 am
by 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