1. 29 Nov, 2013 1 commit
  2. 05 Nov, 2013 1 commit
  3. 29 Jun, 2013 1 commit
  4. 14 Jun, 2013 4 commits
    • Steve Capper's avatar
      ARM64: mm: THP support. · af074848
      Steve Capper authored
      Bring Transparent HugePage support to ARM. The size of a
      transparent huge page depends on the normal page size. A
      transparent huge page is always represented as a pmd.
      If PAGE_SIZE is 4KB, THPs are 2MB.
      If PAGE_SIZE is 64KB, THPs are 512MB.
      Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Steve Capper's avatar
      ARM64: mm: HugeTLB support. · 084bd298
      Steve Capper authored
      Add huge page support to ARM64, different huge page sizes are
      supported depending on the size of normal pages:
      PAGE_SIZE is 4KB:
         2MB - (pmds) these can be allocated at any time.
      1024MB - (puds) usually allocated on bootup with the command line
               with something like: hugepagesz=1G hugepages=6
      PAGE_SIZE is 64KB:
       512MB - (pmds) usually allocated on bootup via command line.
      Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Steve Capper's avatar
      ARM64: mm: Move PTE_PROT_NONE bit. · 59911ca4
      Steve Capper authored
      Under ARM64, PTEs can be broadly categorised as follows:
         - Present and valid: Bit #0 is set. The PTE is valid and memory
           access to the region may fault.
         - Present and invalid: Bit #0 is clear and bit #1 is set.
           Represents present memory with PROT_NONE protection. The PTE
           is an invalid entry, and the user fault handler will raise a
         - Not present (file or swap): Bits #0 and #1 are clear.
           Memory represented has been paged out. The PTE is an invalid
           entry, and the fault handler will try and re-populate the
           memory where necessary.
      Huge PTEs are block descriptors that have bit #1 clear. If we wish
      to represent PROT_NONE huge PTEs we then run into a problem as
      there is no way to distinguish between regular and huge PTEs if we
      set bit #1.
      To resolve this ambiguity this patch moves PTE_PROT_NONE from
      bit #1 to bit #2 and moves PTE_FILE from bit #2 to bit #3. The
      number of swap/file bits is reduced by 1 as a consequence, leaving
      60 bits for file and swap entries.
      Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    • Steve Capper's avatar
      ARM64: mm: Make PAGE_NONE pages read only and no-execute. · 072b1b62
      Steve Capper authored
      If we consider the following code sequence:
      	my_pte = pte_modify(entry, myprot);
      	x = pte_write(my_pte);
      	y = pte_exec(my_pte);
      If myprot comes from a PROT_NONE page, then x and y will both be
      true which is undesireable behaviour.
      This patch sets the no-execute and read-only bits for PAGE_NONE
      such that the code above will return false for both x and y.
      Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
  5. 11 Jun, 2013 1 commit
  6. 07 Jun, 2013 1 commit
  7. 10 Jan, 2013 2 commits
  8. 29 Nov, 2012 1 commit
  9. 16 Nov, 2012 1 commit
  10. 17 Sep, 2012 1 commit
    • Catalin Marinas's avatar
      arm64: MMU definitions · 4f04d8f0
      Catalin Marinas authored
      The virtual memory layout is described in
      Documentation/arm64/memory.txt. This patch adds the MMU definitions for
      the 4KB and 64KB translation table configurations. The SECTION_SIZE is
      2MB with 4KB page and 512MB with 64KB page configuration.
      PHYS_OFFSET is calculated at run-time and stored in a variable (no
      run-time code patching at this stage).
      On the current implementation, both user and kernel address spaces are
      512G (39-bit) each with a maximum of 256G for the RAM linear mapping.
      Linux uses 3 levels of translation tables with the 4K page configuration
      and 2 levels with the 64K configuration. Extending the memory space
      beyond 39-bit with the 4K pages or 42-bit with 64K pages requires an
      additional level of translation tables.
      The SPARSEMEM configuration is global to all AArch64 platforms and
      allows for 1GB sections with SPARSEMEM_VMEMMAP enabled by default.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>