1. 06 11月, 2017 1 次提交
    • N
      KVM: PPC: Book3S HV: Handle host system reset in guest mode · 6de6638b
      Nicholas Piggin 提交于
      If the host takes a system reset interrupt while a guest is running,
      the CPU must exit the guest before processing the host exception
      handler.
      
      After this patch, taking a sysrq+x with a CPU running in a guest
      gives a trace like this:
      
         cpu 0x27: Vector: 100 (System Reset) at [c000000fdf5776f0]
             pc: c008000010158b80: kvmppc_run_core+0x16b8/0x1ad0 [kvm_hv]
             lr: c008000010158b80: kvmppc_run_core+0x16b8/0x1ad0 [kvm_hv]
             sp: c000000fdf577850
            msr: 9000000002803033
           current = 0xc000000fdf4b1e00
           paca    = 0xc00000000fd4d680	 softe: 3	 irq_happened: 0x01
             pid   = 6608, comm = qemu-system-ppc
         Linux version 4.14.0-rc7-01489-g47e1893a404a-dirty #26 SMP
         [c000000fdf577a00] c008000010159dd4 kvmppc_vcpu_run_hv+0x3dc/0x12d0 [kvm_hv]
         [c000000fdf577b30] c0080000100a537c kvmppc_vcpu_run+0x44/0x60 [kvm]
         [c000000fdf577b60] c0080000100a1ae0 kvm_arch_vcpu_ioctl_run+0x118/0x310 [kvm]
         [c000000fdf577c00] c008000010093e98 kvm_vcpu_ioctl+0x530/0x7c0 [kvm]
         [c000000fdf577d50] c000000000357bf8 do_vfs_ioctl+0xd8/0x8c0
         [c000000fdf577df0] c000000000358448 SyS_ioctl+0x68/0x100
         [c000000fdf577e30] c00000000000b220 system_call+0x58/0x6c
         --- Exception: c01 (System Call) at 00007fff76868df0
         SP (7fff7069baf0) is in userspace
      
      Fixes: e36d0a2e ("powerpc/powernv: Implement NMI IPI with OPAL_SIGNAL_SYSTEM_RESET")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6de6638b
  2. 22 10月, 2017 2 次提交
    • M
      powerpc: Disable the fast-endian switch syscall by default · 727f1361
      Michael Ellerman 提交于
      Back in 2008 we added support for "fast little-endian switch" in the
      syscall path. This added a special case syscall number 0x1ebe, which
      is caught very early in the system call exception and switches endian
      with as little overhead as possible. See commit 745a14cc
      ("[POWERPC] Add fast little-endian switch system call") for full
      details.
      
      Although it is fast, it's also completely non standard. The "syscall
      number" is out of the range of normal syscalls, it can't be traced or
      audited, and it's a bit of a wart. To the best of our knowledge it was
      only used by one program, now long since discontinued.
      
      So in an effort to shake out any current users, put it behind a config
      option, and make it default n. If anyone *is* using it they can
      quickly reinstate it with a rebuild, and we can flip it to default y.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      727f1361
    • M
      powerpc/64s: Move the two FAST_ENDIAN macros next to each other · 5c2511bf
      Michael Ellerman 提交于
      So we can #ifdef them in the next patch.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      5c2511bf
  3. 16 10月, 2017 1 次提交
  4. 27 9月, 2017 1 次提交
    • M
      powerpc/64s: Add workaround for P9 vector CI load issue · 5080332c
      Michael Neuling 提交于
      POWER9 DD2.1 and earlier has an issue where some cache inhibited
      vector load will return bad data. The workaround is two part, one
      firmware/microcode part triggers HMI interrupts when hitting such
      loads, the other part is this patch which then emulates the
      instructions in Linux.
      
      The affected instructions are limited to lxvd2x, lxvw4x, lxvb16x and
      lxvh8x.
      
      When an instruction triggers the HMI, all threads in the core will be
      sent to the HMI handler, not just the one running the vector load.
      
      In general, these spurious HMIs are detected by the emulation code and
      we just return back to the running process. Unfortunately, if a
      spurious interrupt occurs on a vector load that's to normal memory we
      have no way to detect that it's spurious (unless we walk the page
      tables, which is very expensive). In this case we emulate the load but
      we need do so using a vector load itself to ensure 128bit atomicity is
      preserved.
      
      Some additional debugfs emulated instruction counters are added also.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      [mpe: Switch CONFIG_PPC_BOOK3S_64 to CONFIG_VSX to unbreak the build]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      5080332c
  5. 23 8月, 2017 7 次提交
  6. 10 8月, 2017 1 次提交
  7. 03 8月, 2017 2 次提交
  8. 31 7月, 2017 1 次提交
    • N
      powerpc/64s: Fix stack setup in watchdog soft_nmi_common() · cc491f1d
      Nicholas Piggin 提交于
      The watchdog soft-NMI exception stack setup loads a stack pointer
      twice, which is an obvious error. It ends up using the system reset
      interrupt (true-NMI) stack, which is also a bug because the watchdog
      could be preempted by a system reset interrupt that overwrites the
      NMI stack.
      
      Change the soft-NMI to use the "emergency stack". The current kernel
      stack is not used, because of the longer-term goal to prevent
      asynchronous stack access using soft-disable.
      
      Fixes: 2104180a ("powerpc/64s: implement arch-specific hardlockup watchdog")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      cc491f1d
  9. 18 7月, 2017 1 次提交
  10. 13 7月, 2017 1 次提交
  11. 03 7月, 2017 2 次提交
  12. 27 6月, 2017 1 次提交
  13. 21 6月, 2017 3 次提交
  14. 20 6月, 2017 3 次提交
  15. 19 6月, 2017 4 次提交
  16. 16 6月, 2017 1 次提交
    • N
      powerpc/64s: Handle data breakpoints in Radix mode · d89ba535
      Naveen N. Rao 提交于
      On Power9, trying to use data breakpoints throws the splat shown
      below. This is because the check for a data breakpoint in DSISR is in
      do_hash_page(), which is not called when in Radix mode.
      
        Unable to handle kernel paging request for data at address 0xc000000000e19218
        Faulting instruction address: 0xc0000000001155e8
        cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
        pc: c0000000001155e8: find_pid_ns+0x48/0xe0
        lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
        sp: c0000000ef1e7da0
        msr: 9000000000009033
        dar: c000000000e19218
        dsisr: 400000
      
      Move the check to handle_page_fault() so as to catch data breakpoints
      in both Hash and Radix MMU modes.
      
      We have to change the check in do_hash_page() against 0xa410 to use
      0xa450, so as to include the value of (DSISR_DABRMATCH << 16).
      
      There are two sites that call handle_page_fault() when in Radix, both
      already pass DSISR in r4.
      
      Fixes: caca285e ("powerpc/mm/radix: Use STD_MMU_64 to properly isolate hash related code")
      Cc: stable@vger.kernel.org # v4.7+
      Reported-by: NShriya R. Kulkarni <shriykul@in.ibm.com>
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      [mpe: Fix the fall-through case on hash, we need to reload DSISR]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d89ba535
  17. 15 6月, 2017 1 次提交
    • N
      powerpc/64s: Optimize hypercall/syscall entry · acd7d8ce
      Nicholas Piggin 提交于
      After bc355125 ("powerpc/64: Allow for relocation-on interrupts from
      guest to host"), a getppid() system call goes from 307 cycles to 358
      cycles (+17%) on POWER8. This is due significantly to the scratch SPR
      used by the hypercall check.
      
      It turns out there are a some volatile registers common to both system
      call and hypercall (in particular, r12, cr0, ctr), which can be used to
      avoid the SPR and some other overheads. This brings getppid to 320 cycles
      (+4%).
      
      Testing hcall entry performance by running "sc 1" in guest userspace
      before this patch is 854 cycles, afterwards is 826. Also a small win
      there.
      
      POWER9 syscall is improved by about the same amount, hcall not tested.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      acd7d8ce
  18. 09 5月, 2017 1 次提交
    • N
      powerpc/64s: Fix unnecessary machine check handler relocation branch · 6102c005
      Nicholas Piggin 提交于
      Similarly to commit 2563a70c ("powerpc/64s: Remove unnecessary relocation
      branch from idle handler"), the machine check handler has a BRANCH_TO from
      relocated to relocated code, which is unnecessary.
      
      It has also caused build errors with some toolchains:
      
        arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
        arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range
        (0xffffffffffff8280 is not between 0x0000000000000000 and
        0x000000000000ffff)
      
      Fixes: 1945bc45 ("powerpc/64s: Fix POWER9 machine check handler from stop state")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Reported-and-tested-by : Abdul Haleem <abdhalee@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6102c005
  19. 28 4月, 2017 5 次提交
  20. 23 4月, 2017 1 次提交
    • N
      powerpc/64s: Fix POWER9 machine check handler from stop state · 1945bc45
      Nicholas Piggin 提交于
      The ISA specifies power save wakeup due to a machine check exception can
      cause a machine check interrupt (rather than the usual system reset
      interrupt).
      
      The machine check handler copes with this by doing low level machine
      check recovery without restoring full state from idle, then queues up a
      machine check event for logging, then directly executes the same idle
      instruction it woke from. This minimises the work done before recovery
      is performed.
      
      The problem is that it requires machine specific instructions and
      knowledge of the book3s idle code. Currently it only has code to handle
      POWER8 idle, so POWER9 crashes when trying to execute the P8 idle
      instructions which don't exist in ISAv3.0B.
      
      cpu 0x0: Vector: e40 (Emulation Assist) at [c0000000008f3810]
          pc: c000000000008380: machine_check_handle_early+0x130/0x2f0
          lr: c00000000053a098: stop_loop+0x68/0xd0
          sp: c0000000008f3a90
         msr: 9000000000081001
        current = 0xc0000000008a1080
        paca    = 0xc00000000ffd0000   softe: 0        irq_happened: 0x01
          pid   = 0, comm = swapper/0
      
      Instead of going to sleep after recovery, do the usual idle wakeup and
      state restoration by calling into the normal idle wakeup path. This
      reuses the normal idle wakeup paths.
      Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Reviewed-by: NMahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      1945bc45