Am 08.10.2013 10:47, schrieb Paolo Bonzini: > This series moves the icount state under the same seqlock as the "normal" > vm_clock implementation. > > It is not yet 100% thread-safe, because the CPU list should be moved > under RCU protection (due to the call to !all_cpu_threads_idle() > in qemu_clock_warp). However it is a substantial step forward, the > only uncovered case being CPU hotplug. > > Please review. > > Paolo > > Paolo Bonzini (8): > timers: extract timer_mod_ns_locked and timerlist_rearm > timers: add timer_mod_anticipate and timer_mod_anticipate_ns
> timers: use cpu_get_icount() directly > timers: reorganize icount_warp_rt > timers: prepare the code for future races in calling qemu_clock_warp > timers: introduce cpu_get_clock_locked > timers: document (future) locking rules for icount > timers: make icount thread-safe These patches touch cpus.c exclusively, so "timers:" is rather misleading. As you know I have pending patches (in need of rebase due to the performance issue you raised) moving the icount CPU fields around. Is there anything in particular I should be aware of? Looks to me as if this may be orthogonal? What about the previous patch disabling icount for -smp? Does this series supersede it or does it fix different concurrency issues? Thanks, Andreas > cpus.c | 110 > ++++++++++++++++++++++++++++++++++++------------- > include/qemu/timer.h | 26 +++++++++ > qemu-timer.c | 74 +++++++++++++++++++------ > 4 files changed, 163 insertions(+), 47 deletions(-) > create mode 100644 include/qemu/seqlock.h -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
