1. 11 5月, 2016 2 次提交
  2. 01 5月, 2016 4 次提交
  3. 12 3月, 2016 1 次提交
    • C
      powerpc/8xx: Map linear kernel RAM with 8M pages · a372acfa
      Christophe Leroy 提交于
      On a live running system (VoIP gateway for Air Trafic Control), over
      a 10 minutes period (with 277s idle), we get 87 millions DTLB misses
      and approximatly 35 secondes are spent in DTLB handler.
      This represents 5.8% of the overall time and even 10.8% of the
      non-idle time.
      Among those 87 millions DTLB misses, 15% are on user addresses and
      85% are on kernel addresses. And within the kernel addresses, 93%
      are on addresses from the linear address space and only 7% are on
      addresses from the virtual address space.
      
      MPC8xx has no BATs but it has 8Mb page size. This patch implements
      mapping of kernel RAM using 8Mb pages, on the same model as what is
      done on the 40x.
      
      In 4k pages mode, each PGD entry maps a 4Mb area: we map every two
      entries to the same 8Mb physical page. In each second entry, we add
      4Mb to the page physical address to ease life of the FixupDAR
      routine. This is just ignored by HW.
      
      In 16k pages mode, each PGD entry maps a 64Mb area: each PGD entry
      will point to the first page of the area. The DTLB handler adds
      the 3 bits from EPN to map the correct page.
      
      With this patch applied, we now get only 13 millions TLB misses
      during the 10 minutes period. The idle time has increased to 313s
      and the overall time spent in DTLB miss handler is 6.3s, which
      represents 1% of the overall time and 2.2% of non-idle time.
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NScott Wood <oss@buserror.net>
      a372acfa
  4. 14 12月, 2015 2 次提交
  5. 11 6月, 2015 1 次提交
    • A
      powerpc/mmu: Add userspace-to-physical addresses translation cache · 15b244a8
      Alexey Kardashevskiy 提交于
      We are adding support for DMA memory pre-registration to be used in
      conjunction with VFIO. The idea is that the userspace which is going to
      run a guest may want to pre-register a user space memory region so
      it all gets pinned once and never goes away. Having this done,
      a hypervisor will not have to pin/unpin pages on every DMA map/unmap
      request. This is going to help with multiple pinning of the same memory.
      
      Another use of it is in-kernel real mode (mmu off) acceleration of
      DMA requests where real time translation of guest physical to host
      physical addresses is non-trivial and may fail as linux ptes may be
      temporarily invalid. Also, having cached host physical addresses
      (compared to just pinning at the start and then walking the page table
      again on every H_PUT_TCE), we can be sure that the addresses which we put
      into TCE table are the ones we already pinned.
      
      This adds a list of memory regions to mm_context_t. Each region consists
      of a header and a list of physical addresses. This adds API to:
      1. register/unregister memory regions;
      2. do final cleanup (which puts all pre-registered pages);
      3. do userspace to physical address translation;
      4. manage usage counters; multiple registration of the same memory
      is allowed (once per container).
      
      This implements 2 counters per registered memory region:
      - @mapped: incremented on every DMA mapping; decremented on unmapping;
      initialized to 1 when a region is just registered; once it becomes zero,
      no more mappings allowe;
      - @used: incremented on every "register" ioctl; decremented on
      "unregister"; unregistration is allowed for DMA mapped regions unless
      it is the very last reference. For the very last reference this checks
      that the region is still mapped and returns -EBUSY so the userspace
      gets to know that memory is still pinned and unregistration needs to
      be retried; @used remains 1.
      
      Host physical addresses are stored in vmalloc'ed array. In order to
      access these in the real mode (mmu off), there is a real_vmalloc_addr()
      helper. In-kernel acceleration patchset will move it from KVM to MMU code.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      15b244a8
  6. 18 3月, 2015 1 次提交
  7. 14 11月, 2014 1 次提交
  8. 08 10月, 2014 1 次提交
  9. 28 7月, 2014 1 次提交
  10. 21 6月, 2013 2 次提交
  11. 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
  12. 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
  13. 25 11月, 2011 1 次提交
  14. 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
  15. 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
  16. 13 10月, 2010 1 次提交
  17. 30 10月, 2009 1 次提交
  18. 20 8月, 2009 1 次提交
  19. 26 6月, 2009 1 次提交
  20. 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
  21. 09 6月, 2009 1 次提交
  22. 27 5月, 2009 1 次提交
  23. 24 3月, 2009 1 次提交
  24. 11 3月, 2009 1 次提交
  25. 21 12月, 2008 3 次提交
  26. 16 12月, 2008 1 次提交
  27. 03 12月, 2008 1 次提交
  28. 30 7月, 2008 1 次提交
  29. 14 2月, 2008 1 次提交
  30. 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
  31. 03 10月, 2007 1 次提交
  32. 20 8月, 2007 1 次提交