1. 05 11月, 2015 1 次提交
  2. 09 10月, 2015 1 次提交
  3. 30 9月, 2015 1 次提交
  4. 09 9月, 2015 6 次提交
  5. 08 9月, 2015 1 次提交
  6. 15 8月, 2015 1 次提交
    • P
      exec: drop cpu_can_do_io, just read cpu->can_do_io · 414b15c9
      Paolo Bonzini 提交于
      After commit 626cf8f4 (icount: set can_do_io outside TB execution,
      2014-12-08), can_do_io is set to 1 if not executing code.  It is
      no longer necessary to make this assumption in cpu_can_do_io.
      
      It is also possible to remove the use_icount test, simply by
      never setting cpu->can_do_io to 0 unless use_icount is true.
      
      With these changes cpu_can_do_io boils down to a read of
      cpu->can_do_io.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      414b15c9
  7. 24 7月, 2015 1 次提交
  8. 09 7月, 2015 2 次提交
  9. 01 7月, 2015 2 次提交
    • P
      main-loop: introduce qemu_mutex_iothread_locked · afbe7053
      Paolo Bonzini 提交于
      This function will be used to avoid recursive locking of the iothread lock
      whenever address_space_rw/ld*/st* are called with the BQL held, which is
      almost always the case.
      
      Tracking whether the iothread is owned is very cheap (just use a TLS
      variable) but requires some care because now the lock must always be
      taken with qemu_mutex_lock_iothread().  Previously this wasn't the case.
      Outside TCG mode this is not a problem.  In TCG mode, we need to be
      careful and avoid the "prod out of compiled code" step if already
      in a VCPU thread.  This is easily done with a check on current_cpu,
      i.e. qemu_in_vcpu_thread().
      
      Hopefully, multithreaded TCG will get rid of the whole logic to kick
      VCPUs whenever an I/O event occurs!
      
      Cc: Frederic Konrad <fred.konrad@greensocs.com>
      Message-Id: <1434646046-27150-3-git-send-email-pbonzini@redhat.com>
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      afbe7053
    • P
      main-loop: use qemu_mutex_lock_iothread consistently · 2e7f7a3c
      Paolo Bonzini 提交于
      The next patch will require the BQL to be always taken with
      qemu_mutex_lock_iothread(), while right now this isn't the case.
      
      Outside TCG mode this is not a problem.  In TCG mode, we need to be
      careful and avoid the "prod out of compiled code" step if already
      in a VCPU thread.  This is easily done with a check on current_cpu,
      i.e. qemu_in_vcpu_thread().
      
      Hopefully, multithreaded TCG will get rid of the whole logic to kick
      VCPUs whenever an I/O event occurs!
      
      Cc: Frederic Konrad <fred.konrad@greensocs.com>
      Message-Id: <1434646046-27150-2-git-send-email-pbonzini@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2e7f7a3c
  10. 23 6月, 2015 2 次提交
  11. 12 6月, 2015 1 次提交
    • J
      migration: Use normal VMStateDescriptions for Subsections · 5cd8cada
      Juan Quintela 提交于
      We create optional sections with this patch.  But we already have
      optional subsections.  Instead of having two mechanism that do the
      same, we can just generalize it.
      
      For subsections we just change:
      
      - Add a needed function to VMStateDescription
      - Remove VMStateSubsection (after removal of the needed function
        it is just a VMStateDescription)
      - Adjust the whole tree, moving the needed function to the corresponding
        VMStateDescription
      Signed-off-by: NJuan Quintela <quintela@redhat.com>
      5cd8cada
  12. 05 6月, 2015 3 次提交
  13. 14 5月, 2015 1 次提交
  14. 30 4月, 2015 1 次提交
  15. 25 3月, 2015 1 次提交
    • P
      cpus: Don't kick un-realized cpus. · bdd459a0
      Peter Crosthwaite 提交于
      following a4649824, it's now possible for
      there to be attempts to take the BQL before CPUs have been realized in
      cases where a machine model inits peripherals before the first CPU.
      
      BQL lock aquisition kicks the first_cpu, leading to a segfault if this
      happens pre-realize. Guard the CPU kick routine to perform no action for
      a CPU that doesn't exist or doesn't have a thread yet.
      
      There was a fix to this with commit
      6b49809c, but the check there misses
      the case where the CPU has been inited and not realized. Strengthen the
      check to make sure that the first_cpu has a thread (i.e. it is
      realized) before allowing the kick.
      Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
      Message-Id: <1427107689-6946-1-git-send-email-peter.crosthwaite@xilinx.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      bdd459a0
  16. 18 3月, 2015 1 次提交
    • A
      profiler: Reenable built-in profiler · 89d5cbdd
      Alexey Kardashevskiy 提交于
      2ed1ebcf "timer: replace time() with QEMU_CLOCK_HOST" broke compile
      when configured with --enable-profiler. Turned out the profiler has been
      broken for a while.
      
      This does s/qemu_time/tcg_time/ as the profiler only works in a TCG mode.
      This also fixes the compile error.
      
      This changes profile_getclock() to return nanoseconds rather than
      CPU ticks as the "profile" HMP command prints seconds and there is no
      platform-independent way to get ticks-per-second rate.
      Since TCG is quite slow and get_clock() returns nanoseconds (fine
      enough), this should not affect precision much.
      
      This removes unused qemu_time_start and tlb_flush_time.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Message-Id: <1426478258-29961-1-git-send-email-aik@ozlabs.ru>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      89d5cbdd
  17. 10 3月, 2015 1 次提交
    • B
      memsave: Improve and disambiguate error message · 0dc9daf0
      Borislav Petkov 提交于
      When requesting a size which cannot be read, the error message shows
      a different address which is misleading to the user and it looks like
      something's wrong with the address parsing. This is because the input
      @addr variable is incremented in the memory dumping loop:
      
      (qemu) memsave 0xffffffff8418069c 0xb00000 mem
      Invalid addr 0xffffffff849ffe9c specified
      
      Fix that by saving the original address and size and use them in the
      error message:
      
      (qemu) memsave 0xffffffff8418069c 0xb00000 mem
      Invalid addr 0xffffffff8418069c/size 11534336 specified
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      0dc9daf0
  18. 02 3月, 2015 2 次提交
    • P
      cpus: be more paranoid in avoiding deadlocks · 21618b3e
      Paolo Bonzini 提交于
      For good measure, ensure that the following sequence:
      
         thread 1 calls qemu_mutex_lock_iothread
         thread 2 calls qemu_mutex_lock_iothread
         VCPU thread are created
         VCPU thread enters execution loop
      
      results in the VCPU threads letting the other two threads run
      and obeying iothread_requesting_mutex even if the VCPUs are
      not halted.  To do this, check iothread_requesting_mutex
      before execution starts.
      Tested-by: NLeon Alrae <leon.alrae@imgtec.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      21618b3e
    • P
      cpus: fix deadlock and segfault in qemu_mutex_lock_iothread · 6b49809c
      Paolo Bonzini 提交于
      When two threads (other than the low-priority TCG VCPU thread)
      are competing for the iothread lock, a deadlock can happen.  This
      is because iothread_requesting_mutex is set to false by the first
      thread that gets the mutex, and then the VCPU thread might never
      yield from the execution loop.  If iothread_requesting_mutex is
      changed from a bool to a counter, the deadlock is fixed.
      
      However, there is another bug in qemu_mutex_lock_iothread that
      can be triggered by the new call_rcu thread.  The bug happens
      if qemu_mutex_lock_iothread is called before the CPUs are
      created.  In that case, first_cpu is NULL and the caller
      segfaults in qemu_mutex_lock_iothread.  To fix this, just
      do not do the kick if first_cpu is NULL.
      Reported-by: NLeon Alrae <leon.alrae@imgtec.com>
      Reported-by: NAndreas Gustafsson <gson@gson.org>
      Tested-by: NLeon Alrae <leon.alrae@imgtec.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6b49809c
  19. 17 2月, 2015 1 次提交
  20. 16 2月, 2015 1 次提交
  21. 02 2月, 2015 1 次提交
    • P
      cpu-exec: simplify init_delay_params · 2e91cc62
      Paolo Bonzini 提交于
      With the introduction of QEMU_CLOCK_VIRTUAL_RT, the computation of
      sc->diff_clk can be simplified nicely:
      
              qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              qemu_clock_get_ns(QEMU_CLOCK_REALTIME) +
              cpu_get_clock_offset()
      
           =  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              (qemu_clock_get_ns(QEMU_CLOCK_REALTIME) - cpu_get_clock_offset())
      
           =  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              (qemu_clock_get_ns(QEMU_CLOCK_REALTIME) + timers_state.cpu_clock_offset)
      
           =  qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) -
              qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL_RT)
      
      Cc: Sebastian Tanase <sebastian.tanase@openwide.fr>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2e91cc62
  22. 14 1月, 2015 1 次提交
  23. 21 12月, 2014 1 次提交
  24. 15 12月, 2014 4 次提交
  25. 16 9月, 2014 1 次提交
  26. 11 9月, 2014 1 次提交