1. 10 Aug, 2017 36 commits
  2. 08 Aug, 2017 4 commits
    • Michael Ellerman's avatar
      powerpc/mm/hash64: Make vmalloc 56T on hash · 21a0e8c1
      Michael Ellerman authored
      On 64-bit book3s, with the hash MMU, we currently define the kernel
      virtual space (vmalloc, ioremap etc.), to be 16T in size. This is a
      leftover from pre v3.7 when our user VM was also 16T.
      
      Of that 16T we split it 50/50, with half used for PCI IO and ioremap
      and the other 8T for vmalloc.
      
      We never bothered to make it any bigger because 8T of vmalloc ought to
      be enough for anybody. But it turns out that's not true, the per cpu
      allocator wants large amounts of vmalloc space, not to make large
      allocations, but to allow a large stride between allocations, because
      we use pcpu_embed_first_chunk().
      
      With a bit of juggling we can increase the entire kernel virtual space
      to 64T. The only real complication is the check of the address in the
      SLB miss handler, see the comment in the code.
      
      Although we could continue to split virtual space 50/50 as we do now,
      no one seems to be running out of PCI IO or ioremap space. So instead
      keep that as 8T, and use the remaining 56T for vmalloc.
      
      In future we should be able to increase the kernel virtual space to
      512T, the code already supports that, it just needs testing on older
      hardware.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      21a0e8c1
    • Michael Ellerman's avatar
      powerpc/mm/slb: Move comment next to the code it's referring to · b5048de0
      Michael Ellerman authored
      There is a comment in slb_allocate() referring to the load of
      paca->vmalloc_sllp, but it's several lines prior in the assembly.
      We're about to change this code, and we want to add another comment,
      so move the comment immediately prior to the instruction it's talking
      about.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      b5048de0
    • Michael Ellerman's avatar
      powerpc/mm/book3s64: Make KERN_IO_START a variable · 63ee9b2f
      Michael Ellerman authored
      Currently KERN_IO_START is defined as:
      
       #define KERN_IO_START  (KERN_VIRT_START + (KERN_VIRT_SIZE >> 1))
      
      Although it looks like a constant, both the components are actually
      variables, to allow us to have a different value between Radix and
      Hash with a single kernel.
      
      However that still requires both Radix and Hash to place the kernel IO
      region at the same location relative to the start and end of the
      kernel virtual region (namely 1/2 way through it), and we'd like to
      change that.
      
      So split KERN_IO_START out into its own variable, and initialise it
      for Radix and Hash. In the medium term we should be able to
      reconsolidate this, by doing a more involved rearrangement of the
      location of the regions.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      63ee9b2f
    • Matt Brown's avatar
      powerpc/powernv: Use darn instruction for get_random_seed() on Power9 · e66ca3db
      Matt Brown authored
      This adds powernv_get_random_darn() which utilises the darn instruction,
      introduced in ISA v3.0/POWER9.
      
      The darn instruction can potentially return an error, which is supported
      by the get_random_seed() API, in normal usage if we see an error we just
      return that to the caller.
      
      However when detecting whether darn is functional at boot we try up to
      10 times, before deciding that darn doesn't work and failing the
      registration of get_random_seed(). That way an intermittent failure
      at boot doesn't deprive the system of randomness until the next reboot.
      Signed-off-by: default avatarMatt Brown <matthew.brown.dev@gmail.com>
      [mpe: Move init into a function, tweak change log]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      e66ca3db