On Fri, 6 May 2011 18:36:31 +0300 Blue Swirl <blauwir...@gmail.com> wrote:
> On Fri, May 6, 2011 at 12:08 PM, Markus Armbruster <arm...@redhat.com> wrote: > > Blue Swirl <blauwir...@gmail.com> writes: > > > >> On Mon, May 2, 2011 at 6:57 PM, Luiz Capitulino <lcapitul...@redhat.com> > >> wrote: > >>> On Sat, 30 Apr 2011 09:33:15 +0300 > >>> Blue Swirl <blauwir...@gmail.com> wrote: > >>> > >>>> On Sat, Apr 30, 2011 at 1:40 AM, Luiz Capitulino > >>>> <lcapitul...@redhat.com> 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. > > > > Yes, we could use nicer infrastructure for modeling IRQs. No, we > > shouldn't reject Lai's work because it doesn't get us there. Perfect is > > the enemy of good. > > > > Pick one: > > > > 1. We take inject-nmi now. Should we get a more general inject command > > like the one you envisage later, we can deprecate inject-nmi, and remove > > it after a suitable grace time. Big deal. We get the special problem > > solved now, without really compromising future solutions for the general > > problem. > > > > 2. We reject inject-nmi now. The itch Lai tries to scratch remains > > unscratched until we get a more general inject command. > > > > 2a. Rejection "motivates" Lai to solve the general problem[*]. Or maybe > > it motivates somebody else. We 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. > > 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?