From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCBoL-0003rY-7D for qemu-devel@nongnu.org; Wed, 21 Aug 2013 13:03:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCBoG-0002v3-93 for qemu-devel@nongnu.org; Wed, 21 Aug 2013 13:03:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCBoF-0002us-Ru for qemu-devel@nongnu.org; Wed, 21 Aug 2013 13:03:04 -0400 Message-ID: <5214F2C0.8050203@redhat.com> Date: Wed, 21 Aug 2013 11:02:56 -0600 From: Eric Blake MIME-Version: 1.0 References: <1377103396-24307-1-git-send-email-pbonzini@redhat.com> <20130821164817.GC10012@redhat.com> <5214EFFF.3060804@redhat.com> In-Reply-To: <5214EFFF.3060804@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OUM7CRFx1cAJWOSM2ukMcspJnGfF6hRU8" Subject: Re: [Qemu-devel] [RFC PATCH v2 0/3] Start fixing the pvpanic mess 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, mst@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, rhod@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, lcapitulino@redhat.com, lersek@redhat.com, afaerber@suse.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OUM7CRFx1cAJWOSM2ukMcspJnGfF6hRU8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/21/2013 10:51 AM, Paolo Bonzini wrote: > Il 21/08/2013 18:48, Daniel P. Berrange ha scritto: >> No, is the right thing to be using for this from >> libvirt's pov & I don't think we should invent something new. >> The element has always been intended to represent >> handling of guest panics, not qemu internal errors. >=20 > Actually for Xen HVM guests, it mostly traps things such as failed > vmentries. The Xen PV-on-HVM drivers do not register a panic notifier > that moves the guest to the "crashed" state. >=20 > cannot be salvaged, in my opinion, because all domain XMLs i= n > the wild will have a setting that causes libvirt to add "-device > isa-pvpanic". Thus changing libvirt versions will change guest > hardware, which is _very_ bad. Let's expand on that statement: Libvirt's default for is 'destroy'. But virt-install (and thus virt-manager) have been setting explicit 'restart' for AGES now. Arguably, this is YET ANOTHER reason why virt-manager should be using libosinfo to make sane choices about new guest XML, based on known capabilities of the guest it will be installing. But that only affects newly created guests after we fix the virt stack. In the meantime, you have a point that we have a back-compat mess - we promise ABI stability (guests shall not see hardware changes when upgrading versions of libvirtd but leaving the XML unchanged - the only way to change hardware seen by an existing guest is to explicitly modify XML). >=20 > In addition, Windows XP and 2003 will show the annoying device wizard > upon a libvirt upgrade, and fixing this is what surfaced all the mess. Yes, so we need the back-compat code to leave pvpanic out of pre-existing guests, if we can find a way to sensibly do that. So, this boils down to a question of what SHOULD the valid states for be? Generically, we want destroy to not invalidate a guest, but also to not instantiate a pvpanic device; since that covers the libvirt defaults. We also want restart 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 that express whether pvpanic device is permitted; and the absence of that attribute means the status quo (the 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 , similar to how we have a subelement that controls whether the memballoon device is show to the guest, and just document that for qemu, is a no-op without the subelement? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --OUM7CRFx1cAJWOSM2ukMcspJnGfF6hRU8 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/ iQEcBAEBCAAGBQJSFPLAAAoJEKeha0olJ0NqOcoH/2dOloY/RgRK6KJhWKgc1SWG kHlwhNwNt5rACat8vrNnAQaeJmpurIT5o0ATE+Atrbkpmtyqh3g/dEFf56RKxDsE L9Q75vVMF+giUJezsMMl0/9PspD59DvZmQlCgfkm4Yh12+nUwjaNKtRqnWUlTR52 sW+RlvfrWS9hrU5ntPAAYw8RKv12eBaRcUNeb7l28UZe6g/wolaKyWky2dRiUuBK X1Pvj5N7csKNEg6ZMjRjTney7Lv48xswhtWndoyCl1CnJC4Kt9aPEMlrPFoT5mib fmTcK1lMHXl5+xE3hnvTWADy93bcrM+s/jt2AbmpNggU0CIsjryiRONR03dWNks= =nEXL -----END PGP SIGNATURE----- --OUM7CRFx1cAJWOSM2ukMcspJnGfF6hRU8--