1. 16 9月, 2019 1 次提交
  2. 03 4月, 2019 1 次提交
  3. 22 9月, 2014 2 次提交
    • M
      powerpc/kvm: common sw breakpoint instr across ppc · 033aaa14
      Madhavan Srinivasan 提交于
      This patch extends the use of illegal instruction as software
      breakpoint instruction across the ppc platform. Patch extends
      booke program interrupt code to support software breakpoint.
      Signed-off-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      [agraf: Fix bookehv]
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      033aaa14
    • M
      KVM: PPC: Book3e: Add AltiVec support · 95d80a29
      Mihai Caraman 提交于
      Add AltiVec support in KVM for Book3e. FPU support gracefully reuse host
      infrastructure so follow the same approach for AltiVec.
      
      Book3e specification defines shared interrupt numbers for SPE and AltiVec
      units. Still SPE is present in e200/e500v2 cores while AltiVec is present in
      e6500 core. So we can currently decide at compile-time which of the SPE or
      AltiVec units to support exclusively by using CONFIG_SPE_POSSIBLE and
      CONFIG_PPC_E500MC defines. As Alexander Graf suggested, keep SPE and AltiVec
      exception handlers distinct to improve code readability.
      
      Guests have the privilege to enable AltiVec, so we always need to support
      AltiVec in KVM and implicitly in host to reflect interrupts and to save/restore
      the unit context. KVM will be loaded on cores with AltiVec unit only if
      CONFIG_ALTIVEC is defined. Use this define to guard KVM AltiVec logic.
      Signed-off-by: NMihai Caraman <mihai.caraman@freescale.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      95d80a29
  4. 28 7月, 2014 4 次提交
    • A
      KVM: PPC: Remove 440 support · b2677b8d
      Alexander Graf 提交于
      The 440 target hasn't been properly functioning for a few releases and
      before I was the only one who fixes a very serious bug that indicates to
      me that nobody used it before either.
      
      Furthermore KVM on 440 is slow to the extent of unusable.
      
      We don't have to carry along completely unused code. Remove 440 and give
      us one less thing to worry about.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      b2677b8d
    • B
      kvm: ppc: bookehv: Save restore SPRN_SPRG9 on guest entry exit · 99e99d19
      Bharat Bhushan 提交于
      SPRN_SPRG is used by debug interrupt handler, so this is required for
      debug support.
      Signed-off-by: NBharat Bhushan <Bharat.Bhushan@freescale.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      99e99d19
    • M
      KVM: PPC: Bookehv: Get vcpu's last instruction for emulation · f5250471
      Mihai Caraman 提交于
      On book3e, KVM uses load external pid (lwepx) dedicated instruction to read
      guest last instruction on the exit path. lwepx exceptions (DTLB_MISS, DSI
      and LRAT), generated by loading a guest address, needs to be handled by KVM.
      These exceptions are generated in a substituted guest translation context
      (EPLC[EGS] = 1) from host context (MSR[GS] = 0).
      
      Currently, KVM hooks only interrupts generated from guest context (MSR[GS] = 1),
      doing minimal checks on the fast path to avoid host performance degradation.
      lwepx exceptions originate from host state (MSR[GS] = 0) which implies
      additional checks in DO_KVM macro (beside the current MSR[GS] = 1) by looking
      at the Exception Syndrome Register (ESR[EPID]) and the External PID Load Context
      Register (EPLC[EGS]). Doing this on each Data TLB miss exception is obvious
      too intrusive for the host.
      
      Read guest last instruction from kvmppc_load_last_inst() by searching for the
      physical address and kmap it. This address the TODO for TLB eviction and
      execute-but-not-read entries, and allow us to get rid of lwepx until we are
      able to handle failures.
      
      A simple stress benchmark shows a 1% sys performance degradation compared with
      previous approach (lwepx without failure handling):
      
      time for i in `seq 1 10000`; do /bin/echo > /dev/null; done
      
      real    0m 8.85s
      user    0m 4.34s
      sys     0m 4.48s
      
      vs
      
      real    0m 8.84s
      user    0m 4.36s
      sys     0m 4.44s
      
      A solution to use lwepx and to handle its exceptions in KVM would be to temporary
      highjack the interrupt vector from host. This imposes additional synchronizations
      for cores like FSL e6500 that shares host IVOR registers between hardware threads.
      This optimized solution can be later developed on top of this patch.
      Signed-off-by: NMihai Caraman <mihai.caraman@freescale.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      f5250471
    • M
      KVM: PPC: e500mc: Revert "add load inst fixup" · b5741bb3
      Mihai Caraman 提交于
      The commit 1d628af7 "add load inst fixup" made an attempt to handle
      failures generated by reading the guest current instruction. The fixup
      code that was added works by chance hiding the real issue.
      
      Load external pid (lwepx) instruction, used by KVM to read guest
      instructions, is executed in a subsituted guest translation context
      (EPLC[EGS] = 1). In consequence lwepx's TLB error and data storage
      interrupts need to be handled by KVM, even though these interrupts
      are generated from host context (MSR[GS] = 0) where lwepx is executed.
      
      Currently, KVM hooks only interrupts generated from guest context
      (MSR[GS] = 1), doing minimal checks on the fast path to avoid host
      performance degradation. As a result, the host kernel handles lwepx
      faults searching the faulting guest data address (loaded in DEAR) in
      its own Logical Partition ID (LPID) 0 context. In case a host translation
      is found the execution returns to the lwepx instruction instead of the
      fixup, the host ending up in an infinite loop.
      
      Revert the commit "add load inst fixup". lwepx issue will be addressed
      in a subsequent patch without needing fixup code.
      Signed-off-by: NMihai Caraman <mihai.caraman@freescale.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      b5741bb3
  5. 20 3月, 2014 2 次提交
    • S
      powerpc/booke64: Use SPRG_TLB_EXFRAME on bolted handlers · a3dc6207
      Scott Wood 提交于
      While bolted handlers (including e6500) do not need to deal with a TLB
      miss recursively causing another TLB miss, nested TLB misses can still
      happen with crit/mc/debug exceptions -- so we still need to honor
      SPRG_TLB_EXFRAME.
      
      We don't need to spend time modifying it in the TLB miss fastpath,
      though -- the special level exception will handle that.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Cc: Mihai Caraman <mihai.caraman@freescale.com>
      Cc: kvm-ppc@vger.kernel.org
      a3dc6207
    • S
      powerpc/booke64: Use SPRG7 for VDSO · 9d378dfa
      Scott Wood 提交于
      Previously SPRG3 was marked for use by both VDSO and critical
      interrupts (though critical interrupts were not fully implemented).
      
      In commit 8b64a9df ("powerpc/booke64:
      Use SPRG0/3 scratch for bolted TLB miss & crit int"), Mihai Caraman
      made an attempt to resolve this conflict by restoring the VDSO value
      early in the critical interrupt, but this has some issues:
      
       - It's incompatible with EXCEPTION_COMMON which restores r13 from the
         by-then-overwritten scratch (this cost me some debugging time).
       - It forces critical exceptions to be a special case handled
         differently from even machine check and debug level exceptions.
       - It didn't occur to me that it was possible to make this work at all
         (by doing a final "ld r13, PACA_EXCRIT+EX_R13(r13)") until after
         I made (most of) this patch. :-)
      
      It might be worth investigating using a load rather than SPRG on return
      from all exceptions (except TLB misses where the scratch never leaves
      the SPRG) -- it could save a few cycles.  Until then, let's stick with
      SPRG for all exceptions.
      
      Since we cannot use SPRG4-7 for scratch without corrupting the state of
      a KVM guest, move VDSO to SPRG7 on book3e.  Since neither SPRG4-7 nor
      critical interrupts exist on book3s, SPRG3 is still used for VDSO
      there.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Cc: Mihai Caraman <mihai.caraman@freescale.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: kvm-ppc@vger.kernel.org
      9d378dfa
  6. 09 1月, 2014 1 次提交
  7. 08 1月, 2014 1 次提交
  8. 06 12月, 2012 2 次提交
  9. 27 7月, 2012 1 次提交
  10. 11 7月, 2012 2 次提交
  11. 10 7月, 2012 2 次提交
  12. 06 5月, 2012 4 次提交
  13. 08 4月, 2012 10 次提交