| commit | 9b4e6f496601d3cd35fd8d09c9e2103999fd5c33 | |
| author | Paolo Bonzini <pbonzini@redhat.com> | |
| Tue, 11 Sep 2018 11:15:32 +0000 (11 13:15 +0200) | ||
| committer | Paolo Bonzini <pbonzini@redhat.com> | |
| Tue, 2 Oct 2018 16:47:55 +0000 (2 18:47 +0200) | ||
| tree | ccab9fa8b0930f3cc1bf9e675b721679a0e869d6 | treesnapshot (tar.gz zip) |
| parent | 39fe576c82bc02749410ea16045109f7b7d4af62 | commitdiff |
cpus: take seqlock across qemu_icount updates
Even though writes of qemu_icount can safely race with reads in
qemu_icount_raw, qemu_icount is also read by icount_adjust, which
runs in the I/O thread. Therefore, writes do needs protection of
the vm_clock_lock; for simplicity the patch protects it with both
seqlock+spinlock, which we already do for hosts that lack 64-bit atomics.
The bug actually predated the introduction of vm_clock_lock;
cpu_update_icount would have needed the BQL before the spinlock was
introduced.
Reported-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Even though writes of qemu_icount can safely race with reads in
qemu_icount_raw, qemu_icount is also read by icount_adjust, which
runs in the I/O thread. Therefore, writes do needs protection of
the vm_clock_lock; for simplicity the patch protects it with both
seqlock+spinlock, which we already do for hosts that lack 64-bit atomics.
The bug actually predated the introduction of vm_clock_lock;
cpu_update_icount would have needed the BQL before the spinlock was
introduced.
Reported-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| cpus.c | diffblobblamehistory |