Bochs "physical adress not available" after enabeling paging

[Nezmar]

Hi,

I am currently trying to implement paging for user processes.
I have already successfully identity paged the first 4 MB to the kernel.

When creating a new process I:

Request a new page for the kernel
load the process to that new page
load a loader function on top of the process code that will reload cr3 with the processes page directory pointer and jump to the entry label of the process.
I then create a new page directory for the process which contains just one table with one page (the one the process is loaded on) mapped to 0x0 virtual address.
Finally i jump to the loader function.

However, right after loading the page dir. to cr3 i get a "physical adress not available" from bochs and the system reboots.

Code: Select all

<bochs:14> s
Next at t=538301714
(0) [0x000000400027] 0008:0000000000400027 (unk. ctxt): mov cr3, eax              ; 0f22d8
<bochs:15> s
Next at t=538301715
(0).[538301715] ??? (physical address not available)
<bochs:16> info tab
cr3: 0x000000106000
0x0000000000000000-0x0000000000000fff -> 0x000000400000-0x000000400fff
<bochs:17> r
CPU0:
rax: 00000000_00106000
rbx: 00000000_00000000
rcx: 00000000_00104f84
rdx: 00000000_00000002
rsp: 00000000_00104ef8
rbp: 00000000_00102208
rsi: 00000000_00000002
rdi: 00000000_0002cf09
r8 : 00000000_00000000
r9 : 00000000_00000000
r10: 00000000_00000000
r11: 00000000_00000000
r12: 00000000_00000000
r13: 00000000_00000000
r14: 00000000_00000000
r15: 00000000_00000000
rip: 00000000_0040002a
eflags: 0x00000206: id vip vif ac vm rf nt IOPL=0 of df IF tf sf zf af PF cf
<bochs:18> s
(0).[538301715] ??? (physical address not available)
Next at t=538301716
(0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b          ; ea5be000f0

Is there anything i should check? Or do I have to always enable paging from an identity mapped process?
Thanks for any suggestions.

[iansjack]

Sounds like your page directory is invalid.

But without seeing your code it’s just shooting in the dark.

[Nezmar]

The directory is at 0x106000 the firs entry has the value of 0x105007 and all other are initialized to a value of 0x6. The firs entry of the page table has the value of 0x400007 and all others are 0x6.

The info tab runs correctly no?

If you think it would help I can provide code examples but I am not sure what part of it would help.

[Octocontrabass]

You only mapped one page at virtual address 0, but your loader function is at virtual address 0x400000. Your loader function unmaps itself!

[Nezmar]

You only mapped one page at virtual address 0, but your loader function is at virtual address 0x400000. Your loader function unmaps itself!

It is true that it is at the virtual address 0x400000 in the kernels page directory, but that means that it is also at the same physical address, since all pages of the kernel are identity mapped.

In fact I have tried first disabling paging completely, jumping to the loader func and then re-enabling it but got the same result.

[Nezmar]

Although I am a little ashamed of some of my code here is the repo if anyone would want to look into it: https://github.com/nezmar48/osp/tree/13-paging

Note that I lied and I give one more page to the os in the code, but I have tried it modified with just one page with the same result.

[iansjack]

But do you have an entry for 0x400000 and subsequent pages in your page table?

You’ve mapped page 0 to physical address 0x400000 (why) but what about virtual address 0x400000?

[Octocontrabass]

In fact I have tried first disabling paging completely, jumping to the loader func and then re-enabling it but got the same result.

Your loader function is at virtual address 0x400000 and you don't have anything mapped at virtual address 0x400000. What are you expecting the CPU to do when that happens?

[Nezmar]

Your loader function is at virtual address 0x400000

My loader function is at physical address 0x400000 which is mapped to 0x0 by the processes page dir. It is at that virtual address in the kernels page dir. But that is either disabled beforehand, or replaced with the processes dir at the moment the error occurs.

What I would expect the CPU to do if the virtual address was not mapped is to throw a page fault.

[Nezmar]

But do you have an entry for 0x400000 and subsequent pages in your page table?

You’ve mapped page 0 to physical address 0x400000 (why) but what about virtual address 0x400000?

I only have one page (page 0) with the value 0x400007.

How i understand it is that the page 0 corresponds to the virtual adress 0 right? So if I map the adress 0x400000 (which is the address my loader function and the processes code itself is at) and enable paging the from the perspective of the loader function it should be at address 0. Now, there is not actually anything that the process wants that is at virtual address 0x40000 since it is very small and it needs just one page.

[iansjack]

According to your register dump, the program is executing at 0x40002a. If there is no mapping for that virtual address all bets are off. Who knows what physical address it is trying to access.

Things are fine until you enable paging. As you say, virtual address 0 then corresponds to physical address 0x400000. But your program is still executing at (now virtual) address 0x40002a - and that, you say, is not mapped. Boom!

[Octocontrabass]

What I would expect the CPU to do if the virtual address was not mapped is to throw a page fault.

It does throw a page fault. When it tries to handle the page fault, it encounters another page fault. When it tries to handle that page fault, it encounters a third page fault and shuts down. The chipset detects the shutdown and resets the CPU.

So if I map the adress 0x400000 (which is the address my loader function and the processes code itself is at) and enable paging the from the perspective of the loader function it should be at address 0.

How is the CPU supposed to know that your loader function moved to a different address?

[Nezmar]

But does the cpu not translate the next instruction pointer when enabling paging?

Before enabling paging the next instruction should be at 0x400027 the next instruction I would expect to be executed is at 0x40002a. I would expect this to now correspond to the virtual address 0x2a.

The loader function is nothing complex the:

Code: Select all

align 4
loader_func:
    lea ebp, [rel loader_func_end + 0x1000] ;this does not work (points to initial position)

    mov eax, [esp + 4]      ; page dir 
    mov ebx, [esp + 8]      ; Load entry label address
    mov ecx, [esp + 12]     ; Load args array pointer
    mov edx, [esp + 16]     ; Load size (number of arguments)

    mov cr3, eax

    mov eax, edx
.loop:
    cmp eax, 0
    je .call
    dec eax
    push dword [ecx + eax * 4]
    call ebx
loader_func_end:

[Octocontrabass]

But does the cpu not translate the next instruction pointer when enabling paging?

It does not.

[Nezmar]

Oh, that could be the problem.
How am i supposed to do it then?
Does the loader just need to be identity paged?