Re: [Qemu-devel] [RFC PATCH v2 0/3] Start fixing the pvpanic mess

[Paolo Bonzini <pbonzini@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 21/08/2013 19:02, Eric Blake ha scritto:
> So, this boils down to a question of what SHOULD the valid states
> for <on_crash> be?  Generically, we want
> <on_crash>destroy</on_crash> to not invalidate a guest, but also to
> not instantiate a pvpanic device; since that covers the libvirt
> defaults.  We also want <on_crash>restart</on_crash> to not
> invalidate a guest, but also to not instantiate a pvpanic device,
> since so many existing guests have that setting thanks to
> virt-install.
> 
> Maybe that means we add attributes/sub-elements to <on_crash> that 
> express whether pvpanic device is permitted; and the absence of
> that attribute means the status quo (the <on_crash> tag is
> effectively ignored because without pvpanic device, there is no way
> for libvirt to learn if a guest panicked).  Or does it mean we
> expose a new sub-element of <devices>, similar to how we have a
> <memballoon> subelement that controls whether the memballoon device
> is show to the guest, and just document that for qemu, <on_crash>
> is a no-op without the <pvpanic> subelement?

Perhaps <panic_notifier bus='isa'/> is better?  Note that for s390
<on_crash> works without <pvpanic>.

Anyway yes, that's a possibility.

More precisely, you could still use <on_crash> for internal errors
even without having anything in <devices> (Xen conflates panics and
internal errors).

But then, "pause" and "ignore" are useful on-panic policies, yet they
do not make sense for internal errors.  Hence my suggestion to
introduce a new element <on_panic>.  We can still make <on_panic> a
no-op without the appropriate element under <devices>.

Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSFPSWAAoJEBvWZb6bTYbywvMP/3MKlED6Y69QM7Xt0aAKEtZp
RmcKUt1m4MAuV91eBmN5/fv+ui0yKzrnZWz0mgF+V3eWCJdnEiewkGocetpx+Mw7
V4wuGVkYUWXV/O8A6x3thENOoxaHYO4OP8dUgkWQLGHXRNTljAd4iyVxBiIbITod
fZvhVEbk8n9Mk3U61JxeMRB5PDjXRHcjgLgpR7htujpVBMTBFAsqxLzflsxsd/p7
UOZ0D3vk6m00DHdIzcJ5pc0dyqaylEaljs3Lf1MNbC/fN8I1sgrMWYMYnukU+moC
GRKS6OB1ySeq2MkMwe73RimtE8M8MNmtVUKle94bmymPdGD3V+qKmBq6o7Hzd+b7
l8Rkht9gWP7Z4T22ZOYVqHpRXaDivkHuRCL2Va3BpyYv48Atyk/G77uB1uSaGTj+
ooRNoEqO61e49JOM3NiEYRI6Gl2YJ5O560j7dK59mQ6OIrLMtuN6Wo1ZiubdKCOa
HB3e6qF0drAEQIBSdqQiU83F58ta634Rqy5R5kc1ad9cuiLMtUDPNbHlKsJtf+Th
Dyu301fxt/1IIxPheoBQNVLRoXtAfoqpxM1nasjRphQqnULpnl7q7MipAclEUadQ
Q7KE0YFPw38BYxl2FWhZOuTNI2kN921PGNiqYFFVpOWCf/aW/uqxU86LnJVSdvZs
T9sRlLpVL4LTGHbFDooI
=nCgT
-----END PGP SIGNATURE-----