Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Hi there!
I'm planning my memory mapping for kernel right now, and I wonder if you could criticize my choices and stuff.
I won't touch the user space memory as I don't have user space yet.
The kernel space starts at 0xC0000000 and ends at 0xFFFFFFFF
+------------------------------+ 0xFFFFFFFF
| Current PD and PT's (4Mb) |
|______________________________| 0xFFC00000
| No idea what will be there |
| Maybe video addresses? |
|______________________________| 0xF0000000
| Probably Drivers |
|______________________________| 0xE0000000
| Kernel Stack (16kb too much?)|
|______________________________| 0xDFFFC000
| Guard page (unmapped) (4kb) |
|______________________________| 0xDFFFB000
| Kernel Heap |
| (around 255MB) |
|______________________________| 0xD00000000
| Kernel Code |
| (255MB) |
|______________________________| 0xC0100000
| Motherboard BIOS (ROM) |
| (64Kb) |
|______________________________| 0xC00F0000
| BIOS Shadow Area ? (ROM) |
| (160kb) |
|______________________________| 0xC00C8000
| Video BIOS (ROM) |
| (32kb) |
|______________________________| 0xC00C0000
| VGA Text Color |
| (32kb) |
|______________________________| 0xC00B8000
| VGA Text Monochrome |
| (32kb) |
|______________________________| 0xC00B0000
| VGA framebuffer |
| (64kb) |
|______________________________| 0xC00A0000
| EBDA |
| (4kb) |
|______________________________| 0xC009F000
| Unmapped |
| (632kb) |
|______________________________| 0xC0001000
| IVT & BDA maybe? |
| (4kb) |
|______________________________| 0xC0000000
The IVT & BDA probably will become an unmapped space since I don't need them at the kernel PDE yet. The same goes for EBDA.
Video memory probably will be moved to 0xF0...
As you may see the whole lower megabyte between 0xC0000000 - 0xC0100000 is wasted (in case if the video memory will be moved to 0xF0.. and E/BDA will be discarded).
So any suggestions, critics, or improvements for my memory map?
Thanks
Last edited by skwee on Sun Sep 20, 2009 1:50 pm, edited 1 time in total.
I don't think that you need a 16kb kernel-stack. My kernel uses 4kb for the stack and that's still far more than I need
I should mention that my kernel is a microkernel (although quite big for a microkernel). I assume that you plan a monolithic one since you reserved 255mb for code?
Additionally you haven't mentioned a area where you map all page-table-entries (by putting the page-directory in a slot of itself). That simplyfies paging very much...
And I think you will need some space for temporary mappings (e.g. copying the kernel-stack from one process to another).
Thanks a lot for the comment.
The 16KB stack probably was design bug since I typed 0x4000 instead of 4096, not a big deal, most likely Ill change it to 4KB.
Hmm I didn't think about mapping page table entires, I thought they would be kept inside the heap since this is the place well I allocate them. But if you say it simplifies paging, than most likely Ill put them at 0xF... (above the video memory if any).
About temporary space, Ill think where to put it.
Thanks for your comment!
skwo wrote:Hmm I didn't think about mapping page table entires, I thought they would be kept inside the heap since this is the place well I allocate them.
That sounds like a strange place for me I don't know for what purpose you want to implement the heap but I think the usual way (or lets better say: the way that makes most sense for me) is to do it the same way you would do in userspace (or are used to from malloc(), ...). That means you can allocate space for data of arbitrary size at a not specified place. I don't know why you want to mix it with paging. Of course, the heap needs to request frames sometimes and map them to somewhere, but that should IMO be the only thing in which it is connected to paging/physical memory management.
Well, as you said heap needs to allocate stuff, so when I'm creating a new page directory I need to allocate space for it, hence it will be stored in heap. Am I missing something?
| No idea what will be there |
| Maybe video addresses? |
If you want to reserve space for framebuffers, have you considered that the high-end video cards already have more VRAM than what you can fit between 0xC0000000 and 0xFFFFFFFF ?
I also take you want to map in MMIO addresses in that area?
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Do you want to support anything more than PC-AT hardware (you know, the stuff you got when you bought that 386 box)
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
skwo wrote:Well, as you said heap needs to allocate stuff, so when I'm creating a new page directory I need to allocate space for it, hence it will be stored in heap. Am I missing something?
Thats possible, of course. But it makes not much sense IMO because a heap is intended to store data of arbitrary size. Page-directories and page-tables are 4kb (= page-size) big. Since the heap has to take care that you can allocate space of any size it is slower. At least comparing to the allocation of a frame which should be (depending on your physical memory management implementation) much faster.
Edit: Additionally you don't flood your heap with these structures. The more areas your heap has to manage the slower it gets, normally.
Edit2: Wait...there was something that page-tables and page-directories have to be page-aligned, IIRC. So, if thats true, you can't use a heap (at least not a default one)
Last edited by hrniels on Sat Sep 19, 2009 2:24 pm, edited 1 time in total.
hrniels
Oh thats nice Idea! But there is a little problem: my page directory is not 4KB because I have array of physical addresses of the page tables and virtual onces, so its more like 8kb (+4bytes for the physical address of the PDE). I might redesign this, but for now it works good.
No arguments here: I'm pleasantly surprised to find that it almost identically matches mine. Any corrections you receive here would be beneficial to me, too.
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
Just small update, current Page Directory and Page tables will be moved to area 0xFFC00000 - 0xFFFFFFFF (since I was able to understand "fractal mapping"/"mapping page directory to itself" method) [first post was updated].
Still would like to get some suggestions, and critics, please!
Thank you!
If you plan to use the "thread-oriented scheduling" maybe better to have all kernel stacks in global kernel space. Each my kernel stack have size 16 kb including guard page (stop frame) at the bottom and thread structure at the top, so in fact real size is equal to 12 kb minus T(hread)S(tructure)_SIZE.
I have total page table (4 mb) at the end of virt. addr. space too. Under this region is placed the local kernel data region (that like hyperspace in WinNT).
I need not to map IVT and BDA, but do this like you in special editions as part of uncachable page where it is placed the first seven entries of IDT (to withstand the bug of some Pentiums).
Most of kernel/driver code and data, bss and reserved areas are placed in consecutive order and so its structures can shift from one position to another. In addition the parts of some large structures can be spread in different places, some physical regions can be mapped multiple times into different frames and so on.
If you have seen bad English in my words, tell me what's wrong, please.
Anyway I think I came up with a solution, that as I see it now fits the best for me.
If someone is interested, continue reading:
0xC0000000 - 0xCFFFFFFF
Kernel code + data (compile time known data) area. The region from 0xC0000000 - 0xC0100000 is not used except for VGA framebuffer that will be mapped to 0xC00B8000.
0xD0000000 - 0xDFFFFFFF
Kernel heap growing towards 0xDFF... and kernel stack growing towards 0xD00... with an unmapped page between them (guard page).
0xE0000000 - 0xEFFFFFFF
Probably here will be drivers and shared libraries, I'm not sure yet because I'm still writing the kernel, for now its reserved.
0xF0000000 - 0xFFBFFFFF
Some place for some data (like newly created page tables or page directory, they have to be mapped somewhere) something like temporary mapping.
