From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCaj8-00075N-LG for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:39:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCaj2-0000Pn-LK for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:39:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCaj2-0000Pa-D9 for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:39:20 -0400 Message-ID: <52166974.4030703@redhat.com> Date: Thu, 22 Aug 2013 21:41:40 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1377187852-11192-1-git-send-email-pbonzini@redhat.com> <5216471E.7020209@redhat.com> <5216642A.7010503@redhat.com> In-Reply-To: <5216642A.7010503@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: Paolo Bonzini 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 On 08/22/13 21:19, Paolo Bonzini wrote: > 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. Ah. I thought "no on_crash" meant ignore, or something like that -- if on_crash was absent, the guest wouldn't see a working pvpanic device in ACPI, and wouldn't trigger the event in qemu. >>> 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"? ... I probably skipped the rename option because you called it gross (and maybe because I (erroneously?) recall Michael's opposition). I think I meant the dummy property under "too much work" (it may not be, in retrospect, but properties always imply compat stuff for me, and *that* is scary). Laszlo