1. 04 10月, 2016 25 次提交
  2. 23 9月, 2016 2 次提交
    • N
      powerpc/pseries: Remove unnecessary syscall trampoline · a24553dd
      Nicholas Piggin 提交于
      When we originally added the ability to split the exception vectors from
      the kernel (commit 1f6a93e4 ("powerpc: Make it possible to move the
      interrupt handlers away from the kernel" 2008-09-15)), the LOAD_HANDLER() macro
      used an addi instruction to compute the offset of the common handler
      from the kernel base address.
      
      Using addi meant the handler had to be within 32K of the kernel base
      address, due to the addi instruction taking a signed immediate value.
      That necessitated creating a trampoline for the system call handler,
      because system_call_common (in entry64.S) is not linked within 32K of
      the kernel base address.
      
      Later in commit 61e2390e ("powerpc: Make load_hander handle upto 64k
      offset" 2012-11-15) we changed LOAD_HANDLER to take a 64K offset, by
      changing it to use ori.
      
      Although system_call_common is not in head_64.S or exceptions-64s.S, it
      is included in head-y, which causes it to be linked early in the kernel
      text, so in practice it ends up below 64K. Additionally if it can't be
      placed below 64K the linker will fail to build with a "relocation
      truncated to fit" error.
      
      So remove the trampoline.
      
      Newer toolchains are able to work out that the ori in LOAD_HANDLER only
      takes a 16 bit offset, and so they generate a 16 bit relocation. Older
      toolchains (binutils 2.22 at least) are not so smart, so we have to add
      the @l annotation to tell the assembler to generate a 16 bit relocation.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a24553dd
    • N
      powerpc/pseries: Fix HV facility unavailable to use correct handler · 40e1b1cf
      Nicholas Piggin 提交于
      The 0xf80 hv_facility_unavailable trampoline branches to the 0xf60
      handler. This works because they both do the same thing, but it should
      be fixed.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      40e1b1cf
  3. 20 9月, 2016 1 次提交
  4. 13 9月, 2016 2 次提交
    • M
      powerpc/64: Do load of PACAKBASE in LOAD_HANDLER · d8d42b05
      Michael Ellerman 提交于
      The LOAD_HANDLER macro requires that you have previously loaded "reg"
      with PACAKBASE. Although that gives callers flexibility to get PACAKBASE
      in some interesting way, none of the callers actually do that. So fold
      the load of PACAKBASE into the macro, making it simpler for callers to
      use correctly.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NNick Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d8d42b05
    • P
      powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address · f0f558b1
      Paul Mackerras 提交于
      Currently, if userspace or the kernel accesses a completely bogus address,
      for example with any of bits 46-59 set, we first take an SLB miss interrupt,
      install a corresponding SLB entry with VSID 0, retry the instruction, then
      take a DSI/ISI interrupt because there is no HPT entry mapping the address.
      However, by the time of the second interrupt, the Come-From Address Register
      (CFAR) has been overwritten by the rfid instruction at the end of the SLB
      miss interrupt handler.  Since bogus accesses can often be caused by a
      function return after the stack has been overwritten, the CFAR value would
      be very useful as it could indicate which function it was whose return had
      led to the bogus address.
      
      This patch adds code to create a full exception frame in the SLB miss handler
      in the case of a bogus address, rather than inserting an SLB entry with a
      zero VSID field.  Then we call a new slb_miss_bad_addr() function in C code,
      which delivers a signal for a user access or creates an oops for a kernel
      access.  In the latter case the oops message will show the CFAR value at the
      time of the access.
      
      In the case of the radix MMU, a segment miss interrupt indicates an access
      outside the ranges mapped by the page tables.  Previously this was handled
      by the code for an unrecoverable SLB miss (one with MSR[RI] = 0), which is
      not really correct.  With this patch, we now handle these interrupts with
      slb_miss_bad_addr(), which is much more consistent.
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      f0f558b1
  5. 22 8月, 2016 2 次提交
  6. 09 8月, 2016 1 次提交
  7. 01 8月, 2016 1 次提交
  8. 17 7月, 2016 2 次提交
  9. 15 7月, 2016 2 次提交
  10. 23 6月, 2016 1 次提交
    • M
      powerpc: Fix faults caused by radix patching of SLB miss handler · 6e914ee6
      Michael Ellerman 提交于
      As part of the Radix MMU support we added some feature sections in the
      SLB miss handler. These are intended to catch the case that we
      incorrectly take an SLB miss when Radix is enabled, and instead of
      crashing weirdly they bail out to a well defined exit path and trigger
      an oops.
      
      However the way they were written meant the bailout case was enabled by
      default until we did CPU feature patching.
      
      On powermacs the early debug prints in setup_system() can cause an SLB
      miss, which happens before code patching, and so the SLB miss handler
      would incorrectly bailout and crash during boot.
      
      Fix it by inverting the sense of the feature section, so that the code
      which is in place at boot is correct for the hash case. Once we
      determine we are using Radix - which will never happen on a powermac -
      only then do we patch in the bailout case which unconditionally jumps.
      
      Fixes: caca285e ("powerpc/mm/radix: Use STD_MMU_64 to properly isolate hash related code")
      Reported-by: NDenis Kirjanov <kda@linux-powerpc.org>
      Tested-by: NDenis Kirjanov <kda@linux-powerpc.org>
      Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6e914ee6
  11. 20 6月, 2016 1 次提交
    • M
      KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt · fd7bacbc
      Mahesh Salgaonkar 提交于
      When a guest is assigned to a core it converts the host Timebase (TB)
      into guest TB by adding guest timebase offset before entering into
      guest. During guest exit it restores the guest TB to host TB. This means
      under certain conditions (Guest migration) host TB and guest TB can differ.
      
      When we get an HMI for TB related issues the opal HMI handler would
      try fixing errors and restore the correct host TB value. With no guest
      running, we don't have any issues. But with guest running on the core
      we run into TB corruption issues.
      
      If we get an HMI while in the guest, the current HMI handler invokes opal
      hmi handler before forcing guest to exit. The guest exit path subtracts
      the guest TB offset from the current TB value which may have already
      been restored with host value by opal hmi handler. This leads to incorrect
      host and guest TB values.
      
      With split-core, things become more complex. With split-core, TB also gets
      split and each subcore gets its own TB register. When a hmi handler fixes
      a TB error and restores the TB value, it affects all the TB values of
      sibling subcores on the same core. On TB errors all the thread in the core
      gets HMI. With existing code, the individual threads call opal hmi handle
      independently which can easily throw TB out of sync if we have guest
      running on subcores. Hence we will need to co-ordinate with all the
      threads before making opal hmi handler call followed by TB resync.
      
      This patch introduces a sibling subcore state structure (shared by all
      threads in the core) in paca which holds information about whether sibling
      subcores are in Guest mode or host mode. An array in_guest[] of size
      MAX_SUBCORE_PER_CORE=4 is used to maintain the state of each subcore.
      The subcore id is used as index into in_guest[] array. Only primary
      thread entering/exiting the guest is responsible to set/unset its
      designated array element.
      
      On TB error, we get HMI interrupt on every thread on the core. Upon HMI,
      this patch will now force guest to vacate the core/subcore. Primary
      thread from each subcore will then turn off its respective bit
      from the above bitmap during the guest exit path just after the
      guest->host partition switch is complete.
      
      All other threads that have just exited the guest OR were already in host
      will wait until all other subcores clears their respective bit.
      Once all the subcores turn off their respective bit, all threads will
      will make call to opal hmi handler.
      
      It is not necessary that opal hmi handler would resync the TB value for
      every HMI interrupts. It would do so only for the HMI caused due to
      TB errors. For rest, it would not touch TB value. Hence to make things
      simpler, primary thread would call TB resync explicitly once for each
      core immediately after opal hmi handler instead of subtracting guest
      offset from TB. TB resync call will restore the TB with host value.
      Thus we can be sure about the TB state.
      
      One of the primary threads exiting the guest will take up the
      responsibility of calling TB resync. It will use one of the top bits
      (bit 63) from subcore state flags bitmap to make the decision. The first
      primary thread (among the subcores) that is able to set the bit will
      have to call the TB resync. Rest all other threads will wait until TB
      resync is complete.  Once TB resync is complete all threads will then
      proceed.
      Signed-off-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      fd7bacbc