From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCaoc-0002Tt-2l for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:45:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCaoN-0002QU-AR for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:45:06 -0400 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:47061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCaoN-0002Q8-1f for qemu-devel@nongnu.org; Thu, 22 Aug 2013 15:44:51 -0400 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 Aug 2013 20:41:45 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id DBD5C1B08061 for ; Thu, 22 Aug 2013 20:44:48 +0100 (BST) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7MJiZIN51445922 for ; Thu, 22 Aug 2013 19:44:35 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r7MJikdr008108 for ; Thu, 22 Aug 2013 13:44:46 -0600 Message-ID: <52166A2D.9000303@de.ibm.com> Date: Thu, 22 Aug 2013 21:44:45 +0200 From: Christian Borntraeger MIME-Version: 1.0 References: <1377187852-11192-1-git-send-email-pbonzini@redhat.com> <5216471E.7020209@redhat.com> <87d2p5mv7u.fsf@codemonkey.ws> In-Reply-To: <87d2p5mv7u.fsf@codemonkey.ws> 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: Anthony Liguori 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, Paolo Bonzini , lcapitulino@redhat.com, Laszlo Ersek , afaerber@suse.de On 22/08/13 20:33, Anthony Liguori wrote: > Laszlo Ersek writes: > >> 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) > > Just to further complicate things... > > pvpanic is not going to be present on S390, PPC, ARM, or MIPS because of > the fact that it's x86 specific. What about crashed state? I have implemented this state after the guest entered disabled wait (by convention used by all s390 OSes for crashes) See commit 08eb8c85e3967b97865d46acadf26dc908fbb094 Author: Christian Borntraeger Date: Fri Apr 26 11:24:47 2013 +0800 Wire up disabled wait a panicked event on s390 Should we remove that as well? From s390 point of view, after allowing the crashed->running transition the feature would probably work as expected. Christian