DragonFly BSD
DragonFly commits List (threaded) for 2004-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 00:05:56 -0800 (PST)

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.




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]