src-test2/sys/amd64/include/vmparam.h, branch releng/6.3 FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=releng%2F6.3 2004-10-27T17:21:15Z Raise MAXDSIZ from 8G to 32G. The old limit was just an arbitary choice 2004-10-27T17:21:15Z Peter Wemm peter@FreeBSD.org 2004-10-27T17:21:15Z urn:sha1:3904b13fab1c3c916cfd19a79c23927ccb40c5b9 that was greater than 4G. I originally used the same values as i386 in order to save opening a new PML4 page slot, but in the day of gigabytes of memory, worrying about a 4K page seems futile. Moving from 8 to 32G moves the page to a different index, it doesn't increase the number of pages used. Increase VM_KMEM_SIZE_MAX from 200MB to 400MB. 2003-12-07T04:51:04Z Alan Cox alc@FreeBSD.org 2003-12-07T04:51:04Z urn:sha1:4d4a286cba7e017edbab2fe2f837a24a94664f39 Discussed with: peter Update the graffiti. 2003-11-08T04:39:22Z Peter Wemm peter@FreeBSD.org 2003-11-08T04:39:22Z urn:sha1:fcfe57d64080fe861c8dc9d41bc675338ff4ad9a Re-raise the default datasize and stacksize now that the 32 bit exec 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. Oops. back out last commit. The data and stack limits are used by the 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. Increase the default data size limit from 512MB to 8GB. Increase default 2003-09-22T23:21:39Z Peter Wemm peter@FreeBSD.org 2003-09-22T23:21:39Z urn:sha1:24789c549a8ad7594d6ed76c327fbbc3f7965a97 stack limit from 64MB to 512MB. Fix the VADDR() macros to use either KVADDR() or UVADDR(), depending 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. Typo fix. oops. 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/*) Major pmap rework to take advantage of the larger address space on 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) Commit MD parts of a loosely functional AMD64 port. This is based on 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.