On Thu, Jul 02, 2026 at 10:50:17AM +0200, Paolo Bonzini wrote:
> Sorry, I forgot to reply about this one.
>
> It is not clear why you need to pause, since this is handled by common
> code. Are you not handling live migration yet? That should be handled at
> levels above QEMU, because users expect migration to be performed while the
> VM runs, and the SaveVMHandler should just fail migration of the VM is
> running.
>
> Paolo
>
Hey Paolo,
I spent some time looking at this. it's a bit twisted. The un/pause()
calls are unfortunately named, they are merely freezing the progress of
the reference timer, which for any real-world workload is in fact
pausing the guest b/c if the timer doesn't progress an os would mostly
stall, waiting for ticks.
We want to freeze the timer though during the last phase of the
migration on the source and on the destination (can't set the reference
time if the vcpu time is not frozen). But currently it's the wrong
place. I'll find some more fitting place to perform this ceremony.
Curiously the time-frozen source was obscuring another potentially more
serious bug. The mshv vcpu dispatch loop currently does not honor a
cpu->exit_request, like it is currently set after precopy:
migration_completion_precopy()
migration_stop_vm()
vm_stop_force_state()
vm_stop()
do_vm_stop()
pause_all_vcpus()
cpu_pause()
cpu_exit()
qatomic_store_release(&cpu->exit_request, true)
The two bugs were sort of cancelling each other out. Since the source
guest was not busy, migrations were still succeeding, even though the
the vcpus were not actually "stopped" on the vcpu.
I'll rework this a bit, and submit a revised version.
best,
magnus
