On Tue, 28 Apr 2020 14:43:20 +0100, "Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote: > * Adalbert Lazăr (ala...@bitdefender.com) wrote: > > One use case is to do VM introspection all the time the guest is running. > > From the user perspective, the pause/suspend/shutdown/snapshot/migrate > > commands should work regardless if the VM is currently introspected > > or not. Our first option was to delay these commands for a couple of > > seconds when the VM is introspected, while the introspection app reverts > > its changes, without blocking the vCPUs. > > Ah OK, so it's not really about blocking it completely; just delaying it > a bit; in that case add_blocker is the wrong thing. > > > I'll see if we can mix the migrate notifier with migrate_add_blocker(), > > or add a new migration state. To block the migration (with an error) > > is our second option, because the user doing this might not be allowed > > to stop the VM introspection. > > Maybe the right thing is to do something just like > MIGRATION_STATUS_WAIT_UNPLUG, it's right near the start of the thread. > Again it's job is just to make the migration wait while it does some > stuff before it can let migration continue. >
This is it! Thank you, Dave. We already register a VMStateDescription structure to save the VM start time ([18/26] kvm: vmi: store/restore 'vm_start_time' on migrate/snapshot [1]). All we have to do is setup the dev_unplug_pending callback and return true when the introspection channel is still active. [1]: https://lore.kernel.org/qemu-devel/20200415005938.23895-19-ala...@bitdefender.com/
