From owner-cvs-src@FreeBSD.ORG  Thu May 22 23:21:46 2003
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5101837B401; Thu, 22 May 2003 23:21:46 -0700 (PDT)
Received: from canning.wemm.org (canning.wemm.org [192.203.228.65])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id C6D9643F75; Thu, 22 May 2003 23:21:45 -0700 (PDT)
	(envelope-from peter@wemm.org)
Received: from wemm.org (localhost [127.0.0.1])
	by canning.wemm.org (Postfix) with ESMTP
	id A53A62A7EA; Thu, 22 May 2003 23:21:45 -0700 (PDT)
	(envelope-from peter@wemm.org)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Dag-Erling Smorgrav <des@ofug.org>
In-Reply-To: <xzp8ysyxk5b.fsf@flood.ping.uio.no> 
Date: Thu, 22 May 2003 23:21:45 -0700
From: Peter Wemm <peter@wemm.org>
Message-Id: <20030523062145.A53A62A7EA@canning.wemm.org>
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.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 
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2003 06:21:46 -0000

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