Physical MM is "below" paging.. or is it?

[lambert]

Hi,

From what I've read in some threads and tutorials, there's 3 basic levels of memory management:
1. Physical (is it like Windows's MmAllocateContiguousMemory()?) -- it allocates memory pages memory "below" paging.
2. Virtual (like NtAllocateVirtualMemory()) -- it allocates virtual memory and maps it to physical memory, but still in whole pages.
3. Process-level (like malloc()) -- it allocates virtual memory and manages that piece with smaller granularity.

However, what I do not understand is: Once paging is enabled, how can you possibly execute code "below" it? Does that mean that whenever someone calls MmAllocateContiguousMemory() in Windows, for example, Windows temporarily modifies CR0 to disable paging, allocates the page, and then re-enables CR0? It just doesn't make sense to me (because of how slow it could get, etc.), but it also doesn't make sense to me for the OS to not be able to bypass virtual memory either (since it needs to work with DMA and all that)... so how could I implement a physical MM and bypass paging? Or am I misunderstanding this?

Thanks!

[garob]

Your physical memory manager keeps track of which pages of physical memory are used, your virtual memory manager will call the physical manager which will mark a page as used in whatever data structure it uses and return which memory location has been marked as used. Your virtual memory manager will then store the physical address returned in a page table entry.

The gist of this is that your physical memory manager will use a data structure in virtual memory which you will of course set up yourself, see here for examples: http://wiki.osdev.org/Page_Frame_Allocation

[xenos]

No, physical memory memory management is not "below" paging in the sense you write in your post. In other words, paging does not make physical MM unnecessary. Instead, physical MM is a necessary ingredient for paging.

Everything the paging mechanism does is mapping physical memory pages into the virtual address space. But is does not know anything about the physical pages it maps - whether they are filled with any code or data, who own them, whether they are already mapped by a different process... The physical MM needs to keep track of this information and guarantee that only free, unused pages are mapped into virtual address space when a process requests more memory, and that pages which are not longer used are marked as unused.

The virtual MM operates on top of the physical MM. So if a process requests 64kb more memory in virtual address space, the virtual MM requests 16 pages of 4kb each from the physical MM, which are then mapped into virtual address space. It does not care where in physical memory these pages are located or whether they are contiguous - it simply takes what it gets from the physical MM.

Process MM is typically built on top of this whole mechanism. Each process reserves some region in virtual address space called the "heap". Functions like malloc() reserve some space on this heap and mark it as used. When the process requests more memory than it has free heap space, the process MM asks the virtual MM for more heap space.

[lambert]

Ah... so I'm understanding that ultimately, once paging is turned on, it's never needed to be turned off again, correct? Since the physical MM can just use virtual addresses to access the critical data structures anyway, so long as it has the right permissions.

[xenos]

Ah... so I'm understanding that ultimately, once paging is turned on, it's never needed to be turned off again, correct? Since the physical MM can just use virtual addresses to access the critical data structures anyway, so long as it has the right permissions.

That's right - paging will never have to be turned off again. It allows a nice trick for accessing the paging structures: For example, using IA32 paging with 4kb pages, each virtual address space has a 4kb page directory. The PD has 1024 entries, each of which can either be empty or point to a page table, which has the same structure as the PD. A PT has 1024 entries, each of which points to a physical page to be mapped. The trick is to make the last entry of the PD point to itself, i.e. use the PD as the last PT. This means that every entry of the PD not only selects a PT, but also maps this PT to some address in the range 0xFFF00000 - 0xFFFFFFFF (this is the region where the last PT points to). In other word, the paging data structures can always be found at the same virtual address using this trick, which makes life very simple.

[lambert]

That's a cool trick; I just managed to get it to work in my kernel! Thank you!!

[inx]

This actually sort of depends. For example,the PowerPC spec specifies that at the beginning of exception handlers, all memory translation is disabled. Some systems (e.g. NetBSD) immediately restore paging, others (I would imagine) take advantage of the situation. Further, NetBSD gets a little weird with its exception handling on PPC: the kernel has its own context that is switched to before restoring paging.