DragonFly kernel List (threaded) for 2007-10
Re: pmap of amd64
:I try to come up the way to organize the kernel memory maps and having
:spent sometime figuring out the freebsd pmap structure which looks
:wired to me (because of not understanding:).
:below is the amd64 long mode 4k page VA structure.
:some issues for discussions:
:1. 4K page or 2M page for kernel?
4K for sure.
:2. how many PML4/PDP entry for kernel/user?
The kernel will be running in long mode w/ 4K pages, which gives
us a 9 bit (512 entry) PML4 table. I think you want to try
to implement things as simply as possible so give each cpu its
own PML4 table. I strongly recommend:
* That the user map use only ONE PML4 entry (i.e. 39 bit address space),
to begin with. This way the process switch code simply load a single
pointer to switch user address spaces and we do not have to allocate
a PML4 table for each user process.
* The kernel map only needs one PML4 entry but giving it more later on
is really easy to do.
* One or more PML4 entries would be used to direct-map all of physical
memory into kernel space. This would make the pmap operations a
lot easier as they would not have to map page table pages into memory
to work on them, they could just figure out the physical address
and access the pages directory from the direct physical map.
* One PML4 entry for globaldata access magic (this would work if the
PML4 table is per-cpu rather then per-process).
:3. how to do with the per-cpu data, should a PML4/PDP entry for each CPU?
I don't think we can use segment descriptor table magic in long mode
like we do in i386. What I suggest is that one PML4 entry be used
to allow us to movq the contents of a specific address into %fs
in order to get the per-cpu structure pointer, or something like that.
Ultimately we will want to be able to support a larger user address
space, either by storing multiple entries in the PML4 table during the
switch code or with other magic, but I really think that can be left
One thing that I do not want to do is give each user process its own
PML4 table. I think that's a mistake. Having the system manage
just one PML4 table per cpu greatly simplifies the rest of the pmap