cvs commit: src/sys/amd64/amd64 pmap.c

[Peter Wemm]

Hidetoshi Shimokawa wrote:
> At Fri, 20 Jun 2003 14:04:53 +0900,
> Hidetoshi Shimokawa wrote:
> > 
> > At Thu, 19 Jun 2003 21:41:41 -0700,
> > Peter Wemm wrote:
> > > 
> > > Hidetoshi Shimokawa wrote:
> > > > At Thu, 19 Jun 2003 12:02:04 -0700,
> > > > Peter Wemm wrote:
> > > > > >   Modified files:
> > > > > >     sys/amd64/amd64      pmap.c 
> > > > > >   Log:
> > > > > >   Fix direct map page table for 2GB+ physical memory.
> > > > > 
> > > > > Thank you! :-)
> > > > > 
> > > > > Cheers,
> > > > > -Peter
> > > > 
> > > > Do you have any plan to increase KVA up to 512GB?
> > > > struct vm_page consumes 250MB space for 8GB memory.
> > > 
> > > Yes, once I return from my trip, which should be next week.  It shouldn't
> > > be too hard, it probably is a relatively simple matter of increasing the
> > > slots reserved for growing KVM, and teaching pmap_growkernel how to grow
> > > downwards....  OK, maybe thats easier said than done. :-)
> > 
> > I though there are something other than that to change KERNBASE.
> > I understand what we should do.
> 
> 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.

> 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).

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