1. 30 5月, 2016 1 次提交
  2. 23 5月, 2016 2 次提交
  3. 19 5月, 2016 2 次提交
  4. 05 4月, 2016 1 次提交
  5. 23 3月, 2016 1 次提交
    • R
      Replaced get_tick_per_sec() by NANOSECONDS_PER_SECOND · 73bcb24d
      Rutuja Shah 提交于
      This patch replaces get_ticks_per_sec() calls with the macro
      NANOSECONDS_PER_SECOND. Also, as there are no callers, get_ticks_per_sec()
      is then removed.  This replacement improves the readability and
      understandability of code.
      
      For example,
      
          timer_mod(fdctrl->result_timer,
      	      qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + (get_ticks_per_sec() / 50));
      
      NANOSECONDS_PER_SECOND makes it obvious that qemu_clock_get_ns
      matches the unit of the expression on the right side of the plus.
      Signed-off-by: NRutuja Shah <rutu.shah.26@gmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      73bcb24d
  6. 17 3月, 2016 1 次提交
  7. 16 3月, 2016 2 次提交
    • P
      icount: decouple warp calls · e76d1798
      Pavel Dovgalyuk 提交于
      qemu_clock_warp function is called to update virtual clock when CPU
      is sleeping. This function includes replay checkpoint to make execution
      deterministic in icount mode.
      Record/replay module flushes async event queue at checkpoints.
      Some of the events (e.g., block devices operations) include interaction
      with hardware. E.g., APIC polled by block devices sets one of IRQ flags.
      Flag to be set depends on currently executed thread (CPU or iothread).
      Therefore in replay mode we have to process the checkpoints in the same thread
      as they were recorded.
      qemu_clock_warp function (and its checkpoint) may be called from different
      thread. This patch decouples two different execution cases of this function:
      call when CPU is sleeping from iothread and call from cpu thread to update
      virtual clock.
      First task is performed by qemu_start_warp_timer function. It sets warp
      timer event to the moment of nearest pending virtual timer.
      Second function (qemu_account_warp_timer) is called from cpu thread
      before execution of the code. It advances virtual clock by adding the length
      of period while CPU was sleeping.
      Signed-off-by: NPavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
      Message-Id: <20160310115609.4812.44986.stgit@PASHA-ISP>
      [Update docs. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e76d1798
    • P
      icount: remove obsolete warp call · 281b2201
      Pavel Dovgalyuk 提交于
      qemu_clock_warp call in qemu_tcg_wait_io_event function is not needed
      anymore, because it is called in every iteration of main_loop_wait.
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NPavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
      Message-Id: <20160310115603.4812.67559.stgit@PASHA-ISP>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      281b2201
  8. 07 3月, 2016 1 次提交
  9. 19 2月, 2016 1 次提交
    • E
      qapi: Don't box branches of flat unions · 544a3731
      Eric Blake 提交于
      There's no reason to do two malloc's for a flat union; let's just
      inline the branch struct directly into the C union branch of the
      flat union.
      
      Surprisingly, fewer clients were actually using explicit references
      to the branch types in comparison to the number of flat unions
      thus modified.
      
      This lets us reduce the hack in qapi-types:gen_variants() added in
      the previous patch; we no longer need to distinguish between
      alternates and flat unions.
      
      The change to unboxed structs means that u.data (added in commit
      cee2dedb) is now coincident with random fields of each branch of
      the flat union, whereas beforehand it was only coincident with
      pointers (since all branches of a flat union have to be objects).
      Note that this was already the case for simple unions - but there
      we got lucky.  Remember, visit_start_union() blindly returns true
      for all visitors except for the dealloc visitor, where it returns
      the value !!obj->u.data, and that this result then controls
      whether to proceed with the visit to the variant.  Pre-patch,
      this meant that flat unions were testing whether the boxed pointer
      was still NULL, and thereby skipping visit_end_implicit_struct()
      and avoiding a NULL dereference if the pointer had not been
      allocated.  The same was true for simple unions where the current
      branch had pointer type, except there we bypassed visit_type_FOO().
      But for simple unions where the current branch had scalar type, the
      contents of that scalar meant that the decision to call
      visit_type_FOO() was data-dependent - the reason we got lucky there
      is that visit_type_FOO() for all scalar types in the dealloc visitor
      is a no-op (only the pointer variants had anything to free), so it
      did not matter whether the dealloc visit was skipped.  But with this
      patch, we would risk leaking memory if we could skip a call to
      visit_type_FOO_fields() based solely on a data-dependent decision.
      
      But notice: in the dealloc visitor, visit_type_FOO() already handles
      a NULL obj - it was only the visit_type_implicit_FOO() that was
      failing to check for NULL. And now that we have refactored things to
      have the branch be part of the parent struct, we no longer have a
      separate pointer that can be NULL in the first place.  So we can just
      delete the call to visit_start_union() altogether, and blindly visit
      the branch type; there is no change in behavior except to the dealloc
      visitor, where we now unconditionally visit the branch, but where that
      visit is now always safe (for a flat union, we can no longer
      dereference NULL, and for a simple union, visit_type_FOO() was already
      safely handling NULL on pointer types).
      
      Unfortunately, simple unions are not as easy to switch to unboxed
      layout; because we are special-casing the hidden implicit type with
      a single 'data' member, we really DO need to keep calling another
      layer of visit_start_struct(), with a second malloc; although there
      are some cleanups planned for simple unions in later patches.
      
      visit_start_union() and gen_visit_implicit_struct() are now unused.
      Drop them.
      
      Note that after this patch, the only remaining use of
      visit_start_implicit_struct() is for alternate types; the next patch
      will do further cleanup based on that fact.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1455778109-6278-14-git-send-email-eblake@redhat.com>
      [Dead code deletion squashed in, commit message updated accordingly]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      544a3731
  10. 09 2月, 2016 1 次提交
  11. 29 1月, 2016 1 次提交
    • P
      exec: Clean up includes · 7b31bbc2
      Peter Maydell 提交于
      Clean up includes so that osdep.h is included first and headers
      which it implies are not included manually.
      
      This commit was created with scripts/clean-includes.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1453832250-766-4-git-send-email-peter.maydell@linaro.org
      7b31bbc2
  12. 26 1月, 2016 1 次提交
    • D
      cpus: use broadcast on qemu_pause_cond · 96bce683
      Dr. David Alan Gilbert 提交于
      Jiri saw a hang on pause_all_vcpus called from postcopy_start,
      where the cpus are all apparently stopped ('stopped' flag set)
      but pause_all_vcpus is still stuck on a cond_wait on qemu_paused_cond.
      We suspect this is happening if a qmp_stop is called at about the
      same time as the postcopy code calls that pause_all_vcpus;
      although they both should have the main lock held, Paolo spotted
      the cond_wait unlocks the global lock so perhaps they both
      could end up waiting at the same time?
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Reported-by: NJiri Denemark <jdenemar@redhat.com>
      Message-Id: <1453716498-27238-1-git-send-email-dgilbert@redhat.com>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      96bce683
  13. 21 1月, 2016 3 次提交
  14. 17 12月, 2015 1 次提交
    • E
      cpu: Convert CpuInfo into flat union · 86f4b687
      Eric Blake 提交于
      The CpuInfo struct is used only by the 'query-cpus' output
      command, so we are free to modify it by adding fields (clients
      are already supposed to ignore unknown output fields), or by
      changing optional members to mandatory, while still keeping
      QMP wire compatibility with older versions of qemu.
      
      When qapi type CpuInfo was originally created for 0.14, we had
      no notion of a flat union, and instead just listed a bunch of
      optional fields with documentation about the mutually-exclusive
      choice of which instruction pointer field(s) would be provided
      for a given architecture.  But now that we have flat unions and
      introspection, it is better to segregate off which fields will
      be provided according to the actual architecture.  With this in
      place, we no longer need the fields to be optional, because the
      choice of the new 'arch' discriminator serves that role.
      
      This has an additional benefit: the old all-in-one struct was
      the only place in the code base that had a case-sensitive
      naming of members 'pc' vs. 'PC'.  Separating these spellings
      into different branches of the flat union will allow us to add
      restrictions against future case-insensitive collisions, since
      that is generally a poor interface practice.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1447836791-369-25-git-send-email-eblake@redhat.com>
      [Spelling of CPUInfo{SPARC,PPC,MIPS} fixed]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      86f4b687
  15. 26 11月, 2015 1 次提交
  16. 06 11月, 2015 3 次提交
  17. 05 11月, 2015 2 次提交
  18. 09 10月, 2015 1 次提交
  19. 30 9月, 2015 1 次提交
  20. 09 9月, 2015 6 次提交
  21. 08 9月, 2015 1 次提交
  22. 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
  23. 24 7月, 2015 1 次提交
  24. 09 7月, 2015 2 次提交
  25. 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