Il 16/09/2014 18:07, Marcelo Tosatti ha scritto: >> > The cpu_synchronize_all_states() call in kvmclock_vm_state_change() is >> > needed to make env->tsc up to date with the value on the source, right? > Its there to make sure the pair > > env->tsc, s->clock = data.clock > > are relative to point close in time.
Ok. But why are they not close in time? Could we have the opposite situation where env->tsc is loaded a long time _after_ s->clock, and something breaks? Also, there is no reason to do kvmclock_current_nsec() during normal execution of the VM. Is the s->clock sent by the source ever good across migration, and could the source send kvmclock_current_nsec() instead of whatever KVM_GET_CLOCK returns? I don't understand this code very well, but it seems to me that the migration handling and VM state change handler are mixed up... Paolo >> > But if the synchronize_all_states+clean_all_dirty pair runs on the >> > source, why is the cpu_synchronize_all_states() call in >> > qemu_savevm_state_complete() not enough? It runs even later than >> > kvmclock_vm_state_change. > Because of the "pair of time values" explanation above.
