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

[Jan Kiszka]

On 2011-10-05 19:12, Avi Kivity wrote:
> 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 can enforce stop for temporal reasons (migration/savevm), something
that overrules user/management initiated stops.

BTW, does stop due to migration actually have a window where it accepts
other commands? I thought that phase is synchronous. Then we would just
have to implement proper state saving/restoring.

Anyway, there is no point in lock counting for stop reasons that require
external synchronization anyway. gdb vs. management stack vs. human
monitor - nothing is solved by counting the stops, they all can step on
each other's shoes. Even worse, exposing a counting stop via the user
interface requires additional interfaces to recover lost or forgotten
locks. We've discussed this in the past IIRC.

Jan

signature.asc
Description: OpenPGP digital signature