OSDev.org

Hi everyone,
I am going to develop PMM & VMM for my OS.
I read the documents in the wiki and some tutorials but i think that i didn't understand the main idea.
I want to understand how to make the PMM, the VMM and what is the address spaces.
I read a lot of documents about this but no document described how to develop one , they talk about the allocators and how malloc and free works.
Can anyone explains to me how the PMM and VMM work and what is the address spaces, please?
------------------
Thanks in advance.

Start with a physical memory manager, and get that right before even looking at virtual.

The physical address space is just your physical memory. Each byte of memory has an address, which is why it is called an address space.

A kernel needs to track the memory that is being used. It needs to do this so two different applications or structures (or anything that needs memory) will not try to access the same part of memory. If they do, memory will get overwritten, which will cause bad behaviour.

The Kernel keeps a structure in memory to track what areas of memory have been allocated. Memory is allocated in blocks, rather than in individual bytes. When something needs memory, it makes a request to the Kernel, the Kernel looks up the structure to see what is free, and allocates one or more free blocks as required. It will also make a note that that block of memory is no longer available to be allocated. When the application no longer needs the memory, it informs the Kernel (hopefully) and the Kernel marks it as available once again.

Does that make sense so far?

At its simplest, a physical memory manager maintains a bitmap of the memory which is currently being used. At the request of the kernel it will search the bitmap for the required number of contiguos (usually 4096 byte) pages, and then pass their address to the kernel. When the kernel later releases that memory, the physical memory manager will go to the bitmap and mark the pages as available for reuse. Depending upon how much information you want to record, the "bitmap" may or may not have a single bit for each page, indicating it as in use/not in use.

A virtual memory manager is a bit more complicated, but it relies upon the physical memory manager to allocate physical memory, which it then maps to the virtual memory applications work with (although they "think" the addresses they work with refer to physical memory).

It doesn't have to do it with bitmaps, I actually find a stack to be an easier way of doing it. Anyway. The PMM keeps track of the physical, actual, real memory. It basically keeps track of what sections of memory are being used, and what is free. The implementation of this is however you chose, but it should be able to allocate a page and deallocate a page.

The VMM keeps track of virtual address spaces, and maps pages accordingly. Basically, a bit of code that is running with a certain address space (this is set in a processor register), will try to access a piece of memory. Say 0x80000000. What the processor does (without the knowledge of the code) is to change the address that it accesses from 0x80000000 to whatever that address is mapped to. Say, 0x80000000 -> 0x10000. This means that the physical RAM that is at 0x10000 is being accessed whenever the code accesses 0x80000000. Its abstraction. At its most frustrating.

The way the processor determines what virtual address is what physical address is described in the page directory.

-JL

The normal procedure is to allocate physical memory on the basis of a 4K page. Almost all allocations can be done on single 4K pages. Therefore, it is overkill to burden the physical memory manager with the ability to allocate larger (or smaller) chunks of physical memory. Some memory-mapped devices will need larger physical memory regions, but those allocations are non-ordinary, and boot-time only, and therefore can cost extra in term of execution speed.

I find linking free pages in a list most convienent. The only problem is that the lists themselves need physical memory.

Virtual memory allocation could be divided into the needs of kernel (ring zero devices) and applications. I have a page-aligned and a dword aligned memory allocator for kernel. The paged aligned allocator would scan page-tables for free pages. The dword-aligned allocator links memory blocks much like traditional MS-DOS blocks or C-library heap implementations. Applications have their own executable-format related allocators. PE format has a page-based allocator operating on page-tables, with the C library providing smaller blocks.

I also have a boot allocator that allocates directly from the PMM's copy of the E820 table. I understand that you cannot free memory back to the bootallocator but if you set things up correctly you can free it to the 'real' allocator later. In fact I initialise my allocator by calling kphys_free() for every page that's left after boot. My PMM is just a linked list.

Like RDOS said you should heavily optimise for allocating 1 page at a time and freeing pages many at a time.

Thank you very much for all your replies