1. 22 1月, 2015 3 次提交
  2. 29 12月, 2014 4 次提交
    • I
      cxl: Disable SPAP register when freeing SPA · db7933f3
      Ian Munsie 提交于
      When we deactivate the AFU directed mode we free the scheduled process
      area, but did not clear the register in the hardware that has a pointer
      to it.
      
      This should be fine since we will have already cleared out every context
      and we won't do anything that would cause the hardware to access it
      until after we have allocated a new one, but just to be safe this patch
      clears out the register when we free the page.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      db7933f3
    • I
      cxl: Disable AFU debug flag · d6a6af2c
      Ian Munsie 提交于
      Upon inspection of the implementation specific registers, it was
      discovered that the high bit of the implementation specific RXCTL
      register was enabled, which enables the DEADB00F debug feature.
      
      The debug feature causes MMIO reads to a disabled AFU to respond with
      0xDEADB00F instead of all Fs. In general this should not be visible as
      the kernel will only allow MMIO access to enabled AFUs, but there may be
      some circumstances where an AFU may become disabled while it is use.
      One such case would be an AFU designed to only be used in the dedicated
      process mode and to disable itself after it has completed it's work
      (however even in that case the effects of this debug flag would be
      limited as the userspace application must have completed any required
      MMIO accesses before the AFU disables itself with or without the flag).
      
      This patch removes the debug flag and replaces the magic value
      programmed into this register with a preprocessor define so it is
      clearer what the rest of this initialisation does.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d6a6af2c
    • I
      cxl: Early return from cxl_handle_fault for a shut down context · 13da7046
      Ian Munsie 提交于
      If a context is being detached and we get a translation fault for it
      there is little point getting it's mm and handling the fault, so just
      respond with an address error and return earlier.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      13da7046
    • I
      cxl: Fix leaking interrupts if attach process fails · 456295e2
      Ian Munsie 提交于
      In this particular error path we have already allocated the AFU
      interrupts, but have not yet set the status to STARTED. The detach
      context code will only attempt to release the interrupts if the context
      is in state STARTED, so in this case the interrupts would remain
      allocated.
      
      This patch releases the AFU interrupts immediately if the attach call
      fails to prevent them leaking.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      456295e2
  3. 12 12月, 2014 3 次提交
    • I
      cxl: Unmap MMIO regions when detaching a context · b123429e
      Ian Munsie 提交于
      If we need to force detach a context (e.g. due to EEH or simply force
      unbinding the driver) we should prevent the userspace contexts from
      being able to access the Problem State Area MMIO region further, which
      they may have mapped with mmap().
      
      This patch unmaps any mapped MMIO regions when detaching a userspace
      context.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b123429e
    • I
      cxl: Add timeout to process element commands · a98e6e9f
      Ian Munsie 提交于
      In the event that something goes wrong in the hardware and it is unable
      to complete a process element comment we would end up polling forever,
      effectively making the associated process unkillable.
      
      This patch adds a timeout to the process element command code path, so
      that we will give up if the hardware does not respond in a reasonable
      time.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a98e6e9f
    • I
      cxl: Change contexts_lock to a mutex to fix sleep while atomic bug · ee41d11d
      Ian Munsie 提交于
      We had a known sleep while atomic bug if a CXL device was forcefully
      unbound while it was in use. This could occur as a result of EEH, or
      manually induced with something like this while the device was in use:
      
      echo 0000:01:00.0 > /sys/bus/pci/drivers/cxl-pci/unbind
      
      The issue was that in this code path we iterated over each context and
      forcefully detached it with the contexts_lock spin lock held, however
      the detach also needed to take the spu_mutex, and call schedule.
      
      This patch changes the contexts_lock to a mutex so that we are not in
      atomic context while doing the detach, thereby avoiding the sleep while
      atomic.
      
      Also delete the related TODO comment, which suggested an alternate
      solution which turned out to not be workable.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      ee41d11d
  4. 05 12月, 2014 1 次提交
    • A
      powerpc/mm: don't do tlbie for updatepp request with NO HPTE fault · aefa5688
      Aneesh Kumar K.V 提交于
      upatepp can get called for a nohpte fault when we find from the linux
      page table that the translation was hashed before. In that case
      we are sure that there is no existing translation, hence we could
      avoid doing tlbie.
      
      We could possibly race with a parallel fault filling the TLB. But
      that should be ok because updatepp is only ever relaxing permissions.
      We also look at linux pte permission bits when filling hash pte
      permission bits. We also hold the linux pte busy bits while
      inserting/updating a hashpte entry, hence a paralle update of
      linux pte is not possible. On the other hand mprotect involves
      ptep_modify_prot_start which cause a hpte invalidate and not updatepp.
      
      Performance number:
      We use randbox_access_bench written by Anton.
      
      Kernel with THP disabled and smaller hash page table size.
      
          86.60%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_updatepp
           2.10%  random_access_b  random_access_bench              [.] doit
           1.99%  random_access_b  [kernel.kallsyms]                [k] .do_raw_spin_lock
           1.85%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_insert
           1.26%  random_access_b  [kernel.kallsyms]                [k] .native_flush_hash_range
           1.18%  random_access_b  [kernel.kallsyms]                [k] .__delay
           0.69%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_remove
           0.37%  random_access_b  [kernel.kallsyms]                [k] .clear_user_page
           0.34%  random_access_b  [kernel.kallsyms]                [k] .__hash_page_64K
           0.32%  random_access_b  [kernel.kallsyms]                [k] fast_exception_return
           0.30%  random_access_b  [kernel.kallsyms]                [k] .hash_page_mm
      
      With Fix:
      
          27.54%  random_access_b  random_access_bench              [.] doit
          22.90%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_insert
           5.76%  random_access_b  [kernel.kallsyms]                [k] .native_hpte_remove
           5.20%  random_access_b  [kernel.kallsyms]                [k] fast_exception_return
           5.12%  random_access_b  [kernel.kallsyms]                [k] .__hash_page_64K
           4.80%  random_access_b  [kernel.kallsyms]                [k] .hash_page_mm
           3.31%  random_access_b  [kernel.kallsyms]                [k] data_access_common
           1.84%  random_access_b  [kernel.kallsyms]                [k] .trace_hardirqs_on_caller
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      aefa5688
  5. 27 11月, 2014 2 次提交
    • M
      cxl: Name interrupts in /proc/interrupt · ca4f8280
      Michael Neuling 提交于
      Currently all interrupts generated by cxl are named "cxl".  This is not very
      informative as we can't distinguish between cards, AFUs, error interrupts, user
      contexts and user interrupts numbers.  Being able to distinguish them is useful
      for setting affinity.
      
      This patch gives each of these names in /proc/interrupts.
      
      A two card CAPI system, with afu0.0 having 2 active contexts each with 4 user
      IRQs each, will now look like this:
      
          % grep cxl /proc/interrupts
          444:          0  OPAL ICS 141312 Level     cxl-card1-err
          445:          0  OPAL ICS 141313 Level     cxl-afu1.0-err
          446:          0  OPAL ICS 141314 Level     cxl-afu1.0
          462:          0  OPAL ICS 2052 Level     cxl-afu0.0-pe0-1
          463:      75517  OPAL ICS 2053 Level     cxl-afu0.0-pe0-2
          468:          0  OPAL ICS 2054 Level     cxl-afu0.0-pe0-3
          469:          0  OPAL ICS 2055 Level     cxl-afu0.0-pe0-4
          470:          0  OPAL ICS 2056 Level     cxl-afu0.0-pe1-1
          471:      75506  OPAL ICS 2057 Level     cxl-afu0.0-pe1-2
          472:          0  OPAL ICS 2058 Level     cxl-afu0.0-pe1-3
          473:          0  OPAL ICS 2059 Level     cxl-afu0.0-pe1-4
          502:       1066  OPAL ICS 2050 Level     cxl-afu0.0
          514:          0  OPAL ICS 2048 Level     cxl-card0-err
          515:          0  OPAL ICS 2049 Level     cxl-afu0.0-err
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca4f8280
    • I
      CXL: Return error to PSL if IRQ demultiplexing fails & print clearer warning · 27bbcef2
      Ian Munsie 提交于
      If an AFU has a hardware bug that causes it to acknowledge a context
      terminate or remove while that context has outstanding transactions, it
      is possible for the kernel to receive an interrupt for that context
      after we have removed it from the context list.
      
      The kernel will not be able to demultiplex the interrupt (or worse - if
      we have already reallocated the process handle we could mis-attribute it
      to the new context), and printed a big scary warning.
      
      It did not acknowledge the interrupt, which would effectively halt
      further translation fault processing on the PSL.
      
      This patch makes the warning clearer about the likely cause of the issue
      (i.e. hardware bug) to make it obvious to future AFU designers of what
      needs to be fixed. It also prints out the process handle which can then
      be matched up with hardware and software traces for debugging.
      
      It also acknowledges the interrupt to the PSL with either an address
      error or acknowledge, so that the PSL can continue with other
      translations.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27bbcef2
  6. 18 11月, 2014 2 次提交
    • M
      cxl: Name interrupts in /proc/interrupt · 80fa93fc
      Michael Neuling 提交于
      Currently all interrupts generated by cxl are named "cxl".  This is not very
      informative as we can't distinguish between cards, AFUs, error interrupts, user
      contexts and user interrupts numbers.  Being able to distinguish them is useful
      for setting affinity.
      
      This patch gives each of these names in /proc/interrupts.
      
      A two card CAPI system, with afu0.0 having 2 active contexts each with 4 user
      IRQs each, will now look like this:
      
          % grep cxl /proc/interrupts
          444:          0  OPAL ICS 141312 Level     cxl-card1-err
          445:          0  OPAL ICS 141313 Level     cxl-afu1.0-err
          446:          0  OPAL ICS 141314 Level     cxl-afu1.0
          462:          0  OPAL ICS 2052 Level     cxl-afu0.0-pe0-1
          463:      75517  OPAL ICS 2053 Level     cxl-afu0.0-pe0-2
          468:          0  OPAL ICS 2054 Level     cxl-afu0.0-pe0-3
          469:          0  OPAL ICS 2055 Level     cxl-afu0.0-pe0-4
          470:          0  OPAL ICS 2056 Level     cxl-afu0.0-pe1-1
          471:      75506  OPAL ICS 2057 Level     cxl-afu0.0-pe1-2
          472:          0  OPAL ICS 2058 Level     cxl-afu0.0-pe1-3
          473:          0  OPAL ICS 2059 Level     cxl-afu0.0-pe1-4
          502:       1066  OPAL ICS 2050 Level     cxl-afu0.0
          514:          0  OPAL ICS 2048 Level     cxl-card0-err
          515:          0  OPAL ICS 2049 Level     cxl-afu0.0-err
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      80fa93fc
    • I
      cxl: Return error to PSL if IRQ demultiplexing fails & print clearer warning · bc78b05b
      Ian Munsie 提交于
      If an AFU has a hardware bug that causes it to acknowledge a context
      terminate or remove while that context has outstanding transactions, it
      is possible for the kernel to receive an interrupt for that context
      after we have removed it from the context list.
      
      The kernel will not be able to demultiplex the interrupt (or worse - if
      we have already reallocated the process handle we could mis-attribute it
      to the new context), and printed a big scary warning.
      
      It did not acknowledge the interrupt, which would effectively halt
      further translation fault processing on the PSL.
      
      This patch makes the warning clearer about the likely cause of the issue
      (i.e. hardware bug) to make it obvious to future AFU designers of what
      needs to be fixed. It also prints out the process handle which can then
      be matched up with hardware and software traces for debugging.
      
      It also acknowledges the interrupt to the PSL with either an address
      error or acknowledge, so that the PSL can continue with other
      translations.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      bc78b05b
  7. 28 10月, 2014 3 次提交
  8. 09 10月, 2014 1 次提交
  9. 08 10月, 2014 3 次提交