From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:56397)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UIGg5-0007eE-LD
	for qemu-devel@nongnu.org; Wed, 20 Mar 2013 06:55:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UIGfu-00075d-6b
	for qemu-devel@nongnu.org; Wed, 20 Mar 2013 06:55:29 -0400
Received: from mx1.redhat.com ([209.132.183.28]:9224)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UIGft-00075U-VC
	for qemu-devel@nongnu.org; Wed, 20 Mar 2013 06:55:18 -0400
Message-ID: <5149957B.70505@redhat.com>
Date: Wed, 20 Mar 2013 11:54:51 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <cover.1363243596.git.hutao@cn.fujitsu.com>
	<a7ce000ee0790d5e5d8c7c51684687ed7dc8c0c0.1363243596.git.hutao@cn.fujitsu.com>
	<87y5dimorn.fsf@blackfin.pond.sub.org>
In-Reply-To: <87y5dimorn.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v14 1/4] add a new runstate:
	RUN_STATE_GUEST_PANICKED
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Gleb Natapov <gleb@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, Hu Tao <hutao@cn.fujitsu.com>, qemu-devel <qemu-devel@nongnu.org>, Luiz Capitulino <lcapitulino@redhat.com>, Blue Swirl <blauwirbel@gmail.com>, Orit Wasserman <owasserm@redhat.com>, Juan Quintela <quintela@redhat.com>, Alexander Graf <agraf@suse.de>, Christian Borntraeger <borntraeger@de.ibm.com>, Jan Kiszka <jan.kiszka@siemens.com>, Andrew Jones <drjones@redhat.com>, Alex Williamson <alex.williamson@redhat.com>, Sasha Levin <levinsasha928@gmail.com>, Stefan Hajnoczi <stefanha@redhat.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Marcelo Tosatti <mtosatti@redhat.com>

Il 20/03/2013 09:58, Markus Armbruster ha scritto:
> Let's examine the other transitions to RUN_STATE_PAUSED, and whether
> they can now come from RUN_STATE_GUEST_PANICKED:
> 
> * process_incoming_migration_co()
> 
>   No, because we're in RUN_STATE_INMIGRATE here, aren't we?  Juan?

Yes.

> * qmp_stop()
> 
>   No, because vm_stop() calls do_vm_stop() to do the actual state
>   transition, which protects it by runstate_is_running().
> 
>   We can ignore the conditional, it merely punts the vm_stop() to the
>   main loop.
> 
> Next question: RUN_STATE_INTERNAL_ERROR and RUN_STATE_SHUTDOWN may go to
> RUN_STATE_FINISH_MIGRATE, but RUN_STATE_GUEST_PANICKED may not.  Why?

RUN_STATE_FINISH_MIGRATE is reached with vm_stop_force_state, so every
state can go there.  Next question: why doesn't the switch to
RUN_STATE_SAVE_VM use vm_stop_force_state?

Next question: almost all states go to RUN_STATE_FINISH_MIGRATE, the
same would hold for RUN_STATE_SAVE_VM if it started using
vm_stop_force_state.  There are few exceptions, and I'm not even sure
all of them are correct (why can't RUN_STATE_DEBUG go to
RUN_STATE_FINISH_MIGRATE?).

Should vm_stop_force_state override the runstate check (either directly,
or by interposing a transition to RUN_STATE_PAUSED? The few outliers can
be handled with manually-placed assertions.

Paolo