diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2013-10-07 17:30:02 +0200 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2013-10-17 17:31:00 +0200 |
commit | ce78d18ced118b03e821135e702ba1d513c8b2a7 (patch) | |
tree | a378f5b85523a1e793f4cc5def8a2a8121735b0b /net | |
parent | 8ed961d95708ee6cadac22fba7762724d533a5b4 (diff) | |
download | qemu-ce78d18ced118b03e821135e702ba1d513c8b2a7.tar.gz qemu-ce78d18ced118b03e821135e702ba1d513c8b2a7.tar.bz2 qemu-ce78d18ced118b03e821135e702ba1d513c8b2a7.zip |
icount: prepare the code for future races in calling qemu_clock_warp
Computing the deadline of all vm_clocks is somewhat expensive and calls
out to qemu-timer.c; two reasons not to do it in the seqlock's write-side
critical section. This however opens the door for races in setting and
reading vm_clock_warp_start.
To plug them, we need to cover the case where a new deadline slips in
between the call to qemu_clock_deadline_ns_all and the actual modification
of the icount_warp_timer. Restrict changes to vm_clock_warp_start and
the icount_warp_timer's expiration time, to only move them back (which
would simply cause an early wakeup).
If a vm_clock timer is cancelled while CPUs are idle, this might cause the
icount_warp_timer to fire unnecessarily. This is not a problem, after it
fires the timer becomes inactive and the next call to timer_mod_anticipate
will be precise.
In addition to this, we must deactivate the icount_warp_timer _before_
checking whether CPUs are idle. This way, if the "last" CPU becomes idle
during the call to timer_del we will still set up the icount_warp_timer.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions