OSDev.org

I am trying to implement paging in my OS, but as soon as I set the paging bit of cr0, the OS crashes. I am following James Molloy's tutorial but I can't get it to work. When I follow the tutorial on the osdev wiki here it works fine, and I don't understand paging enough to debug it (yet). When I use gdb here is what I get:
At which point if I continue, QEMU resets.

My paging.c file: https://hastebin.com/akequpexij.cs
Can anyone see what I am doing wrong?

I just quickly scanned your code as I don't have much time right now, and I'm more sleepy than awake, but it's worth nothing that all paging structures must be physical addresses and aligned to 4 KB (4096 bytes). In short, it means that the hexadecimal address should always have the lowest three digits zero (i.e. 0x1000, 0x2000, 0x7A8000, etc.) I see you are using kmalloc to allocate the page directory - how does your kmalloc work? My wild guess says your kmalloc doesn't return page-aligned addresses.
Also, why are you hard-coding the amount of memory as 16 MB? If you are using a multiboot-compatible boot loader (like GRUB,) you have the memory map information passed to you.
As a better debug technique for debugging paging, try to stop right before you set bit 31 of CR0 register, and dump all page related structures/registers, including CR3, the complete page directory and the complete page tables.

My kmalloc_a function returns an aligned address always. I am hard coding the amount because I am using my own bootloader and don't know how to get that info myself. Could you elaborate on what commands I should use to dump all of that?

Stop the code just before you enable paging. (asm("jmp .") will do the job), and then type "info mem" in the qemu monitor. This will show you which address ranges are mapped in your page directory. You should also examine your page tables (use the "print" or "x" commands in gdb or the "x" command in the qemu monitor) to see if they look right. Once you see what is wrong with them it should be possible to work out where your error is.

Since you already use gdb you don't need to add any "jmp .", you can just single step (as you were doing) and check the paging stuff from Qemu, once the CR3 is set.

As for getting the memory info, see the wiki:
http://wiki.osdev.org/Detecting_Memory_(x86)#BIOS_Function:_INT_0x15.2C_EAX_.3D_0xE820

It's much more efficient to put judicious halts into a program rather than having to single-step through all the instructions up to the point of interest. Alternatively, you can set breakpoints at the appropriate places. If you're going to run the program, up to a certain point, a number of times an inserted halt is the most efficient solution.

To each their own, I guess. I find using breakpoints and single stepping far easier and faster. It allows me to dynamically inspect what I want, instead of modifying the code all the time and recompiling to move the infinite-loop "breakpoint".

I, (hopefully) obviously, wasn't suggesting single stepping 1MiB executable for the first 500k steps =)

After doing some testing here is what I get:

Which leads me to believe that for some reason it isn't paging enough of the memory, but I don't really know. When I use x in gdb to inspect the page tables at 0x0000, 0x1000, 0x2000 etc I get very different results for each. I hope you can do something more with this info.

You have a number of subtle bugs. First:



Setting user/supervisor bit sets user mode, not the other way around.



Again, this sets user mode.

I have a feeling that you copy/pasted some of James Molloy's code which contains gotchas for the unobservant.

As I understand it, that code means that if is_kernel is true, the value will be zero, and if not it will be 1, which is correct.



And what is the issue with setting user mode? Would that cause the kernel to reset? According to the wiki 'If the bit is set, then the page may be accessed by all' so that shouldn't be a problem.

Yes I am reusing his code, but as far as I can tell what you pointed out won't have a significant effect.

The very same page you referenced says "Therefore if you wish to make a page a user page, you must set the user bit in the relevant page directory entry as well as the page table entry.". Also it's clear from your page directory* that somehow the flags are getting screwed up (0x5 implies the RW bit is cleared).

I see, do you have any idea as to how I can fix my flags? I'm afraid that I really don't have much idea what I'm doing here yet.

Hi!

I'd like to leave several notes that might help you with your issue.

First, what is the value of cr3? gdb printout suggests that the value of "kernel_directory" variable is 0x0000C000:


Looking at your code, it seems to me that kernel_directory points to a data structure that contains, at least, these two arrays:

• An array that stores the virtual addresses of your allocated page tables (called tables[]).
• An array that stores page entries to your page tables (called tablesPhysical[]).

The second array is what we call a page directory. Each page entry consists of flags + physical address of a page table. If you go to that page table, you shall find other 1024 page entries that actually point to actual memory frames. Each page entry consists of flags + physical address of an actual memory frame.

However, there seems to be some confusion in the comments above...


This peaceful line of code sets the flag of an entry in the page directory, not page table. However, you are referring to the part of the wiki article that talks about page table entries, not page directory entries:


So, if I understand your code correctly, I expect that your page directory actually contains one entry [at index 0]: 0x0000F007. It obviously points to a page table at 0x0000F000, and the flags PRESENT, RW, and US are all set (and it's OK).

Now if we go to your page table at 0x0000F000, we should see entries to actual memory frames. This is related to line 159:


You pass 0 and 0 to alloc_frame(), which means: set US but please don't set RW. Thus, you will have only US and PRESENT flags set [i.e, 0x05]:


This seems sensible to me. If the flag of your first page directory entry is 0x7 and the flags of your page entries are 0x5, then your US flag is actually set correctly.


In my point of view, your flags are OK.

So how can we make sure that the flags are set correctly? print the value of cr3, not kernel_directory variable. I believe (according to your gdb outputs) that kernel_directory points to 0xC000, which is the base for a data structure that holds the two arrays explained above. It seems to me that the first array (the virtual addresses of page tables) is actually based at 0xC000, while the second one might be at 0xD000 or 0xE000. We want this second one.


^ This prints the first entry of kernel_directory->tables[] (the first array). We actually want the first entry of kernel_directory->tablesPhysical[] (the second array), since this actually what your processor sees and translates as a page directory. Remember how you have loaded cr3:


-----------------------------------------------

Now let's move to another point...




Could you please check the value of "placement_address" variable?

Wow, thanks for all that. Could you please clarify this sentence as you say page entry twice with different meanings?


placement_address has a value of 65535 before paging is enabled, and cr3 is set to 0x0000D000.

I also get this when looking at 0xD000:


Which seems to suggest that there is only one table mapped, at 0xF000, which when read gives 0x00000005, as before. Thanks again for your help.

Sorry for not choosing the keywords precisely. The entries of page directory should be called 'page directory entries', and the entries of a page table should be called 'page table entries'. These are actually the terms used in the original intel 80386 programmer's reference manual (1986), which also uses the shortcuts 'DIR ENTRY' and 'PG TBL ENTRY' for both terms, respectively.