From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command Date: Thu, 07 Apr 2011 09:29:00 +0200 Message-ID: <4D9D67BC.3010805@siemens.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Luiz Capitulino , Lai Jiangshan , Jiangshan , "kvm@vger.kernel.org" , Markus Armbruster , "qemu-devel@nongnu.org" , Avi Kivity To: Anthony Liguori Return-path: Received: from david.siemens.de ([192.35.17.14]:16048 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751578Ab1DGH3R (ORCPT ); Thu, 7 Apr 2011 03:29:17 -0400 In-Reply-To: <4D9CC044.2000705@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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