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

[Avi Kivity]

On 10/05/2011 08:02 PM, Jan Kiszka wrote:
> >
> >  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.

Migration resume shouldn't overrule user stop.

It's really simple.  If any agent wants the system stopped, it's 
stopped.  Only when no one wants it stopped, it may run.

> 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.

Save: ++stop_count, restore: --stop_count.

> 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.

Please elaborate.

> 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.

Agree with that.  So there's the second proposal:

vm_stop(unsigned reason)
{
    if (!stop_state) {
        do_vm_stop();
    }
    stop_state |= 1 << reason;
}

vm_resume(unsigned reason)
{
    stop_state &= ~(1 << reason);
    if (!stop_state) {
        do_vm_resume();
    }
}

so now each agent is separated from the other.

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