FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F5.2.1 2003-11-08T04:39:22Z 2003-11-08T04:39:22Z Peter Wemm peter@FreeBSD.org 2003-11-08T04:39:22Z urn:sha1:fcfe57d64080fe861c8dc9d41bc675338ff4ad9a 2003-09-25T01:11:17Z Peter Wemm peter@FreeBSD.org 2003-09-25T01:11:17Z urn:sha1:cc3112f108529cf55535993c0235bf3c75228739 support can clip it to sensible values. 2003-09-23T03:20:34Z Peter Wemm peter@FreeBSD.org 2003-09-23T03:20:34Z urn:sha1:725bc1731234270efaf1a26dcab244ca00253793 32 bit binary stuff. 32 bit binaries do not like it much when the kernel tries hard to put things above the 8GB mark. I have a work-in-progress to fix this properly, but I didn't want to burn anybody with this yet. 2003-09-22T23:21:39Z Peter Wemm peter@FreeBSD.org 2003-09-22T23:21:39Z urn:sha1:24789c549a8ad7594d6ed76c327fbbc3f7965a97 stack limit from 64MB to 512MB. 2003-07-09T23:04:23Z Peter Wemm peter@FreeBSD.org 2003-07-09T23:04:23Z urn:sha1:bf8ca114e2ba26db9a83261173ba4c867e37806d on the implied sign extension. The single unified VADDR() macro was not able to avoid sign extending the VM_MAXUSER_ADDRESS/USRSTACK values. Be explicit about UVADDR() (positive address space) and KVADDR() (kernel negative address space) to make mistakes show up more spectacularly. Increase user VM space from 1/2TB (512GB) to 128TB. 2003-05-23T06:36:46Z Peter Wemm peter@FreeBSD.org 2003-05-23T06:36:46Z urn:sha1:d9cd1af4aad01580a41d5540445b12f919e39636 Submitted by: jmallett Approved by: re (blanket amd64/*) 2003-05-23T05:04:54Z Peter Wemm peter@FreeBSD.org 2003-05-23T05:04:54Z urn:sha1:3c9a3c9ca347babaa07b5f7126cf8a5e30fadf3f systems. Of note: - Implement a direct mapped region using 2MB pages. This eliminates the need for temporary mappings when getting ptes. This supports up to 512GB of physical memory for now. This should be enough for a while. - Implement a 4-tier page table system. Most of the infrastructure is there for 128TB of userland virtual address space, but only 512GB is presently enabled due to a mystery bug somewhere. The design of this was heavily inspired by the alpha pmap.c. - The kernel is moved into the negative address space(!). - The kernel has 2GB of KVM available. - Provide a uma memory allocator to use the direct map region to take advantage of the 2MB TLBs. - Fixed some assumptions in the bus_space macros about the ability to fit virtual addresses in an 'int'. Notable missing things: - pmap_growkernel() should be able to grow to 512GB of KVM by expanding downwards below kernbase. The kernel must be at the top 2GB of the negative address space because of gcc code generation strategies. - need to fix the >512GB user vm code. Approved by: re (blanket) 2003-05-01T01:05:25Z Peter Wemm peter@FreeBSD.org 2003-05-01T01:05:25Z urn:sha1:afa8862328041298fe0c059d65cea406f92bad4b a heavily stripped down FreeBSD/i386 (brutally stripped down actually) to attempt to get a stable base to start from. There is a lot missing still. Worth noting: - The kernel runs at 1GB in order to cheat with the pmap code. pmap uses a variation of the PAE code in order to avoid having to worry about 4 levels of page tables yet. - It boots in 64 bit "long mode" with a tiny trampoline embedded in the i386 loader. This simplifies locore.s greatly. - There are still quite a few fragments of i386-specific code that have not been translated yet, and some that I cheated and wrote dumb C versions of (bcopy etc). - It has both int 0x80 for syscalls (but using registers for argument passing, as is native on the amd64 ABI), and the 'syscall' instruction for syscalls. int 0x80 preserves all registers, 'syscall' does not. - I have tried to minimize looking at the NetBSD code, except in a couple of places (eg: to find which register they use to replace the trashed %rcx register in the syscall instruction). As a result, there is not a lot of similarity. I did look at NetBSD a few times while debugging to get some ideas about what I might have done wrong in my first attempt. 2003-04-07T14:27:19Z Jake Burkholder jake@FreeBSD.org 2003-04-07T14:27:19Z urn:sha1:46ea68dd108014e4cbf9ee4157b22c7a52bb4836 the top of the address space to be reclaimed. The problem is that with the APTD gone the mapable kernel address space runs right to the end of the 32 bit address space. As a max this is 0x100000000, which can't be represented in 32 bits, so we have to use ptd entry n-1 and pte offset n-1, instead of ptd entry n and pte offset 0. There's still 1 page we can't use, but we gain just under 4 megs of kva (8 megs with PAE). Sponsored by: DARPA, Network Associates Laboratories 2003-02-24T20:29:52Z Jake Burkholder jake@FreeBSD.org 2003-02-24T20:29:52Z urn:sha1:5cd612b27e591a1a0f1105869ae960f07554f3d8 - Changed VM_MAXUSER_ADDRESS to be defined in terms of PTDPTDI. In order for assumptions about the recursive page table map to work it must be the base of the recursive map. Any pte offset that's not NPTEPG will break these assumptions. Sponsored by: DARPA, Network Associates Laboratories