1. 11 6月, 2014 2 次提交
    • M
      powerpc/perf: Ensure all EBB register state is cleared on fork() · 3df48c98
      Michael Ellerman 提交于
      In commit 330a1eb7 "Core EBB support for 64-bit book3s" I messed up
      clear_task_ebb(). It clears some but not all of the task's Event Based
      Branch (EBB) registers when we duplicate a task struct.
      
      That allows a child task to observe the EBBHR & EBBRR of its parent,
      which it should not be able to do.
      
      Fix it by clearing EBBHR & EBBRR.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Cc: stable@vger.kernel.org [v3.11+]
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3df48c98
    • S
      powerpc: Correct DSCR during TM context switch · 96d01610
      Sam bobroff 提交于
      Correct the DSCR SPR becoming temporarily corrupted if a task is
      context switched during a transaction.
      
      The problem occurs while suspending the task and is caused by saving
      the DSCR to thread.dscr after it has already been set to the CPU's
      default value:
      
      __switch_to() calls __switch_to_tm()
      	which calls tm_reclaim_task()
      	which calls tm_reclaim_thread()
      	which calls tm_reclaim()
      		where the DSCR is set to the CPU's default
      __switch_to() calls _switch()
      		where thread.dscr is set to the DSCR
      
      When the task is resumed, it's transaction will be doomed (as usual)
      and the DSCR SPR will be corrupted, although the checkpointed value
      will be correct. Therefore the DSCR will be immediately corrected by
      the transaction aborting, unless it has been suspended. In that case
      the incorrect value can be seen by the task until it resumes the
      transaction.
      
      The fix is to treat the DSCR similarly to the TAR and save it early
      in __switch_to().
      
      A program exposing the problem is added to the kernel self tests as:
      tools/testing/selftests/powerpc/tm/tm-resched-dscr.
      Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
      CC: <stable@vger.kernel.org> [v3.10+]
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      96d01610
  2. 09 1月, 2014 1 次提交
    • P
      KVM: PPC: Use load_fp/vr_state rather than load_up_fpu/altivec · 09548fda
      Paul Mackerras 提交于
      The load_up_fpu and load_up_altivec functions were never intended to
      be called from C, and do things like modifying the MSR value in their
      callers' stack frames, which are assumed to be interrupt frames.  In
      addition, on 32-bit Book S they require the MMU to be off.
      
      This makes KVM use the new load_fp_state() and load_vr_state() functions
      instead of load_up_fpu/altivec.  This means we can remove the assembler
      glue in book3s_rmhandlers.S, and potentially fixes a bug on Book E,
      where load_up_fpu was called directly from C.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      09548fda
  3. 11 12月, 2013 1 次提交
    • S
      powerpc/kvm/booke: Fix build break due to stack frame size warning · f5f97210
      Scott Wood 提交于
      Commit ce11e48b ("KVM: PPC: E500: Add
      userspace debug stub support") added "struct thread_struct" to the
      stack of kvmppc_vcpu_run().  thread_struct is 1152 bytes on my build,
      compared to 48 bytes for the recently-introduced "struct debug_reg".
      Use the latter instead.
      
      This fixes the following error:
      
      cc1: warnings being treated as errors
      arch/powerpc/kvm/booke.c: In function 'kvmppc_vcpu_run':
      arch/powerpc/kvm/booke.c:760:1: error: the frame size of 1424 bytes is larger than 1024 bytes
      make[2]: *** [arch/powerpc/kvm/booke.o] Error 1
      make[1]: *** [arch/powerpc/kvm] Error 2
      make[1]: *** Waiting for unfinished jobs....
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      f5f97210
  4. 19 10月, 2013 1 次提交
  5. 17 10月, 2013 1 次提交
  6. 14 8月, 2013 3 次提交
  7. 09 8月, 2013 1 次提交
  8. 01 7月, 2013 1 次提交
  9. 30 4月, 2012 2 次提交
  10. 08 4月, 2012 1 次提交
  11. 29 3月, 2012 1 次提交