1. 10 Aug, 2017 25 commits
  2. 08 Aug, 2017 6 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
    • Christophe Leroy's avatar
      powerpc/32: Fix boot failure on non 6xx platforms · 64d0a506
      Christophe Leroy authored
      Commit d300627c ("powerpc/6xx: Handle DABR match before calling
      do_page_fault") breaks non 6xx platforms.
      
        Failed to execute /init (error -14)
        Starting init: /bin/sh exists but couldn't execute it (error -14)
        Kernel panic - not syncing: No working init found.  Try passing init= ...
        CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-rc3-s3k-dev-00143-g7aa62e972a56 #56
        Call Trace:
          panic+0x108/0x250 (unreliable)
          rootfs_mount+0x0/0x58
          ret_from_kernel_thread+0x5c/0x64
        Rebooting in 180 seconds..
      
      This is because in handle_page_fault(), the call to do_page_fault() has been
      mistakenly enclosed inside an #ifdef CONFIG_6xx
      
      Fixes: d300627c ("powerpc/6xx: Handle DABR match before calling do_page_fault")
      Brown-paper-bag-to-be-worn-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      64d0a506
    • Frederic Barrat's avatar
      powerpc/powernv: Enable PCI peer-to-peer · 25529100
      Frederic Barrat authored
      P9 has support for PCI peer-to-peer, enabling a device to write in the
      MMIO space of another device directly, without interrupting the CPU.
      
      This patch adds support for it on powernv, by adding a new API to be
      called by drivers. The pnv_pci_set_p2p(...) call configures an
      'initiator', i.e the device which will issue the MMIO operation, and a
      'target', i.e. the device on the receiving side.
      
      P9 really only supports MMIO stores for the time being but that's
      expected to change in the future, so the API allows to define both
      load and store operations.
      
        /* PCI p2p descriptor */
        #define OPAL_PCI_P2P_ENABLE           0x1
        #define OPAL_PCI_P2P_LOAD             0x2
        #define OPAL_PCI_P2P_STORE            0x4
      
        int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target,
                            u64 desc)
      
      It uses a new OPAL call, as the configuration magic is done on the
      PHBs by skiboot.
      Signed-off-by: default avatarFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Reviewed-by: default avatarRussell Currey <ruscur@russell.cc>
      [mpe: Drop unrelated OPAL calls, s/uint64_t/u64/, minor formatting]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      25529100
  3. 03 Aug, 2017 9 commits