qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3]: QMP: Introduce inject-nmi command


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH 0/3]: QMP: Introduce inject-nmi command
Date: Fri, 6 May 2011 11:55:35 -0300

On Fri, 06 May 2011 11:08:08 +0200
Markus Armbruster <address@hidden> wrote:

> Blue Swirl <address@hidden> writes:
> 
> > On Mon, May 2, 2011 at 6:57 PM, Luiz Capitulino <address@hidden> wrote:
> >> On Sat, 30 Apr 2011 09:33:15 +0300
> >> Blue Swirl <address@hidden> wrote:
> >>
> >>> On Sat, Apr 30, 2011 at 1:40 AM, Luiz Capitulino <address@hidden> 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 /address@hidden:l1int
> > which would be a shorthand for
> > raise /address@hidden:l1int
> > lower /address@hidden: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.

We don't even need to drop it, we just call the new one 'inject' or something
like it and we're set (internally we could re-write 'inject-nmi' to use
'inject' in the future).

> 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.
> 
> 
> [*] He's been trying to give us NMI injection via QMP for five months,
> so what's a few months more to him.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]