From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QIN5J-0004mq-As for qemu-devel@nongnu.org; Fri, 06 May 2011 11:36:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QIN5I-0001nd-17 for qemu-devel@nongnu.org; Fri, 06 May 2011 11:36:53 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:59609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QIN5H-0001nU-VC for qemu-devel@nongnu.org; Fri, 06 May 2011 11:36:51 -0400 Received: by qyk36 with SMTP id 36so4907449qyk.4 for ; Fri, 06 May 2011 08:36:51 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1304116821-18201-1-git-send-email-lcapitulino@redhat.com> <20110502125746.5ef8bc78@doriath> From: Blue Swirl Date: Fri, 6 May 2011 18:36:31 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Markus Armbruster Cc: qemu-devel@nongnu.org, laijs@cn.fujitsu.com, Luiz Capitulino On Fri, May 6, 2011 at 12:08 PM, Markus Armbruster wrot= e: > 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 a= n >>>> > 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 beha= vior. >>>> > 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' t= he >>> 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= . > > Yes, we could use nicer infrastructure for modeling IRQs. =C2=A0No, we > shouldn't reject Lai's work because it doesn't get us there. =C2=A0Perfec= t is > the enemy of good. > > Pick one: > > 1. We take inject-nmi now. =C2=A0Should we get a more general inject comm= and > like the one you envisage later, we can deprecate inject-nmi, and remove > it after a suitable grace time. =C2=A0Big deal. =C2=A0We get the special = problem > solved now, without really compromising future solutions for the general > problem. > > 2. We reject inject-nmi now. =C2=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[*]. =C2=A0Or m= aybe > it motivates somebody else. =C2=A0We get the general problem solved soone= r. > And maybe I get a pony for my birthday, too. > > 2b. The general problem remains unsolved along with the special problem. > We get nothing. 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.