OSDev.org

Hi,

I have to say I'm pretty new to OSDev, so sorry if this is a really simple question. But I am trying to implement paging in my OS, which I have successfully done, or at least I loaded my page directory into the cr3 register without it crashing or throwing a page fault. I basically copied the paging code from the paging tutorial page, which I fully understand what it does other than the 4096 alignment.
I understand that pages are 4kib of memory and that a page table has 1024 pages, totalling 4mib and that we have 1024 page tables in the page directory totalling 4gib. We then load a pointer to the page directory into the cr3 register and enable the paging bit in the cr0 register to enable paging. But the part I'm confused about is actually using paging within my OS. Do I load my kernel into pages? What actually is page frame allocation? is it just allocating pages to locations in memory? and how does paging actually help me with my OS other than sort of sand-boxing programs to their own little address space?

Apologies again if this is simple or stupid, even after reading the OSDev wiki on paging and some of the related pages and even reading the 80386 programmers guide didn't really help me understand the concept.

Thanks in advance.

Hi,

lockyj wrote:I have to say I'm pretty new to OSDev, so sorry if this is a really simple question.

Paging is one of those things that isn't too obvious until it suddenly clicks.

lochyj wrote:I basically copied the paging code from the paging tutorial page, which I fully understand what it does other than the 4096 alignment.

There are several paging tutorials out there and some of them are riddled with bugs. There's nothing wrong with using them to get to grips with paging, but I'd advise you to implement your own paging code from scratch once you understand what needs to be done.

lockyj wrote:But the part I'm confused about is actually using paging within my OS. Do I load my kernel into pages?

Physical memory is divided into 4KiB chunks as you mentioned. These chunks, called page frames, are discrete units; you cannot just back a page with any 4KiB area, it must be a frame and therefore aligned to a 4KiB boundary.

Paging, as a mechanism, allows you to map virtual memory addresses to different physical memory addresses, with a 4KiB granularity (or more if you use large pages). To understand this, try not to think of memory as a series of bytes, instead think of it as a series of page frames in physical memory and a series of pages in virtual memory. Any page in virtual memory can map to any page frame in physical memory. The need for "alignment" comes from the fact that a page cannot be backed by the latter half of one frame and the former half of another.

When you can map virtual addresses to physical addresses, this allows you to make memory appear wherever you want. Your kernel will already be loaded in physical memory, but you can now remap it to another location in virtual memory, by backing those virtual pages with the corresponding physical frames. Most OSes map the kernel into the "higher half" of memory, typically at the 3GiB mark for 32-bit kernels (0xC000_0000). In order for it to run, your kernel will need to be present somewhere within your virtual address space.

lockyj wrote:What actually is page frame allocation? is it just allocating pages to locations in memory?

You have a finite resource, physical memory, that is just sitting there doing nothing. When a process (or the kernel) needs memory, your Physical Memory Manager needs to find some physical memory that is not in use and mark it as used, before handing it to your Virtual Memory Manager, which can then map it into whichever virtual address space needs it. How you implement this is up to you, but the wiki has some good methods.

lockyj wrote:and how does paging actually help me with my OS other than sort of sand-boxing programs to their own little address space?

Sandboxing is a huge benefit of paging, along with the protection paging can provide. You'll want to mark the pages your kernel resides in as supervisor pages to prevent user mode from accessing them.
Programs often leave gaps in memory that would be wasted if they used physical memory directly. With paging, you only need to allocate physical memory for the areas that are actually used. This can be done at runtime with demand paging, where you allocate pages when a page fault happens.

You can also map the same physical frames into multiple virtual pages, which is how the kernel is in every address space. This opens up the possibility for shared libraries and IPC via shared memory.

In decades prior, and still today on 64-bit architectures, paging allowed the OS to act like it had more memory than it actually did. Imagine you're on a machine with 128MiB of RAM, 0x800_0000 would be the top of your address space. With paging enabled, such a computer would be able to access all of the 32-bit address space, as long as it only consumed at most 128MiB of it, regardless of where those accesses are. If an application does need more memory than this, it's possible to save the contents of allocated frames to disk and to re-allocate the frames for another page, swapping the saved content back in when needed. This essentially causes RAM to act as a cache, and you can have as much memory as your hard drive can support, albeit at a much slower speed than real RAM.


Best of luck!

Another advantage of paging is that it lets you link programs to use a fixed memory address. As well as simplifying program loading this allows you to use the same code pages for multiple instances of a program with different data pages that appear to each instance to be at the same address. Not only does this reduce program load time but it can also reduce memory usage.

lochyj wrote:and how does paging actually help me with my OS other than sort of sand-boxing programs to their own little address space?

This sandboxing is important for stability if you're doing any sort of multitasking, and absolutely critical to security if the OS is going to be multi-user or network connected.