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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2894 bytes --]

On 2011-10-06 16:27, Avi Kivity wrote:
> 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.

That's not what I had in mind. Migration stop could overrule user resume.

But that discussion is moot as there is no time span where this could
happen. Migration just needs to re-enter the original state on error,
savevm/loadvm restore what it found on entry. All this is atomic /wrt
other agents.

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

Every agent can issue every monitor command. If you have a gdb session
running, you don't want the management stack to migrate your VM away or
mess with it otherwise. If you try to migrate a machine, you don't want
any other agent change its configuration beforehand, adding a device
that is not present on the target, etc.

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

Stop reasons are orthogonal to agents.

BTW, the above model would still require extending the user interface to
report pending stop reasons and allow specifying resume reasons.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]