All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
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>
Subject: Re: [Qemu-devel] [PATCH v14 1/4] add a new runstate: RUN_STATE_GUEST_PANICKED
Date: Wed, 20 Mar 2013 11:54:51 +0100	[thread overview]
Message-ID: <5149957B.70505@redhat.com> (raw)
In-Reply-To: <87y5dimorn.fsf@blackfin.pond.sub.org>

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

  reply	other threads:[~2013-03-20 10:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14  8:15 [Qemu-devel] [PATCH v14 0/4] pvevent device to deal with guest panic event Hu Tao
2013-03-14  8:15 ` [Qemu-devel] [PATCH v14 1/4] add a new runstate: RUN_STATE_GUEST_PANICKED Hu Tao
2013-03-20  8:58   ` Markus Armbruster
2013-03-20 10:54     ` Paolo Bonzini [this message]
2013-03-20 11:07     ` Markus Armbruster
2013-03-14  8:15 ` [Qemu-devel] [PATCH v14 2/4] add a new qevent: QEVENT_GUEST_PANICKED Hu Tao
2013-03-20  9:04   ` Markus Armbruster
2013-03-14  8:15 ` [Qemu-devel] [PATCH v14 3/4] introduce pvevent device to deal with panicked event Hu Tao
2013-03-14  9:14   ` Paolo Bonzini
2013-03-14  9:19     ` Gleb Natapov
2013-03-14  9:43       ` Paolo Bonzini
2013-03-14 11:00         ` Alexander Graf
2013-03-14 11:03           ` Paolo Bonzini
2013-03-14 11:23             ` Alexander Graf
2013-03-14 11:28               ` Gleb Natapov
2013-03-20  9:24           ` Markus Armbruster
2013-03-14 12:34         ` Gleb Natapov
2013-03-14 13:49           ` Paolo Bonzini
2013-03-14 13:56             ` Gleb Natapov
2013-03-14 14:05               ` Paolo Bonzini
2013-03-14 14:23                 ` Gleb Natapov
2013-03-14 15:50                   ` Paolo Bonzini
2013-03-14 15:59                     ` Gleb Natapov
2013-03-14 16:13                       ` Paolo Bonzini
2013-03-15 11:34                         ` Gleb Natapov
2013-03-20  9:16                         ` Markus Armbruster
2013-03-14  9:46     ` Hu Tao
2013-03-20  9:15   ` Markus Armbruster
2013-03-14  8:15 ` [Qemu-devel] [PATCH v14 4/4] pvevent: add document to describe the usage Hu Tao
2013-03-14  8:45   ` Paolo Bonzini
2013-03-14  9:35     ` Hu Tao
2013-03-14 20:35   ` Eric Blake
2013-03-14  8:58 ` [Qemu-devel] [PATCH v14 0/4] pvevent device to deal with guest panic event Gleb Natapov
2013-03-14  9:36   ` Hu Tao
2013-03-20  9:29   ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5149957B.70505@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=borntraeger@de.ibm.com \
    --cc=drjones@redhat.com \
    --cc=gleb@redhat.com \
    --cc=hutao@cn.fujitsu.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=levinsasha928@gmail.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=owasserm@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.