From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHhkX-00042b-Ku for qemu-devel@nongnu.org; Wed, 04 May 2011 15:28:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QHhkW-0007Tt-NI for qemu-devel@nongnu.org; Wed, 04 May 2011 15:28:41 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:60803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHhkW-0007To-H1 for qemu-devel@nongnu.org; Wed, 04 May 2011 15:28:40 -0400 Received: by qwj8 with SMTP id 8so1120307qwj.4 for ; Wed, 04 May 2011 12:28:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110502125746.5ef8bc78@doriath> References: <1304116821-18201-1-git-send-email-lcapitulino@redhat.com> <20110502125746.5ef8bc78@doriath> From: Blue Swirl Date: Wed, 4 May 2011 22:28:20 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 0/3]: QMP: Introduce inject-nmi command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: laijs@cn.fujitsu.com, qemu-devel@nongnu.org, armbru@redhat.com On Mon, May 2, 2011 at 6:57 PM, Luiz Capitulino wrote: > On Sat, 30 Apr 2011 09:33:15 +0300 > Blue Swirl wrote: > >> On Sat, Apr 30, 2011 at 1:40 AM, Luiz Capitulino wrote: >> > This series introduces the inject-nmi command for QMP, which sends an >> > NMI to _all_ guest's CPUs. >> > >> > Also note that this series changes the human monitor nmi command to use >> > the QMP implementation, which means that it now has a DIFFERENT behavior. >> > Please, check patch 3/3 for details. >> >> As discussed earlier, please change the QMP version for future >> expandability so that instead of single command 'inject-nmi', 'inject' >> takes parameter 'nmi'. HMP command 'nmi' can remain for now, but >> 'inject' should be added. > > I'm not sure I agree with this, because we risky overloading 'inject' the > same way we did with the 'change' command. > > What's 'inject' supposed to do in the future? Inject other IRQs, for example inject nmi could become an alias to something like inject /apic@fee00000:l1int which would be a shorthand for raise /apic@fee00000:l1int lower /apic@fee00000:l1int I think we only need a registration framework for IRQs and other signals.