1. 14 10月, 2014 7 次提交
  2. 13 10月, 2014 12 次提交
  3. 12 8月, 2014 1 次提交
  4. 29 7月, 2014 1 次提交
  5. 05 7月, 2014 1 次提交
  6. 21 6月, 2014 1 次提交
  7. 19 6月, 2014 1 次提交
  8. 18 6月, 2014 1 次提交
    • J
      target-mips: Reset CPU timer consistently · 4b69c7e2
      James Hogan 提交于
      The MIPS CPU timer (CP0 Count/Compare registers & QEMU timer) is
      reset at machine initialisation, including starting the timeout. Both
      registers however are placed before mvp in CPUMIPSState so they will
      both be zeroed on reset by the memset in mips_cpu_reset() including soon
      after init. This doesn't take into account that the timer may be
      running, in which case env->CP0_Count will represent the delta against
      the VM clock and the timeout will need updating.
      
      At init time (cpu_mips_clock_init()), lets only create the timer.
      Setting Count = 1 and starting the timer (cpu_mips_store_count()) can be
      done at reset time from cpu_state_reset(), which is after the memset.
      There is also no need to set CP0_Compare = 0 as that is already handled
      by the memset.
      
      Note that a reset occurs from mips_cpu_realizefn() which is before the
      machine init callback has had a chance to set up the CPU interrupts and
      the CPU timer, so env->timer will be NULL. This case is handled
      explicitly in cpu_mips_store_count(), treating the timer as disabled
      (which will also be the right thing to do when KVM support is added).
      Reported-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4b69c7e2
  9. 05 6月, 2014 1 次提交
  10. 29 5月, 2014 1 次提交
  11. 26 3月, 2014 1 次提交
  12. 14 3月, 2014 2 次提交
  13. 10 2月, 2014 3 次提交
  14. 21 12月, 2013 1 次提交
  15. 09 12月, 2013 1 次提交
  16. 11 10月, 2013 1 次提交
  17. 07 10月, 2013 1 次提交
  18. 03 9月, 2013 1 次提交
  19. 06 8月, 2013 1 次提交
  20. 29 7月, 2013 1 次提交
    • J
      target-mips: fix branch in likely delay slot tcg assert · 240ce26a
      James Hogan 提交于
      When a branch delay slot contains another branch instruction, the code
      generated raises an exception, however since is_branch==1,
      handle_delay_slot() doesn't get called immediately. This means
      ctx->bstate isn't set to BS_BRANCH, and the decoder continues decoding
      until a non-branch instruction is found.
      
      If the first branch was a branch likely instruction then each
      instruction after it generates code for the unlikely case, to go to the
      next tb starting after the delay slot. This results in multiple goto_tb
      tcg ops being generated with the same exit number. When debug is enabled
      this hits:
      
      tcg-op.h:2589: tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed.
      
      This is fixed by removing is_branch entirely, and calling
      handle_delay_slot() if (ctx.hflags & MIPS_HFLAG_BMASK) was set prior to
      the current instruction being decoded. This still prevents
      handle_delay_slot() being called immediately after a branch but allows
      it to still be called after a branch within a delay slot.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NYongbok Kim <yongbok.kim@imgtec.com>
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      240ce26a