1. 02 Jun, 2015 12 commits
    • Anton Blanchard's avatar
      powerpc/perf: Fix book3s kernel to userspace backtraces · 72e349f1
      Anton Blanchard authored
      When we take a PMU exception or a software event we call
      perf_read_regs(). This overloads regs->result with a boolean that
      describes if we should use the sampled instruction address register
      (SIAR) or the regs.
      
      If the exception is in kernel, we start with the kernel regs and
      backtrace through the kernel stack. At this point we switch to the
      userspace regs and backtrace the user stack with perf_callchain_user().
      
      Unfortunately these regs have not got the perf_read_regs() treatment,
      so regs->result could be anything. If it is non zero,
      perf_instruction_pointer() decides to use the SIAR, and we get issues
      like this:
      
      0.11%  qemu-system-ppc  [kernel.kallsyms]        [k] _raw_spin_lock_irqsave
             |
             ---_raw_spin_lock_irqsave
                |
                |--52.35%-- 0
                |          |
                |          |--46.39%-- __hrtimer_start_range_ns
                |          |          kvmppc_run_core
                |          |          kvmppc_vcpu_run_hv
                |          |          kvmppc_vcpu_run
                |          |          kvm_arch_vcpu_ioctl_run
                |          |          kvm_vcpu_ioctl
                |          |          do_vfs_ioctl
                |          |          sys_ioctl
                |          |          system_call
                |          |          |
                |          |          |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
                |          |          |          |
                |          |          |           --100.00%-- 0x7e714
                |          |          |                     0x7e714
      
      Notice the bogus _raw_spin_irqsave when we transition from kernel
      (system_call) to userspace (0x7e714). We inserted what was in the SIAR.
      
      Add a check in regs_use_siar() to check that the regs in question
      are from a PMU exception. With this fix the backtrace makes sense:
      
           0.47%  qemu-system-ppc  [kernel.vmlinux]         [k] _raw_spin_lock_irqsave
                  |
                  ---_raw_spin_lock_irqsave
                     |
                     |--53.83%-- 0
                     |          |
                     |          |--44.73%-- hrtimer_try_to_cancel
                     |          |          kvmppc_start_thread
                     |          |          kvmppc_run_core
                     |          |          kvmppc_vcpu_run_hv
                     |          |          kvmppc_vcpu_run
                     |          |          kvm_arch_vcpu_ioctl_run
                     |          |          kvm_vcpu_ioctl
                     |          |          do_vfs_ioctl
                     |          |          sys_ioctl
                     |          |          system_call
                     |          |          __ioctl
                     |          |          0x7e714
                     |          |          0x7e714
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      72e349f1
    • Michael Ellerman's avatar
      powerpc/mm: Fix build break with STRICT_MM_TYPECHECKS && DEBUG_PAGEALLOC · 09f3f326
      Michael Ellerman authored
      If both STRICT_MM_TYPECHECKS and DEBUG_PAGEALLOC are enabled, the code
      in kernel_map_linear_page() is built, and so we fail with:
      
        arch/powerpc/mm/hash_utils_64.c:1478:2:
        error: incompatible type for argument 1 of 'htab_convert_pte_flags'
      
      Fix it by using pgprot_val().
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      09f3f326
    • Daniel Axtens's avatar
      powerpc/powernv: Move dma_set_mask() from pnv_phb to pci_controller_ops · 763d2d8d
      Daniel Axtens authored
      Previously, dma_set_mask() on powernv was convoluted:
       0) Call dma_set_mask() (a/p/kernel/dma.c)
       1) In dma_set_mask(), ppc_md.dma_set_mask() exists, so call it.
       2) On powernv, that function pointer is pnv_dma_set_mask().
          In pnv_dma_set_mask(), the device is pci, so call pnv_pci_dma_set_mask().
       3) In pnv_pci_dma_set_mask(), call pnv_phb->set_dma_mask() if it exists.
       4) It only exists in the ioda case, where it points to
          pnv_pci_ioda_dma_set_mask(), which is the final function.
      
      So the call chain is:
       dma_set_mask() ->
        pnv_dma_set_mask() ->
         pnv_pci_dma_set_mask() ->
          pnv_pci_ioda_dma_set_mask()
      
      Both ppc_md and pnv_phb function pointers are used.
      
      Rip out the ppc_md call, pnv_dma_set_mask() and pnv_pci_dma_set_mask().
      
      Instead:
       0) Call dma_set_mask() (a/p/kernel/dma.c)
       1) In dma_set_mask(), the device is pci, and pci_controller_ops.dma_set_mask()
          exists, so call pci_controller_ops.dma_set_mask()
       2) In the ioda case, that points to pnv_pci_ioda_dma_set_mask().
      
      The new call chain is
       dma_set_mask() ->
        pnv_pci_ioda_dma_set_mask()
      
      Now only the pci_controller_ops function pointer is used.
      
      The fallback paths for p5ioc2 are the same.
      
      Previously, pnv_pci_dma_set_mask() would find no pnv_phb->set_dma_mask()
      function, to it would call __set_dma_mask().
      
      Now, dma_set_mask() finds no ppc_md call or pci_controller_ops call,
      so it calls __set_dma_mask().
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      763d2d8d
    • Daniel Axtens's avatar
      powerpc/pci: add dma_set_mask to pci_controller_ops · 3405c257
      Daniel Axtens authored
      Some systems only need to deal with DMA masks for PCI devices.
      For these systems, we can avoid the need for a platform hook and
      instead use a pci controller based hook.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      3405c257
    • Daniel Axtens's avatar
      powerpc/powernv: Specialise pci_controller_ops for each controller type · 92ae0353
      Daniel Axtens authored
      Remove powernv generic PCI controller operations. Replace it with
      controller ops for each of the two supported PHBs.
      
      As an added bonus, make the two new structs const, which will help
      guard against bugs such as the one introduced in 65ebf4b6
      ("powerpc/powernv: Move controller ops from ppc_md to controller_ops")
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      92ae0353
    • Daniel Axtens's avatar
      powerpc: Remove MSI-related PCI controller ops from ppc_md · 1f88d586
      Daniel Axtens authored
      Remove unneeded ppc_md functions. Patch callsites to use pci_controller_ops
      functions exclusively.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1f88d586
    • Daniel Axtens's avatar
      powerpc/mpic_u3msi: Move MSI-related ops to pci_controller_ops · 14f95acd
      Daniel Axtens authored
      Move the u3 MPIC msi subsystem to use the pci_controller_ops structure
      rather than ppc_md for MSI related PCI controller operations.
      
      As with fsl_msi, operations are plugged in at the subsys level, after
      controller creation. Again, we iterate over all controllers and
      populate them with the MSI ops.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      14f95acd
    • Daniel Axtens's avatar
      powerpc/pasemi: Move MSI-related ops to pci_controller_ops · 83922966
      Daniel Axtens authored
      Move the PaSemi MPIC msi subsystem to use the pci_controller_ops
      structure rather than ppc_md for MSI related PCI controller
      operations.
      
      As with fsl_msi, operations are plugged in at the subsys level, after
      controller creation. Again, we iterate over all controllers and
      populate them with the MSI ops.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      83922966
    • Daniel Axtens's avatar
      powerpc/ppc4xx_hsta_msi: Move MSI-related ops to pci_controller_ops · f2c800aa
      Daniel Axtens authored
      Move the ppc4xx hsta msi subsystem to use the pci_controller_ops
      structure rather than ppc_md for MSI related PCI controller
      operations.
      
      As with fsl_msi, operations are plugged in at the subsys level, after
      controller creation. Again, we iterate over all controllers and
      populate them with the MSI ops.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f2c800aa
    • Daniel Axtens's avatar
      powerpc/ppc4xx_msi: Move MSI-related ops to pci_controller_ops · b7eba2ff
      Daniel Axtens authored
      Move the ppc4xx msi subsystem to use the pci_controller_ops structure
      rather than ppc_md for MSI related PCI controller operations.
      
      As with fsl_msi, operations are plugged in at the subsys level, after
      controller creation. Again, we iterate over all controllers and
      populate them with the MSI ops.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      b7eba2ff
    • Daniel Axtens's avatar
      powerpc/fsl_msi: Move MSI-related ops to pci_controller_ops · 00e25397
      Daniel Axtens authored
      Move the fsl_msi subsystem to use the pci_controller_ops structure
      rather than ppc_md for MSI related PCI controller operations.
      
      Previously, MSI ops were added to ppc_md at the subsys level. However,
      in fsl_pci.c, PCI controllers are created at the at arch level. So,
      unlike in e.g. PowerNV/pSeries/Cell, we can't simply populate a
      platform-level controller ops structure and have it copied into the
      controllers when they are created.
      
      Instead, walk every phb, and attempt to populate it with the MSI ops.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      00e25397
    • Daniel Axtens's avatar
      powerpc/pseries: Move MSI-related ops to pci_controller_ops · 1d14b875
      Daniel Axtens authored
      Move the pseries platform to use the pci_controller_ops structure
      rather than ppc_md for MSI related PCI controller operations
      
      We need to iterate all PHBs because the MSI setup happens later than
      find_and_init_phbs() - mpe.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1d14b875
  2. 22 May, 2015 15 commits
  3. 20 May, 2015 1 commit
    • Laurent Dufour's avatar
      powerpc: Enable sys_kcmp() for CRIU · 7978f76c
      Laurent Dufour authored
      The commit 8170a83f ("powerpc: Wireup the kcmp syscall to sys_ni") has
      disabled the kcmp syscall for powerpc.  This has been done due to the use
      of unsigned long parameters which may require a dedicated wrapper to handle
      32bit process on top of 64bit kernel.  However in the kcmp() case, the 2
      unsigned long parameters are currently only used to carry file descriptors
      from user space to the kernel.  Since such a parameter is passed through
      register, and file descriptor doesn't need to get extended, there is,
      today, no need for a wrapper.
      
      In the case there will be a need to pass address in or out of this system
      call, then a wrapper could be required, it will then be to care of it.
      
      As today this is not the case, it is safe to enable kcmp() on powerpc.
      
      Tested (by Laurent) on 64-bit, 32-bit, and 32-bit userspace on 64-bit
      kernel using tools/testing/selftests/kcmp [mpe].
      Signed-off-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7978f76c
  4. 18 May, 2015 1 commit
  5. 13 May, 2015 4 commits
  6. 12 May, 2015 3 commits
  7. 11 May, 2015 4 commits