associating page tables with processes and kernel

[AndrewAPrice]

How does everyone associate page tables/directories with their processes and their kernel?

In my kernel, the kernel has a page table that has virtual address 0 to 4MB allocated to physical addresses 0 to 4MB.

My processes each have their own page directory (which can contain up to 1024 pages, but these pages aren't allocated until a process requests them). This page table is mapped to physical addresses 4 to 8MB.

To switch into another process's memory, in my kernel I can do it by:
memory.SetProcessPageTable(myProcess->GetPageTable());

The active process's page table is mapped into position 1 of the page directory and the kernel is always mapped into position 0.

This method is quiet reliable except for the simple fact that a process or the kernel can't be allocated more than 4MB (1 page table worth) of memory.

If your processes can have more than 1 page table associated with them, how have you gotten around this problem?

I thought about each process having a linked list of page tables, except each page table takes up a whole page in itself (this page will have to be allocated in kernel memory - and the kernel only occupies the bottom 4MB (a 1GB process would use up half the kernel's pages))..

[AJ]

Hi,

My PD is mapped to itself (this is done dynamically, but it is currently at 0xC0400000). Each process has a different PD and the PD of the currently running process always appears at that same location.

In this way, each task has 3GB of virtual RAM which is paged in as required. Page tables above the 3GB mark are common to all tasks, but are supervisor pages.

Cheers,
Adam

[AndrewAPrice]

Does the kernel have to be mapped into virtual memory? If it doesn't, it'll make things easier, but then how are interrupt handlers suppose to work if the interrupt code isn't in virtual memory?

[frank]

Generally the kernel has to be mapped into virtual memory. Most people map the kernel into each address space at the same location.

[AJ]

Hi,

This is how it works for me:

- When paging is set up, 0-3GB in the page directory is zeroed.
- Page tables are created (even if not needed yet) for the 3-4GB area. This 'wastes' 1MB of physical RAM.
- On new process creation, a new page directory is created, containing any user code / stack / heap somewhere in the lower 3GB (I tend to load binaries at 0x100000 but ELF and COFFs can be fixed up to wherever they were compiled for.
- The top GB (3-4GB area) is copied from the kernel page directory (or any other page directory - the top GB is the same in all of them, after all!).

This means that the kernel resides in all memory spaces in the same location. Suppose a page fault exception now occurs in the running user process. That exception will occur inside the current process space. This means that I can just page in to the current page directory as appropriate - easy!

I think the above reason alone is good enough reason to map the kernel in to each task space.

Cheers,
Adam