From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJQZQ-0006qz-NT for qemu-devel@nongnu.org; Mon, 09 May 2011 09:32:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJQZP-0003Yt-Al for qemu-devel@nongnu.org; Mon, 09 May 2011 09:32:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJQZP-0003Yp-38 for qemu-devel@nongnu.org; Mon, 09 May 2011 09:32:19 -0400 Date: Mon, 9 May 2011 10:32:10 -0300 From: Luiz Capitulino Message-ID: <20110509103210.337ea7af@doriath> In-Reply-To: References: <1304116821-18201-1-git-send-email-lcapitulino@redhat.com> <20110502125746.5ef8bc78@doriath> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Blue Swirl Cc: qemu-devel@nongnu.org, Markus Armbruster , laijs@cn.fujitsu.com On Fri, 6 May 2011 18:36:31 +0300 Blue Swirl wrote: > On Fri, May 6, 2011 at 12:08 PM, Markus Armbruster wr= ote: > > Blue Swirl writes: > > > >> 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 t= o use > >>>> > the QMP implementation, which means that it now has a DIFFERENT be= havior. > >>>> > 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', 'injec= t' > >>>> 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 signa= ls. > > > > Yes, we could use nicer infrastructure for modeling IRQs. =A0No, we > > shouldn't reject Lai's work because it doesn't get us there. =A0Perfect= is > > the enemy of good. > > > > Pick one: > > > > 1. We take inject-nmi now. =A0Should we get a more general inject comma= nd > > like the one you envisage later, we can deprecate inject-nmi, and remove > > it after a suitable grace time. =A0Big deal. =A0We get the special prob= lem > > solved now, without really compromising future solutions for the general > > problem. > > > > 2. We reject inject-nmi now. =A0The itch Lai tries to scratch remains > > unscratched until we get a more general inject command. > > > > 2a. Rejection "motivates" Lai to solve the general problem[*]. =A0Or ma= ybe > > it motivates somebody else. =A0We get the general problem solved sooner. > > And maybe I get a pony for my birthday, too. > > > > 2b. The general problem remains unsolved along with the special problem. > > We get nothing. >=20 > 2c. Don't add full generic IRQ registration and aliases just now but > handle 'inject' with only 'nmi'. That way we introduce no legacy > baggage to the syntax. Can you give an example on how this is supposed to look like?