Il ven 3 lug 2026, 19:22 Magnus Kulke <[email protected]> ha scritto:
> 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. > There are different "schools of thought" for that. Freezing introduces an incorrect timing on the destination, not freezing introduces a jump. If you choose to freeze that's fine, QEMU does the same for KVM even though KVM has alternative ioctls that allow not freezing. But currently it's the wrong > place. I'll find some more fitting place to perform this ceremony. > KVM uses a device for that, see kvnclock.c. 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 Was that related to the other patch that was touching the vcpu thread loop? Paolo 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 > >
