From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPxf1-0007qJ-54 for qemu-devel@nongnu.org; Fri, 27 May 2011 10:05:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QPxez-0000dh-LU for qemu-devel@nongnu.org; Fri, 27 May 2011 10:05:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPxez-0000d6-Cd for qemu-devel@nongnu.org; Fri, 27 May 2011 10:05:05 -0400 Date: Fri, 27 May 2011 11:04:55 -0300 From: Luiz Capitulino Message-ID: <20110527110455.1b42df32@doriath> In-Reply-To: References: <1304116821-18201-1-git-send-email-lcapitulino@redhat.com> <20110502125746.5ef8bc78@doriath> <20110509103210.337ea7af@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: laijs@cn.fujitsu.com, Markus Armbruster , qemu-devel@nongnu.org On Thu, 26 May 2011 22:23:10 +0300 Blue Swirl wrote: > On Thu, May 26, 2011 at 8:25 PM, Markus Armbruster wr= ote: > > Luiz Capitulino writes: > > > >> On Fri, 6 May 2011 18:36:31 +0300 > >> Blue Swirl wrote: > >> > >>> On Fri, May 6, 2011 at 12:08 PM, Markus Armbruster wrote: > >>> > 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 s= ends an > >>> >>>> > NMI to _all_ guest's CPUs. > >>> >>>> > > >>> >>>> > Also note that this series changes the human monitor nmi comma= nd to use > >>> >>>> > the QMP implementation, which means that it now has a DIFFEREN= T 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', 'i= nject' > >>> >>>> 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 'inj= ect' 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 s= ignals. > >>> > > >>> > Yes, we could use nicer infrastructure for modeling IRQs. =A0No, we > >>> > shouldn't reject Lai's work because it doesn't get us there. =A0Per= fect is > >>> > the enemy of good. > >>> > > >>> > Pick one: > >>> > > >>> > 1. We take inject-nmi now. =A0Should we get a more general inject c= ommand > >>> > like the one you envisage later, we can deprecate inject-nmi, and r= emove > >>> > it after a suitable grace time. =A0Big deal. =A0We get the special = problem > >>> > solved now, without really compromising future solutions for the ge= neral > >>> > problem. > >>> > > >>> > 2. We reject inject-nmi now. =A0The itch Lai tries to scratch remai= ns > >>> > unscratched until we get a more general inject command. > >>> > > >>> > 2a. Rejection "motivates" Lai to solve the general problem[*]. =A0O= r maybe > >>> > it motivates somebody else. =A0We get the general problem solved so= oner. > >>> > And maybe I get a pony for my birthday, too. > >>> > > >>> > 2b. The general problem remains unsolved along with the special pro= blem. > >>> > 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. > >> > >> Can you give an example on how this is supposed to look like? > > > > No reply. =A0When you demand a redesign to generalize a simple feature = to > > something only you envisage, please explain what exactly you want. > > Documentation to stick into qmp-commands.hx would be a start. =A0Here's > > the baseline from Luiz, for your editing convenience. > > > > > > inject-nmi > > ---------- > > > > Inject an NMI on guest's CPUs. > > > > Arguments: None. > > > > Example: > > > > -> { "execute": "inject-nmi" } > > <- { "return": {} } > > > > Note: inject-nmi is only supported for x86 guest currently, it will > > =A0 =A0 =A0returns "Unsupported" error for non-x86 guest. >=20 > I think I explained it many times, but let's try again. >=20 > inject > ---------- >=20 > Inject a signal on guest machine. >=20 > Arguments: signal name. >=20 > Example: >=20 > -> { "execute": "inject", > "arguments": { "signal": "nmi" } } > <- { "return": {} } >=20 > -> { "execute": "inject", > "arguments": { "signal": "/apic@fee00000:l1int" } } > <- { "return": {} } Shouldn't this be broken into device and signal (or pin) arguments? > Note: the set of signals supported depends on the CPU architecture and > board type, unknown or unsupported names will > return "Unsupported" error. Unsuported error !=3D bad usage error.