cvs commit: src/sys/amd64/amd64 genassym.c locore.S machdep.c mem.c nexus.c pmap.c trap.c vm_machdep.c src/sys/amd64/include bus_amd64.h param.h pmap.h vmparam.h src/sys/conf kern.mk

[Peter Wemm]

Dag-Erling Smorgrav wrote:
> Peter Wemm <peter at FreeBSD.org> writes:
> >   - The kernel is moved into the negative address space(!).
> 
> Read a lot of Knuth lately?  :)

Heh, no.  Its just a quirk of doing signed 32 and 48 bit addressing.  Gcc
likes to generate 32 bit signed address relocations in the code generation
models that we use.  This means it can reference symbols from -2GB through
2GB.  There are 48 virtual address bits (256TB) that are defined in this
version of the cpu spec, and it too is signed.  So, it just seemed natural
to have the user own the positive half, and the kernel the negative half.
This probably isn't strictly necessary, we could allocate additional user
address space in the unused negative address space if 128TB isn't enough.
:-)

Anyway, all I have to do now is figure out what I did wrong in
_pmap_allocpte() that causes >512GB page table instantiation to get
screwed up.

Cheers,
-Peter
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5