1. 28 7月, 2014 1 次提交
  2. 21 6月, 2013 2 次提交
  3. 20 6月, 2013 1 次提交
    • D
      powerpc/mm: Make mmap_64.c compile on 32bit powerpc · d5d8ec89
      Daniel Walker 提交于
      There appears to be no good reason to keep this as 64bit only. It works
      on 32bit also, and has checks so that it can work correctly with 32bit
      binaries on 64bit hardware which is why I think this works.
      
      I tested this on qemu using the virtex-ml507 machine type.
      
      Before,
      
      /bin2 # ./test & cat /proc/${!}/maps
      00100000-00103000 r-xp 00000000 00:00 0          [vdso]
      10000000-10007000 r-xp 00000000 00:01 454        /bin2/test
      10017000-10018000 rw-p 00007000 00:01 454        /bin2/test
      48000000-48020000 r-xp 00000000 00:01 224        /lib/ld-2.11.3.so
      48021000-48023000 rw-p 00021000 00:01 224        /lib/ld-2.11.3.so
      bfd03000-bfd24000 rw-p 00000000 00:00 0          [stack]
      /bin2 # ./test & cat /proc/${!}/maps
      00100000-00103000 r-xp 00000000 00:00 0          [vdso]
      0fe6e000-0ffd8000 r-xp 00000000 00:01 214        /lib/libc-2.11.3.so
      0ffd8000-0ffe8000 ---p 0016a000 00:01 214        /lib/libc-2.11.3.so
      0ffe8000-0ffed000 rw-p 0016a000 00:01 214        /lib/libc-2.11.3.so
      0ffed000-0fff0000 rw-p 00000000 00:00 0
      10000000-10007000 r-xp 00000000 00:01 454        /bin2/test
      10017000-10018000 rw-p 00007000 00:01 454        /bin2/test
      48000000-48020000 r-xp 00000000 00:01 224        /lib/ld-2.11.3.so
      48020000-48021000 rw-p 00000000 00:00 0
      48021000-48023000 rw-p 00021000 00:01 224        /lib/ld-2.11.3.so
      bf98a000-bf9ab000 rw-p 00000000 00:00 0          [stack]
      /bin2 # ./test & cat /proc/${!}/maps
      00100000-00103000 r-xp 00000000 00:00 0          [vdso]
      0fe6e000-0ffd8000 r-xp 00000000 00:01 214        /lib/libc-2.11.3.so
      0ffd8000-0ffe8000 ---p 0016a000 00:01 214        /lib/libc-2.11.3.so
      0ffe8000-0ffed000 rw-p 0016a000 00:01 214        /lib/libc-2.11.3.so
      0ffed000-0fff0000 rw-p 00000000 00:00 0
      10000000-10007000 r-xp 00000000 00:01 454        /bin2/test
      10017000-10018000 rw-p 00007000 00:01 454        /bin2/test
      48000000-48020000 r-xp 00000000 00:01 224        /lib/ld-2.11.3.so
      48020000-48021000 rw-p 00000000 00:00 0
      48021000-48023000 rw-p 00021000 00:01 224        /lib/ld-2.11.3.so
      bfa54000-bfa75000 rw-p 00000000 00:00 0          [stack]
      
      After,
      
      bash-4.1# ./test & cat /proc/${!}/maps
      [7] 803
      00100000-00103000 r-xp 00000000 00:00 0          [vdso]
      10000000-10007000 r-xp 00000000 00:01 454        /bin2/test
      10017000-10018000 rw-p 00007000 00:01 454        /bin2/test
      b7eb0000-b7ed0000 r-xp 00000000 00:01 224        /lib/ld-2.11.3.so
      b7ed1000-b7ed3000 rw-p 00021000 00:01 224        /lib/ld-2.11.3.so
      bfbc0000-bfbe1000 rw-p 00000000 00:00 0          [stack]
      bash-4.1# ./test & cat /proc/${!}/maps
      [8] 805
      00100000-00103000 r-xp 00000000 00:00 0          [vdso]
      10000000-10007000 r-xp 00000000 00:01 454        /bin2/test
      10017000-10018000 rw-p 00007000 00:01 454        /bin2/test
      b7b03000-b7b23000 r-xp 00000000 00:01 224        /lib/ld-2.11.3.so
      b7b24000-b7b26000 rw-p 00021000 00:01 224        /lib/ld-2.11.3.so
      bfc27000-bfc48000 rw-p 00000000 00:00 0          [stack]
      bash-4.1# ./test & cat /proc/${!}/maps
      [9] 807
      00100000-00103000 r-xp 00000000 00:00 0          [vdso]
      10000000-10007000 r-xp 00000000 00:01 454        /bin2/test
      10017000-10018000 rw-p 00007000 00:01 454        /bin2/test
      b7f37000-b7f57000 r-xp 00000000 00:01 224        /lib/ld-2.11.3.so
      b7f58000-b7f5a000 rw-p 00021000 00:01 224        /lib/ld-2.11.3.so
      bff96000-bffb7000 rw-p 00000000 00:00 0          [stack]
      Signed-off-by: NDaniel Walker <dwalker@fifo90.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      d5d8ec89
  4. 10 1月, 2013 1 次提交
    • A
      powerpc: Build kernel with -mcmodel=medium · 1fbe9cf2
      Anton Blanchard 提交于
      Finally remove the two level TOC and build with -mcmodel=medium.
      
      Unfortunately we can't build modules with -mcmodel=medium due to
      the tricks the kernel module loader plays with percpu data:
      
      # -mcmodel=medium breaks modules because it uses 32bit offsets from
      # the TOC pointer to create pointers where possible. Pointers into the
      # percpu data area are created by this method.
      #
      # The kernel module loader relocates the percpu data section from the
      # original location (starting with 0xd...) to somewhere in the base
      # kernel percpu data space (starting with 0xc...). We need a full
      # 64bit relocation for this to work, hence -mcmodel=large.
      
      On older kernels we fall back to the two level TOC (-mminimal-toc)
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1fbe9cf2
  5. 25 11月, 2011 1 次提交
  6. 20 9月, 2011 1 次提交
    • B
      powerpc: Hugetlb for BookE · 41151e77
      Becky Bruce 提交于
      Enable hugepages on Freescale BookE processors.  This allows the kernel to
      use huge TLB entries to map pages, which can greatly reduce the number of
      TLB misses and the amount of TLB thrashing experienced by applications with
      large memory footprints.  Care should be taken when using this on FSL
      processors, as the number of large TLB entries supported by the core is low
      (16-64) on current processors.
      
      The supported set of hugepage sizes include 4m, 16m, 64m, 256m, and 1g.
      Page sizes larger than the max zone size are called "gigantic" pages and
      must be allocated on the command line (and cannot be deallocated).
      
      This is currently only fully implemented for Freescale 32-bit BookE
      processors, but there is some infrastructure in the code for
      64-bit BooKE.
      Signed-off-by: NBecky Bruce <beckyb@kernel.crashing.org>
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      41151e77
  7. 14 10月, 2010 1 次提交
    • K
      powerpc/fsl-booke64: Use TLB CAMs to cover linear mapping on FSL 64-bit chips · 55fd766b
      Kumar Gala 提交于
      On Freescale parts typically have TLB array for large mappings that we can
      bolt the linear mapping into.  We utilize the code that already exists
      on PPC32 on the 64-bit side to setup the linear mapping to be cover by
      bolted TLB entries.  We utilize a quarter of the variable size TLB array
      for this purpose.
      
      Additionally, we limit the amount of memory to what we can cover via
      bolted entries so we don't get secondary faults in the TLB miss
      handlers.  We should fix this limitation in the future.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      55fd766b
  8. 13 10月, 2010 1 次提交
  9. 30 10月, 2009 1 次提交
  10. 20 8月, 2009 1 次提交
  11. 26 6月, 2009 1 次提交
  12. 16 6月, 2009 1 次提交
    • M
      powerpc: Add configurable -Werror for arch/powerpc · ba55bd74
      Michael Ellerman 提交于
      Add the option to build the code under arch/powerpc with -Werror.
      
      The intention is to make it harder for people to inadvertantly introduce
      warnings in the arch/powerpc code. It needs to be configurable so that
      if a warning is introduced, people can easily work around it while it's
      being fixed.
      
      The option is a negative, ie. don't enable -Werror, so that it will be
      turned on for allyes and allmodconfig builds.
      
      The default is n, in the hope that developers will build with -Werror,
      that will probably lead to some build breaks, I am prepared to be flamed.
      
      It's not enabled for math-emu, which is a steaming pile of warnings.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ba55bd74
  13. 09 6月, 2009 1 次提交
  14. 27 5月, 2009 1 次提交
  15. 24 3月, 2009 1 次提交
  16. 11 3月, 2009 1 次提交
  17. 21 12月, 2008 3 次提交
  18. 16 12月, 2008 1 次提交
  19. 03 12月, 2008 1 次提交
  20. 30 7月, 2008 1 次提交
  21. 14 2月, 2008 1 次提交
  22. 24 1月, 2008 1 次提交
    • P
      [POWERPC] Provide a way to protect 4k subpages when using 64k pages · fa28237c
      Paul Mackerras 提交于
      Using 64k pages on 64-bit PowerPC systems makes life difficult for
      emulators that are trying to emulate an ISA, such as x86, which use a
      smaller page size, since the emulator can no longer use the MMU and
      the normal system calls for controlling page protections.  Of course,
      the emulator can emulate the MMU by checking and possibly remapping
      the address for each memory access in software, but that is pretty
      slow.
      
      This provides a facility for such programs to control the access
      permissions on individual 4k sub-pages of 64k pages.  The idea is
      that the emulator supplies an array of protection masks to apply to a
      specified range of virtual addresses.  These masks are applied at the
      level where hardware PTEs are inserted into the hardware page table
      based on the Linux PTEs, so the Linux PTEs are not affected.  Note
      that this new mechanism does not allow any access that would otherwise
      be prohibited; it can only prohibit accesses that would otherwise be
      allowed.  This new facility is only available on 64-bit PowerPC and
      only when the kernel is configured for 64k pages.
      
      The masks are supplied using a new subpage_prot system call, which
      takes a starting virtual address and length, and a pointer to an array
      of protection masks in memory.  The array has a 32-bit word per 64k
      page to be protected; each 32-bit word consists of 16 2-bit fields,
      for which 0 allows any access (that is otherwise allowed), 1 prevents
      write accesses, and 2 or 3 prevent any access.
      
      Implicit in this is that the regions of the address space that are
      protected are switched to use 4k hardware pages rather than 64k
      hardware pages (on machines with hardware 64k page support).  In fact
      the whole process is switched to use 4k hardware pages when the
      subpage_prot system call is used, but this could be improved in future
      to switch only the affected segments.
      
      The subpage protection bits are stored in a 3 level tree akin to the
      page table tree.  The top level of this tree is stored in a structure
      that is appended to the top level of the page table tree, i.e., the
      pgd array.  Since it will often only be 32-bit addresses (below 4GB)
      that are protected, the pointers to the first four bottom level pages
      are also stored in this structure (each bottom level page contains the
      protection bits for 1GB of address space), so the protection bits for
      addresses below 4GB can be accessed with one fewer loads than those
      for higher addresses.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fa28237c
  23. 03 10月, 2007 1 次提交
  24. 20 8月, 2007 1 次提交
  25. 14 6月, 2007 1 次提交
    • B
      [POWERPC] Rewrite IO allocation & mapping on powerpc64 · 3d5134ee
      Benjamin Herrenschmidt 提交于
      This rewrites pretty much from scratch the handling of MMIO and PIO
      space allocations on powerpc64.  The main goals are:
      
       - Get rid of imalloc and use more common code where possible
       - Simplify the current mess so that PIO space is allocated and
         mapped in a single place for PCI bridges
       - Handle allocation constraints of PIO for all bridges including
         hot plugged ones within the 2GB space reserved for IO ports,
         so that devices on hotplugged busses will now work with drivers
         that assume IO ports fit in an int.
       - Cleanup and separate tracking of the ISA space in the reserved
         low 64K of IO space. No ISA -> Nothing mapped there.
      
      I booted a cell blade with IDE on PIO and MMIO and a dual G5 so
      far, that's it :-)
      
      With this patch, all allocations are done using the code in
      mm/vmalloc.c, though we use the low level __get_vm_area with
      explicit start/stop constraints in order to manage separate
      areas for vmalloc/vmap, ioremap, and PCI IOs.
      
      This greatly simplifies a lot of things, as you can see in the
      diffstat of that patch :-)
      
      A new pair of functions pcibios_map/unmap_io_space() now replace
      all of the previous code that used to manipulate PCI IOs space.
      The allocation is done at mapping time, which is now called from
      scan_phb's, just before the devices are probed (instead of after,
      which is by itself a bug fix). The only other caller is the PCI
      hotplug code for hot adding PCI-PCI bridges (slots).
      
      imalloc is gone, as is the "sub-allocation" thing, but I do beleive
      that hotplug should still work in the sense that the space allocation
      is always done by the PHB, but if you unmap a child bus of this PHB
      (which seems to be possible), then the code should properly tear
      down all the HPTE mappings for that area of the PHB allocated IO space.
      
      I now always reserve the first 64K of IO space for the bridge with
      the ISA bus on it. I have moved the code for tracking ISA in a separate
      file which should also make it smarter if we ever are capable of
      hot unplugging or re-plugging an ISA bridge.
      
      This should have a side effect on platforms like powermac where VGA IOs
      will no longer work. This is done on purpose though as they would have
      worked semi-randomly before. The idea at this point is to isolate drivers
      that might need to access those and fix them by providing a proper
      function to obtain an offset to the legacy IOs of a given bus.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3d5134ee
  26. 09 5月, 2007 1 次提交
    • B
      [POWERPC] Introduce address space "slices" · d0f13e3c
      Benjamin Herrenschmidt 提交于
      The basic issue is to be able to do what hugetlbfs does but with
      different page sizes for some other special filesystems; more
      specifically, my need is:
      
       - Huge pages
      
       - SPE local store mappings using 64K pages on a 4K base page size
      kernel on Cell
      
       - Some special 4K segments in 64K-page kernels for mapping a dodgy
      type of powerpc-specific infiniband hardware that requires 4K MMU
      mappings for various reasons I won't explain here.
      
      The main issues are:
      
       - To maintain/keep track of the page size per "segment" (as we can
      only have one page size per segment on powerpc, which are 256MB
      divisions of the address space).
      
       - To make sure special mappings stay within their allotted
      "segments" (including MAP_FIXED crap)
      
       - To make sure everybody else doesn't mmap/brk/grow_stack into a
      "segment" that is used for a special mapping
      
      Some of the necessary mechanisms to handle that were present in the
      hugetlbfs code, but mostly in ways not suitable for anything else.
      
      The patch relies on some changes to the generic get_unmapped_area()
      that just got merged.  It still hijacks hugetlb callbacks here or
      there as the generic code hasn't been entirely cleaned up yet but
      that shouldn't be a problem.
      
      So what is a slice ?  Well, I re-used the mechanism used formerly by our
      hugetlbfs implementation which divides the address space in
      "meta-segments" which I called "slices".  The division is done using
      256MB slices below 4G, and 1T slices above.  Thus the address space is
      divided currently into 16 "low" slices and 16 "high" slices.  (Special
      case: high slice 0 is the area between 4G and 1T).
      
      Doing so simplifies significantly the tracking of segments and avoids
      having to keep track of all the 256MB segments in the address space.
      
      While I used the "concepts" of hugetlbfs, I mostly re-implemented
      everything in a more generic way and "ported" hugetlbfs to it.
      
      Slices can have an associated page size, which is encoded in the mmu
      context and used by the SLB miss handler to set the segment sizes.  The
      hash code currently doesn't care, it has a specific check for hugepages,
      though I might add a mechanism to provide per-slice hash mapping
      functions in the future.
      
      The slice code provide a pair of "generic" get_unmapped_area() (bottomup
      and topdown) functions that should work with any slice size.  There is
      some trickiness here so I would appreciate people to have a look at the
      implementation of these and let me know if I got something wrong.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d0f13e3c
  27. 04 12月, 2006 1 次提交
    • A
      [POWERPC] ps3: multiplatform build fixes · e22ba7e3
      Arnd Bergmann 提交于
      A few code paths need to check whether or not they are running
      on the PS3's LV1 hypervisor before making hcalls. This introduces
      a new firmware feature bit for this, FW_FEATURE_PS3_LV1.
      
      Now when both PS3 and IBM_CELL_BLADE are enabled, but not PSERIES,
      FW_FEATURE_PS3_LV1 and FW_FEATURE_LPAR get enabled at compile time,
      which is a bug. The same problem can also happen for (PPC_ISERIES &&
      !PPC_PSERIES && PPC_SOMETHING_ELSE). In order to solve this, I
      introduce a new CONFIG_PPC_NATIVE option that is set when at least
      one platform is selected that can run without a hypervisor and then
      turns the firmware feature check into a run-time option.
      
      The new cell oprofile support that was recently merged does not
      work on hypervisor based platforms like the PS3, therefore make
      it depend on PPC_CELL_NATIVE instead of PPC_CELL. This may change
      if we get oprofile support for PS3.
      Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
      e22ba7e3
  28. 20 10月, 2005 1 次提交
  29. 12 10月, 2005 1 次提交
    • S
      powerpc: make iSeries boot again · 3a5f8c5f
      Stephen Rothwell 提交于
      On ARCH=ppc64 we were getting htab_hash_mask recalculated
      to the correct value for our particular machine by accident.
      In the merge tree, that code was commented out, so htab_hash_mask
      was being corrupted.
      
      We now set ppc64_pft_size instead which gets htab_has_mask
      calculated correctly for us later.  We should put an
      ibm,pft-size property in the device tree at some point.
      
      Also set -mno-minimal-toc in some makefiles.
      Allow iSeries to configure PROC_DEVICETREE.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      3a5f8c5f
  30. 10 10月, 2005 2 次提交
  31. 06 10月, 2005 1 次提交
    • P
      powerpc: Merge lmb.c and make MM initialization use it. · 7c8c6b97
      Paul Mackerras 提交于
      This also creates merged versions of do_init_bootmem, paging_init
      and mem_init and moves them to arch/powerpc/mm/mem.c.  It gets rid
      of the mem_pieces stuff.
      
      I made memory_limit a parameter to lmb_enforce_memory_limit rather
      than a global referenced by that function.  This will require some
      small changes to ppc64 if we want to continue building ARCH=ppc64
      using the merged lmb.c.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7c8c6b97
  32. 26 9月, 2005 1 次提交
    • P
      powerpc: Merge enough to start building in arch/powerpc. · 14cf11af
      Paul Mackerras 提交于
      This creates the directory structure under arch/powerpc and a bunch
      of Kconfig files.  It does a first-cut merge of arch/powerpc/mm,
      arch/powerpc/lib and arch/powerpc/platforms/powermac.  This is enough
      to build a 32-bit powermac kernel with ARCH=powerpc.
      
      For now we are getting some unmerged files from arch/ppc/kernel and
      arch/ppc/syslib, or arch/ppc64/kernel.  This makes some minor changes
      to files in those directories and files outside arch/powerpc.
      
      The boot directory is still not merged.  That's going to be interesting.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      14cf11af