Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused

[Avi Kivity <avi@redhat.com>]

On 10/05/2011 06:31 PM, Jan Kiszka wrote:
> >>
> >
> >  vm_start() should be symmetric with vm_stop().  That is, if a piece of
> >  code wants to execute with vcpus stopped, it should just run inside a
> >  stop/start pair.
> >
> >  The only confusion can come from the user, if he sees multiple stop
> >  events and expects that just one cont will continue the vm.  For the
> >  machine monitor, we should just document that the you have to issue one
> >  cont for every stop event you see (plus any stops you issue).  It's not
> >  unnatural - the code that handles a stop_due_to_enospace can work to fix
> >  the error and issue a cont, disregarding any other stops in progress
> >  (due to a user pressing the stop button, or migration, or cpu hotplug,
> >  or whatever).  For the human monitor, it's not so intuitive, but the
> >  situation is so rare we can just rely on the user to issue cont again.
>
> Making this kind of user-visible change would be a bad idea.

The current situation is a bad idea.

Consider a user-initiated or qemu-initiated stop; the user starts to 
deal with it, types 'cont', and as the Enter key is being depressed 
another qemu-initiated stop comes along.  The 'cont' restarts the guest 
even though the second event was not dealt with.

> We are talking about multiple stop states here, but only a single
> function (vm_stop) to enter them - maybe that's not optimal. But the
> point is that we were missing one stop-to-stop transition. And that
> needs to be fixed, either inside vm_stop or when it is called.

Those stops are orthogonal.  There is no relationship between a 
migration stop, a user stop, an ENOSPC stop, a hotplug stop, and a 
debugger stop.  There is no reason to start inventing stop-to-stop 
transitions between them.  A 'cont' intended for one should not undo 
another.

There are two ways to do this, one is to store a set of stop reasons and 
let both 'stop' and 'cont' specify the reason, the other, which is 
simpler but less safe, is to use a reference counting approach.

>
> If you want to lock the VM into paused state, add a new symmetric API
> that does precisely this. That API would send the VM into RSTATE_LOCKED
> if it is not yet stopped on lock or is still locked on resume. That
> would avoid redefining stop states that have no use for lock-counting
> semantics.
>

Which stop states would these be?  When would you want one cont to undo 
two stops?

-- 
error compiling committee.c: too many arguments to function