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

[Avi Kivity <avi@redhat.com>]

On 10/05/2011 06:49 PM, Jan Kiszka wrote:
> On 2011-10-05 18:37, Avi Kivity wrote:
> >  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.
>
> You always have this kind of problems when you attach two keyboards to
> the same console. A counting stop/cont will just create different
> effects of the same problem but not solve it.

Let's examine a concrete example: a user is debugging a guest, which 
stops at a breakpoint.  Meanwhile a live migration is going on, 
involving internal stops.  When the guest does manage to run for a bit, 
it runs out of disk space, generating a stop, which the management agent 
resolves by allocating more space and issuing a cont.

With a counting cont, no matter in what order these events happen, 
things work out fine.  How do they work out with your proposal?

> >
> >>  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.
>
> No, they aren't. They are all different states, and we need to model
> transitions between them. If there are redundant states, lets collapse them.

What's the state caused by 'stopped-due-to-migration-phase-3' and 
'stopped-due-to-breakpoint'? 
'stopped-due-to-migration-phase-3-and-breakpoint'?

> >>
> >
> >  Which stop states would these be?  When would you want one cont to undo
> >  two stops?
>
> No, cont would remain cont: the resume-after-stop command.
>
> Locking would never be user-exposed. It would be a QEMU-internal thing,
> used when there must be no resume for a certain finite while (e.g.
> during migration or savevm). I think one problem with the current state
> machine is that it does not differentiate between these two types of "stop".
>

My second proposal (a set of stop reasons) differentiates between all 
kinds of cont.  Maybe we should extend the monitor command to cont [reason].


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