From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCaQL-0005R4-8u for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:20:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCaQC-0001Sj-QX for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:20:01 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:53479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCaQC-0001Sc-Jz for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:19:52 -0400 Received: by mail-wi0-f170.google.com with SMTP id hi8so1257298wib.5 for ; Thu, 22 Aug 2013 12:19:51 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5216642A.7010503@redhat.com> Date: Thu, 22 Aug 2013 21:19:06 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1377187852-11192-1-git-send-email-pbonzini@redhat.com> <5216471E.7020209@redhat.com> In-Reply-To: <5216471E.7020209@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] pvpanic plans? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: pkrempa@redhat.com, mst@redhat.com, libvir-list@redhat.com, hutao@cn.fujitsu.com, marcel.a@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, rhod@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, lcapitulino@redhat.com, afaerber@suse.de Il 22/08/2013 19:15, Laszlo Ersek ha scritto: >> 2) On all versions, will only work if the element is there. > > I like this, because, if on_crash doesn't work without panic_notifier > *at all*, then we can just drop panic_notifier, and make on_crash mean > (on_crash && panic_notifier) in the original sense. > > IOW, drop "panic_notifier", and make "on_crash" work *always*. No, we cannot because of backwards compatibility. VMs could have no on_crash element (which means destroy) and yet the guest admin could expect them to reboot on panic. >> 2b) QEMU will provide a way for libvirt to detect that no machine type >> has the builtin pvpanic. If some machine type may have the builtin >> pvpanic, and is absent, libvirt will add >> "-global pvpanic.iobase=0" to neutralize it. Otherwise, libvirt >> will create the device normally. >> >> A possible way for libvirt to detect "good" machine types is a >> dummy property. This is a bit ugly in that the property would not >> affect the behavior of the device. The property would remain in >> the long term. >> >> Another possibility is for QEMU to rename the device, e.g. to >> isa-pvpanic. This is also somewhat gross, but not visible in the >> long term when the "pvpanic" name will be lost in history. >> >> Advantage 1: libvirt has no knowledge of the pvpanic port number >> >> Disadvantage 1: same as above >> >> Disadvantage 2: need a somewhat gross change in QEMU >> >> >> This method also provides an (also somewhat gross on the QEMU side) >> way to detect other changes in the pvpanic semantics. One example >> mentioned below, is making the panicked state temporary. > > Too much work in qemu, in order to introduce ugliness, to hide older > ugliness. Is it too much work? s/"pvpanic"/"isa-pvpanic"? Paolo