From owner-cvs-all@FreeBSD.ORG Fri Jun 20 22:16:42 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA13337B401; Fri, 20 Jun 2003 22:16:42 -0700 (PDT) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [133.11.205.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7FF643FB1; Fri, 20 Jun 2003 22:16:40 -0700 (PDT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is1.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id AB8E62187B8; Sat, 21 Jun 2003 14:16:38 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) h5L5Gb3V005432; Sat, 21 Jun 2003 14:16:37 +0900 Received: from ett.sat.t.u-tokyo.ac.jp (ett.sat.t.u-tokyo.ac.jp [133.11.135.3])3.3.5-GR) with ESMTP id AJA13567; Sat, 21 Jun 2003 14:16:37 +0900 (JST) Date: Sat, 21 Jun 2003 14:16:37 +0900 Message-ID: From: Hidetoshi Shimokawa To: Peter Wemm In-Reply-To: <20030620155756.423C72A7EA@canning.wemm.org> References: <20030620155756.423C72A7EA@canning.wemm.org> User-Agent: Wanderlust/2.11.0 (Wonderwall) REMI/1.14.3 (Matsudai) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 8) (Honest Recruiter) (i386--freebsd) X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7: #j7i14gu$jgR\S*&C3R/pJX cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 pmap.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2003 05:16:43 -0000 At Fri, 20 Jun 2003 08:57:56 -0700, Peter Wemm wrote: > > I made patch for that, > > http://www.sat.t.u-tokyo.ac.jp/~simokawa/amd64/kva.patch.txt > > (include /dev/kmem fix for direct map and debug code) > > I like the part about moving to -2GB (but see below), but I am unhappy > about the /dev/mem part of the change. We need to be able to let /dev/mem > reach the pci mapping space etc, and your change breaks that. Checking phys_avail seems redundant. I have removed it. > > I failed to link kernel for 2GB+ KVA space (set KPDPI to (NPDPEPG-4)). > > Linker produces the following errors: > > > > locore.o: In function `btext': > > /usr/obj/amd64/export/home/src/sys/FireWire/{standard input}:53: relocation t > runcated to fit: R_X86_64_32S .bss > > cam.o: In function `cam_fetch_status_entry':/export/home/src/sys/cam/cam.c:18 > 7:relocation truncated to fit: R_X86_64_32S .text > > ..... > > > > Do you have any idea? > > Yes. This is what I was talking about for growing the kernel downwards. > gcc generates code that uses 32 bit signed relocations. This means that you > can only link code that has symbols in the +/- 2GB range. This is why > things like PTmap[] are #defines rather than symbols. So, what I had planned > was to leave the kernel at -1GB, and grow new pdp's downwards below the > code link address. Since they are all accessed via pointers rather than > compile time symbols, we can do that. What I haven't finished thinking about > is the implications of that. Do we leave KERNBASE at -1GB and have something > like KVABASE for some of the places that test for 'if (va > KERNBASE) ...' > and so on. Those would have to change to KVABASE. Or, do we move KERNBASE > to the bottom address that we can grow downwards to? The problem with > that is that some early bootstrap code knows that va = pa + KERNBASE, > so that would all need to be fixed. I did not want to try this in the > leadup to 5.1-R, but the dust seems to be settling now and it is time > to resolve it (and some of the other problems I've mentioned before). Is it hard to fix gcc to handle 64 relocations? I'm wondering how other 64 arch. like alpha handle this problem. I'm not sure how you cheat vm_find_space() which assumes kernel grows upward... Anyway, after converting pmap_map() to use direct map, 2GB of KVA seems enough for now. /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html