qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] runstate: do not discard runstate changes when paused
Date: Wed, 05 Oct 2011 19:12:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]