cvs commit: src/sys/amd64/amd64 genassym.c src/sys/amd64/include asm.h atomic.h bootinfo.h coredump.h cpufunc.h elf.h endian.h exec.h float.h fpu.h frame.h globaldata.h ieeefp.h limits.h lock.h md_var.h param.h pcb.h pcb_ext.h pmap.h proc.h profile.h psl.h ...
Matthew Dillon
dillon at crater.dragonflybsd.org
Mon Feb 2 00:07:43 PST 2004
dillon 2004/02/02 00:05:56 PST
DragonFly src repository
Added files:
sys/amd64/amd64 genassym.c
sys/amd64/include asm.h atomic.h bootinfo.h coredump.h
cpufunc.h elf.h endian.h exec.h float.h
fpu.h frame.h globaldata.h ieeefp.h
limits.h lock.h md_var.h param.h pcb.h
pcb_ext.h pmap.h proc.h profile.h psl.h
reloc.h segments.h setjmp.h sigframe.h
signal.h specialreg.h stdarg.h stdint.h
sysarch.h thread.h trap.h tss.h types.h
ucontext.h uvparam.h vmparam.h
sys/conf Makefile.amd64 files.amd64 ldscript.amd64
options.amd64
Removed files:
sys/conf files.alpha
Log:
AMD64 infrastructure stage 1/99. This is just a preliminary commit. Many
of these files are being brought in from FreeBSD-5. The noteable exception
is sys/amd64/pmap.h, which contains some #if 0'd FreeBSD-5 stuff but has
the beginnings of a new MMU infrastructure. NOTHING WILL BUILD YET!
The DFly 64 bit AMD work will have a lot of similarities to the FreeBSD-5
work, but the PMAP/MMU/VM subsystem support is going to be written from
scratch and diverge wildly from F-5.
In particular, it is my intent to entirely do-away with %fs for per-cpu
storage references and instead use the top level PML4 page table (512GB
per entry, 256TB total VM) as a fixed per-cpu entity. Each cpu will get
its own PML4 table. Initially only one entry (512GB of VM) in PML4 will
be used to represent UVM. This is the entry that the thread switch code
changes out. Other entries will be used:
PML4 TABLE (each cpu gets its own table)
* 1 switched entry 512GB of UVM (expandable to more)
* 1 static entry 512GB of KVM
* 1 static entry to map physical memory
* 1 per-cpu entry to map the per-cpu globaldata space.
* Additional entries for recursive page tables, third party
process address space caches (userspace<->userspace copying),
and other features.
This should greatly simplify the PMAP code... no copies of the 'high' kernel
PDE entries, for example, and we still have the flexibility of switching out
the whole PML4 table at a later date without interfering with the basic
feature set.
More information about the Commits
mailing list