From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36299 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q7jed-0000VB-2m for qemu-devel@nongnu.org; Thu, 07 Apr 2011 03:29:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q7jeT-0004U8-Os for qemu-devel@nongnu.org; Thu, 07 Apr 2011 03:29:14 -0400 Received: from david.siemens.de ([192.35.17.14]:30929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q7jeT-0004Tr-GB for qemu-devel@nongnu.org; Thu, 07 Apr 2011 03:29:13 -0400 Message-ID: <4D9D67BC.3010805@siemens.com> Date: Thu, 07 Apr 2011 09:29:00 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command References: <4D74A8C9.2020408@cn.fujitsu.com> <4D74A974.6090509@cn.fujitsu.com> <20110404105949.GA30324@redhat.com> <4D99BF99.1040305@redhat.com> <4D99C22C.4070401@codemonkey.ws> <20110406144723.45333682@doriath> <4D9CAAF9.7000509@codemonkey.ws> <20110406150818.56707b9b@doriath> <4D9CAE4B.7080305@siemens.com> <20110406160020.373cb5a2@doriath> <4D9CC044.2000705@codemonkey.ws> In-Reply-To: <4D9CC044.2000705@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Lai Jiangshan , Jiangshan , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Markus Armbruster , Luiz Capitulino , Avi Kivity On 2011-04-06 21:34, Anthony Liguori wrote: > On 04/06/2011 02:27 PM, Peter Maydell wrote: >>> Right, but honestly speaking, I don't know how this works for other arches. >>> >>> So, the best thing to do is to have a general design that can be used >>> by any architecture. Of course that we can also add a new command later >>> if needed. >> Well, I'm not sure "send a random interrupt to the core" makes >> much sense for ARM... So what are we actually trying to model here? >> Some sort of way to do "press a front panel switch" via remote monitor >> protocol? I guess you could have an API for boards to register any >> switches they had... > > http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm > > If an OS is totally hosed (spinning with interrupts disabled), and NMI > can be used to generate a crash dump. > > It's a debug feature and modelling it exactly the way we are probably > makes sense for other architectures too. The real semantics are > basically force guest crash dump. Right, it's a debugging tool. And that does not necessarily means it has to match real hardware. I could imagine scenarios where it could be helpful to direct the NMI to a specific core, e.g. in AMP setups if only one OS ran wild. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux