On Mon, Nov 20, 2023 at 03:55:54PM -0500, Steven Sistare wrote: > If we drop force, then all calls to vm_stop will completely stop the > suspended state, eg an hmp "stop" command. This causes two problems. > First, that is a change in user-visible behavior for something that > currently works,
IMHO it depends on what should be the correct behavior. IOW, when VM is in SUSPENDED state and then the user sends "stop" QMP command, what should we expect? My understanding is we should expect to fully stop the VM, including the ticks, for example. Keeping the ticks running even after QMP "stop" doesn't sound right, isn't it? > vs the migration code where we are fixing brokenness. This is not a migration-only bug if above holds, IMO. > Second, it does not quite work, because the state becomes > RUN_STATE_PAUSED, so the suspended state is forgotten, and the hmp "cont" > will try to set the running state. I could fix that by introducing a new > state RUN_STATE_SUSPENDED_STOPPED, but again it is a user-visible change > in existing behavior. (I even implemented that while developing, then I > realized it was not needed to fix the migration bugs.) Good point. Now with above comments, what's your thoughts on whether we should change the user behavior? My answer is still a yes. Maybe SUSPENDED should not be a RunState at all? SUSPENDED is guest visible behavior, while something like QMP "stop" is not guest visible. Maybe we should remember it separately? It means qemu_system_suspend() could remember that in a separate field (as part of guest state), then when wakeup we should conditionally go back with/without vcpus running depending on the new "suspended" state. -- Peter Xu
