Page 2 of 2
Re: Physical and Virtual Memory Allocator
Posted: Mon Aug 11, 2008 2:46 am
by leledumbo
The problem is, you wrote a physical memory manager, and you're using it as a virtual memory manager, which obviously does not work
That's why I'm asking it. Especially the problem that when paging is enabled, all memory references will be virtual. Then how can a PMM work with paging enabled? I have an idea that when a page needs to be allocated, paging is disabled first, get the page, then re-enable paging. Will that work?
Re: Physical and Virtual Memory Allocator
Posted: Mon Aug 11, 2008 3:30 am
by AJ
No - you're overcomplicating things.
All your physical memory manager does is allocate page frames. These are just numbers. Your page frame allocator is not special code that the processor will take note of - it is an internal accounting system for your kernel.
A
very simple page fault exception handler in a C kernel may look like this:
Code: Select all
void myPFEHandler()
{
void *physicalPage = pmalloc(); //pmalloc is your physical page allocator.
void *virtualPage = read_cr2()&~0xFFF; //cr2 contains the address of the page fault.
page_in(physicalPage, virtualPage, PAGE_PRESENT | PAGE_WRITE); //guess what this does!
}
You can do all this without disabling paging in any way. pmalloc simply assigns the next available page of physical memory from a stack or bitmap that you have constructed. If this were to go wrong and allocate the same page twice, the CPU has no way of knowing this - it is down to your kernel to keep track of allocated pages.
The function above simply pages in whenever there is a page fault. Your
virtual memory manager allocates memory with a resolution of 1 byte (or the processor word size) rather than 1 page. This means that calling kmalloc(0x100) twice may return different addresses within the same page. The page fault will only occur the first time that page is accessed.
Later, you will need something in that page fault exception handler to check whether the page fault occurred somewhere that was allocated by your virtual allocator (in which case you page in as above) or somewhere that was not allocated (in which case you throw an exception which could result in the application being terminated).
Cheers,
Adam
Re: Physical and Virtual Memory Allocator
Posted: Wed Aug 13, 2008 1:25 am
by leledumbo
I re-read JamesM tutorial on Chapter 6, and I think I finally understand (used to skip some parts of it). This is the part that resembles my question:
How do you access your page tables? It may seem simple, but remember that a page directory must hold physical addresses, not virtual ones. And the only way you can read/write to memory is using virtual addresses!
One thing I don't yet understand is from the next paragraph:
One solution to this problem is to never access your page tables directly, but to map one page table to point back to the page directory, so that by accessing memory at a certain address you can see all your page tables as if they were pages, and all your page table entries as if they were normal integers. The diagram on the right should help to explain. This method is a little counter-intuitive in my opinion and it also wastes 256MB of addressable space, so I prefer another method.
Recursive directory entry AFAIK only consumes 1 page table (4 MB). Why did you state that it wastes 256 MB?
Re: Physical and Virtual Memory Allocator
Posted: Wed Aug 13, 2008 3:03 am
by AJ
You are correct - in the traditional 32 bit paging scheme, it only uses 4MiB - more if you are using PAE or 64 bit mode (but then in 64 bit mode you have a lot more address space to play with).
I am an advocate of this method (mapping the PD to itself) and think it also has a lot going for it once you start multitasking, too.
Cheers,
Adam