On 25/07/2017 09:29, Jay Zhou wrote: >> >> >> Maybe memory_global_dirty_log_stop can delay itself to the next vm_start >> if it's called while runstate_running() returns false (which should be >> always the case)? > > It is logical, but then we need to put some migration related codes into > the file of cpus.c(in my patch, I put some codes into the file of qmp.c), > is there any elegant way to reduce the coupling?
See below: >> It could even be entirely enclosed within memory.c if you do it with a >> VMChangeStateHandler. If memory_global_dirty_log_stop runs with !runstate_running(), instead of doing the memory transaction you set a VMChangeStateHandler and return immediately. The VMChangeStateHandler then does the actual work just before the VM starts running. memory_global_dirty_log_start also needs to delete the VMChangeStateHandler if it is present. Paolo
