Date: Sat, 21 Jun 2003 14:16:37 +0900 From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> To: Peter Wemm <peter@wemm.org> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 pmap.c Message-ID: <ybsllvwqabu.wl@ett.sat.t.u-tokyo.ac.jp> In-Reply-To: <20030620155756.423C72A7EA@canning.wemm.org> References: <ybsu1alqk02.wl@ett.sat.t.u-tokyo.ac.jp> <20030620155756.423C72A7EA@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybsllvwqabu.wl>