OSDev.org

I think I understand most of it, but I'm just having trouble with one thing - if I'm only running the kernel (I.E. no other processes) and the memory is mapped 1:1 physical:virtual, there should be no difference between having paging enabled and not enabled, right?

I know there's a ton of paging questions here, sorry for adding one more!

If paging is enabled then there wil be permission checks, even for a one-to-one mapping.

Oh, right. But since everything running is in kernel-space, I still won't see a difference between paging and no-paging, right? Even though permission checking is happening behind the scenes?

Depending on the processor, if you write to a read-only page, or access an address that isn't mapped, or execute on a non-executable page then there is a difference.

If paging is enabled there is the possibility of a page fault.

Alright, that answers my question thank you

Unwritable pages cause a pagefault when written in ring3, and they do in ring0 as well depending on what the WP bit was set to. (Something tells me there was a caveat with the writeprotect bit but I can't recall what it was)

Right, that makes sense.

I thought I had everything setup alright, but now I'm not so sure. How can I test that paging is set up correctly? I've checked the CR3 register via Qemu's command line and it does have the correct physical address for my page directory. But when I try writing to some memory that should be read-only, it just gets written like normal. That means I set something up incorrectly, right?

Luns wrote:Right, that makes sense.

I thought I had everything setup alright, but now I'm not so sure. How can I test that paging is set up correctly? I've checked the CR3 register via Qemu's command line and it does have the correct physical address for my page directory. But when I try writing to some memory that should be read-only, it just gets written like normal. That means I set something up incorrectly, right?

Try reading more on the Write Protect bit in CR0.

Regards,
Shikhin

The WP bit is set in CR0 - according to the manuals, this means supervisor code cannot write to addresses with read-only access.

I checked the mappings with 'info mem' and sure enough, nothing I thought I was setting to read-only was actually being set to read only... I'll have to fiddle with my code for a bit. I made a bunch of upper memory set to read only though, and writing to that did cause a page fault! So I think once I'm setting everything to the correct permissions, I'll be good to go.

Thanks very much for the help!

Did you try invalidating TLB entries before using them?

No, is that something that needs to be done? I'm quite certain the code I use to assign access modes (r/w or just r) to page table entries is incorrect, but if I need to invalidate everything first before assigning page table entries then that would be another problem with my code...

If the CPU could have been informed where your pagetables are before you set the read-only part, then yes it's possible that it saw them as writable and treat them as such afterwards. If that possibility exists, depends on how your code is written (it involves changing writable pages to non-writable ones while paging is active).

Alright, that makes sense.

After quite a few hours, I believe I now have paging enabled correctly. Thanks everyone for the help

Sorry to double post, but I have a new, somewhat related question that I thought outta go here rather than it's own topic - I'm trying to map my kernel to the 0xC0000000, and I'm not sure if I'm doing it correctly. I map my kernel (at physical 0x00100000) to 0xC0000000 using a method similar to the one on the Paging wiki page. Then I look at a few bytes of memory at 0x00100000 and 0xC0000000, and it's all the same. So does that mean I've successfully mapped my kernel to 0xC0000000? Can anyone tell if I'm missing something?

Thank you!

e: A thought - is there any reason to map the kernel to a different address in the kernel's own page directory? I understand why you would do it in a process's page directory, but not really why it's useful to the kernel process.

Hi,

Luns wrote:Sorry to double post, but I have a new, somewhat related question that I thought outta go here rather than it's own topic - I'm trying to map my kernel to the 0xC0000000, and I'm not sure if I'm doing it correctly. I map my kernel (at physical 0x00100000) to 0xC0000000 using a method similar to the one on the Paging wiki page. Then I look at a few bytes of memory at 0x00100000 and 0xC0000000, and it's all the same. So does that mean I've successfully mapped my kernel to 0xC0000000? Can anyone tell if I'm missing something?

Seems like it's at least partially correct - you could check the entire kernel rather than a few bytes, and check the permissions are right (e.g. try to write to something that should be "read only", try to execute something in that should be "no execute", etc).

Luns wrote:e: A thought - is there any reason to map the kernel to a different address in the kernel's own page directory? I understand why you would do it in a process's page directory, but not really why it's useful to the kernel process.

If you have the kernel mapped to 0xC0000000 when a process is running, then you must've compiled the kernel so that it expects to be mapped at 0xC0000000. When a process isn't running and the kernel is using its own page directory, you want to use the same kernel (and not recompile it with a different linker script or whatever so that it can run at a different address, and then have 2 versions of the same kernel at the same time, one for each virtual address).

You also want to use the CPU's "global pages" feature - make sure all of the kernel's pages are the same in all address spaces (regardless of whether it's a process' address space or the kernel's address space), then set the "global" bit for those pages, so that the CPU doesn't have to flush the kernel's TLB entries when you change address spaces. This improves performance (avoids unnecessary TLB misses when you switch virtual address spaces). You end up with "user space" (which may be unused when the kernel is using its own page directory) that isn't "global", and "kernel space" that is "global". Note: this is "all the kernel's pages", not just the kernel's ".text, .data, .rodata and .bss" - typically a kernel will dynamically allocate more RAM for things while it's running.

The 1:1 physical:virtual mapping that you did to begin with is mostly just a convenience during boot - you'd discard it once the kernel is running in its proper place. Some (most) OS's don't even both with a 1:1 physical:virtual mapping - just map the kernel at 0xC0000000 and identity map 1 page (that contains the code that enables paging and jumps to the kernel at 0xC0000000) - it means you need to do less work setting it up, and less work discarding it once the kernel is running in its proper place.


Cheers,

Brendan