From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCAGS-0008JT-2k for qemu-devel@nongnu.org; Wed, 21 Aug 2013 11:24:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCAGN-0004Pb-J0 for qemu-devel@nongnu.org; Wed, 21 Aug 2013 11:24:04 -0400 Message-ID: <5214DB87.6010305@redhat.com> Date: Wed, 21 Aug 2013 09:23:51 -0600 From: Eric Blake MIME-Version: 1.0 References: <1377086477-19553-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1377086477-19553-1-git-send-email-pbonzini@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lLp2sEIg49KrVjw8tA8IQ1sJUwlapS74q" Subject: Re: [Qemu-devel] [PATCH] vl: allow "cont" from panicked state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: pkrempa@redhat.com, marcel.a@redhat.com, libvir-list@redhat.com, hutao@cn.fujitsu.com, qemu-stable@nongnu.org, mst@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, rhod@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, lersek@redhat.com, afaerber@suse.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lLp2sEIg49KrVjw8tA8IQ1sJUwlapS74q Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/21/2013 06:01 AM, Paolo Bonzini wrote: > After reporting the GUEST_PANICKED monitor event, QEMU stops the VM. > The reason for this is that events are edge-triggered, and can be lost = if > management dies at the wrong time. Stopping a panicked VM lets managem= ent > know of a panic even if it has crashed; management can learn about the > panic when it restarts and queries running QEMU processes. The downsid= e > is of course that the VM will be paused while management is not running= , > but that is acceptable if it only happens with explicit "-device pvpani= c". Agreed - the key point is that by having a command line option to opt in to panic handling, then libvirt can decide whether panics should pause or auto-resume based on its settings being mapped to appropriate command lines. >=20 > Upon learning of a panic, management (if configured to do so) can pick = a > variety of behaviors: leave the VM paused, reset it, destroy it. In > addition to all of these behaviors, it is possible dumping the VM core > from the host. s/possible dumping/possible to dump/ and yes, libvirt wants to do just that, as one of its mappings, since it could do the same for Xen. >=20 > However, right now, the panicked state is irreversible, and can only be= > exited by resetting the machine. This means that any policy decision > is entirely in the hands of the host. In particular there is no way to= > use the "reboot on panic" option together with pvpanic. >=20 > This patch makes the panicked state reversible (and removes various > workarounds that were there because of the state being irreversible). > With this change, management has a wider set of possible policies: it > can just log the crash and leave policy to the guest, it can leave the > VM paused. In particular, the "log the crash and continue" is implemen= ted > simply by sending a "cont" as soon as management learns about the panic= =2E > Management could also implement the "irreversible paused state" itself.= > And again, all such actions can be coupled with dumping the VM core. Yes, this makes sense. >=20 > Unfortunately we cannot change the behavior of 1.6.0. Thus, even if > it uses "-device pvpanic", management should check for "cont" failures.= > If "cont" fails, management can then log that the VM remained paused > and urge the administrator to update QEMU. Is that the best we can do? Is there any sort of QMP introspection that libvirt can do, where we can know UP FRONT what level of panic support is provided by the qemu binary and the machine type being run in that binary? I'm afraid we've created a complicated mess of what options work when, and I'm not looking forward to what it will take to encode all the correct workarounds into libvirt. Ideally, I'd like a one-shot question: is qemu new enough to sanely support reversible '-device pvpanic'? If so, honor settings, if not, reject attempts to use any setting other than the default that matches qemu 1.4 behavior - but I might be persuaded to also support qemu 1.5/1.6 behaviors if they are easy enough to detect and work with; there's also the question that the behavior is machine-type dependent (-M pc-1.5 behaves differently than -M pc-1.6). >=20 > I suggest that this patch be included in an 1.6.1 release as soon as > possible, and perhaps in the 1.5 branch too. >=20 > Cc: qemu-stable@nongnu.org > Signed-off-by: Paolo Bonzini > --- > gdbstub.c | 3 --- > vl.c | 6 ++---- > 2 files changed, 2 insertions(+), 7 deletions(-) Reviewed-by: Eric Blake /me why oh why did we rush such a half-baked builtin design into qemu 1.5 again? > +++ b/vl.c > @@ -637,9 +637,8 @@ static const RunStateTransition runstate_transition= s_def[] =3D { > { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING }, > { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE }, > =20 > - { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED }, > + { RUN_STATE_GUEST_PANICKED, RUN_STATE_RUNNING }, Is 'cont' the only viable way to escape PANICKED, or is it also reasonable to support 'stop' as a way to transition from PANICKED to PAUSED? That is, management may want to make the state reversible but still leave the guest paused, so this patch may be incomplete. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --lLp2sEIg49KrVjw8tA8IQ1sJUwlapS74q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSFNuHAAoJEKeha0olJ0NqgX4H/iI3QIUL3/ZLTNWIhgEAQMuu JlqhY9GU7ZZ+78CtzS3Q8HqfaPt4iJ+byYy3mIlOBJtm2rihULmBV7YRVOMwXSVY iMmkKowiJMzzQTmAo3V9eTJgQIEwwW65v9ZklYNMlvA9mDiFLt1DOdh5O3S7NUF8 ERI/SKt5M5DO1GASVvPJwpFQj7+swPPVV7m77kkEAcPCHUxscQFSDNzNOmFM9p+a gje497MSX9NEJWjL45b/bwK1dOMr3ATt8yil9OZ1Ms2cHRwVpdhkfLIqeH4o3bL/ M6jE349UzMxc2fwXloJHqMpbhsSGrkd/5r+nX1DuLnAtI4IguC4aTEwGHOm9CyI= =oIDo -----END PGP SIGNATURE----- --lLp2sEIg49KrVjw8tA8IQ1sJUwlapS74q--