From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCYRM-0005Yo-0o for qemu-devel@nongnu.org; Thu, 22 Aug 2013 13:13:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCYRF-0002JI-OQ for qemu-devel@nongnu.org; Thu, 22 Aug 2013 13:12:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCYRF-0002JB-FZ for qemu-devel@nongnu.org; Thu, 22 Aug 2013 13:12:49 -0400 Message-ID: <5216471E.7020209@redhat.com> Date: Thu, 22 Aug 2013 19:15:10 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1377187852-11192-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1377187852-11192-1-git-send-email-pbonzini@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, 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, afaerber@suse.de On 08/22/13 18:10, Paolo Bonzini wrote: > The thread from yesterday has died off (perhaps also because of > my inappropriate answer to Michael, for which I apologize to him > and everyone). I took some time to discuss the libvirt requirements > further with Daniel Berrange and Eric Blake on IRC. If anyone is > interested, I can give logs. This is a suggestion for how to > proceed in both QEMU and libvirt. The analysis is pretty overwhelming :) I have read Anthony's response and I'm not trying to argue -- I'm just spending a few thoughts on this and I'm willing to let them go to waste. In general I think we should minimize the quirks the user (who edits the libvirt XML) has to know about. Interactions between some XML elements, without explicit inter-references (formulated as attributes, like controller/index) are Bad (TM). So, > == Builtin pvpanic == > > QEMU will remove pvpanic from pc-1.5 in 1.6.1 and 1.5.4. This does not > break migration. > > > == Support in libvirt for current functionality == > > libvirt will add a element, and possibly a capability > for it accessible via "virsh capabilities". There are two possibilities: > > 1) On QEMU 1.5.4/1.6.1 and newer (and on QEMU 1.6.0 with a machine type > other than pc-1.5), will only work if the element is there. > On QEMU 1.5.0->1.5.3, and on QEMU 1.6.0 with the pc-1.5 machine type, > will be obeyed always, and may override e.g. reboot-on-panic > if a guest driver exist. I don't like this because there's some interplay between on_crash and panic_notifier, which even depends on the qemu version. > > 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*. > > > In turn, there are two ways to implement (2): > > 2a) libvirt will always add -global pvpanic.iobase=0 to neutralize > the builtin pvpanic device if present. > will create the device with -device pvpanic,iobase=0x505 > > Advantage: no changes to QEMU > > Disadvantage 1: writes to port 0 with QEMU 1.{5.0,5.1,5.2,5.3,6.0} > and pc-1.5 machine type will write to a pvpanic device instead of > the DMA controller. Probably harmless, and limited to some QEMU > versions. > > Disadvantage 2: libvirt has knowledge of the pvpanic port number Updating this paragraph with my above suggestion: - (s/pvpanic.iobase/pvpanic.ioport/g) - if "on_crash" is absent: - for 1.{5.0,5.1,5.2,5.3,6.0}, add -global pvpanic.ioport=0 - for other versions, do nothing - if "on_crash" is present: - for 1.{5.0,5.1,5.2,5.3,6.0}, do nothing, - for other versions, pass -device pvpanic (knowledge of 0x505 is unneeded) "advantage" and "disadvantage 1" remain, "disadvantage 2" is gone. > 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. > == Possible improvements to pvpanic == That's too complex / far out for me now, sorry :) Thanks, Laszlo