Il 21/02/2013 18:34, Juan Quintela ha scritto:
> This move buffered_flush() to inside the iothread lock. At least the
> commit message needs to be changed.
No, it doesn't... Here is the full body of the migration thread:
qemu_mutex_lock_iothread();
qemu_savevm_state_begin(s->file, &s->params);
while (s->state == MIG_STATE_ACTIVE) {
int64_t current_time = qemu_get_clock_ms(rt_clock);
uint64_t pending_size;
if (s->bytes_xfer < s->xfer_limit) {
/* call qemu_savevm_state_* */
}
qemu_mutex_unlock_iothread();
if (current_time >= initial_time + BUFFER_DELAY) {
/* yadda yadda */
s->bytes_xfer = 0;
initial_time = current_time;
}
if (!last_round && (s->bytes_xfer >= s->xfer_limit)) {
/* usleep expects microseconds */
g_usleep((initial_time + BUFFER_DELAY - current_time)*1000);
}
buffered_flush(s);
qemu_mutex_lock_iothread();
if (qemu_file_get_error(s->file)) {
migrate_fd_error(s);
}
}
qemu_mutex_unlock_iothread();
> Looking at the rest of the series before thinking if that is the right
> approach.
The series is fully bisectable. There should be no thread-unsafe patch,
nor any state where blocking calls are done with iothread lock taken
(except at the end of migration where qemu_savevm_state_complete runs
with iothread lock taken; but this happens much later than this patch).
Paolo
