Date: Thu, 22 May 2003 23:21:45 -0700 From: Peter Wemm <peter@wemm.org> To: Dag-Erling Smorgrav <des@ofug.org> Cc: cvs-all@FreeBSD.org Subject: Re: 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 Message-ID: <20030523062145.A53A62A7EA@canning.wemm.org> In-Reply-To: <xzp8ysyxk5b.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote: > Peter Wemm <peter@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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030523062145.A53A62A7EA>