On Wed, 15 Dec 2010 18:45:09 +0100
Markus Armbruster <armbru@xxxxxxxxxx> wrote:
> Luiz Capitulino <lcapitulino@xxxxxxxxxx> writes:
>
> > On Wed, 15 Dec 2010 19:18:32 +0200
> > Avi Kivity <avi@xxxxxxxxxx> wrote:
> >
> >> On 12/15/2010 07:09 PM, Luiz Capitulino wrote:
> >> > On Wed, 15 Dec 2010 17:49:27 +0800
> >> > Lai Jiangshan<laijs@xxxxxxxxxxxxxx> wrote:
> >> >
> >> > >
> >> > > Convert do_inject_nmi() to QObject, QError, we need to use it(via libvirt).
> >> > >
> >> > > changed from v1
> >> > > Add document.
> >> > > Add error handling when the cpu index is invalid.
> >> > >
> >> > > changed from v2
> >> > > use QERR_INVALID_PARAMETER_VALUE as Markus suggest.
> >> > >
> >> > > Signed-off-by: Lai Jiangshan<laijs@xxxxxxxxxxxxxx>
> >> > > ---
> >> > > diff --git a/hmp-commands.hx b/hmp-commands.hx
> >> > > index 23024ba..f86d9fe 100644
> >> > > --- a/hmp-commands.hx
> >> > > +++ b/hmp-commands.hx
> >> > > @@ -724,7 +724,8 @@ ETEXI
> >> > > .args_type = "cpu_index:i",
> >> > > .params = "cpu",
> >> > > .help = "inject an NMI on the given CPU",
> >> > > - .mhandler.cmd = do_inject_nmi,
> >> > > + .user_print = monitor_user_noop,
> >> > > + .mhandler.cmd_new = do_inject_nmi,
> >> > > },
> >> > > #endif
> >> > > STEXI
> >> > > diff --git a/monitor.c b/monitor.c
> >> > > index ec31eac..3e33a96 100644
> >> > > --- a/monitor.c
> >> > > +++ b/monitor.c
> >> > > @@ -2119,7 +2119,7 @@ static void do_wav_capture(Monitor *mon, const QDict *qdict)
> >> > > #endif
> >> > >
> >> > > #if defined(TARGET_I386)
> >> > > -static void do_inject_nmi(Monitor *mon, const QDict *qdict)
> >> > > +static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
> >> > > {
> >> > > CPUState *env;
> >> > > int cpu_index = qdict_get_int(qdict, "cpu_index");
> >> > > @@ -2127,8 +2127,12 @@ static void do_inject_nmi(Monitor *mon, const QDict *qdict)
> >> > > for (env = first_cpu; env != NULL; env = env->next_cpu)
> >> > > if (env->cpu_index == cpu_index) {
> >> > > cpu_interrupt(env, CPU_INTERRUPT_NMI);
> >> > > - break;
> >> > > + return 0;
> >> > > }
> >> > > +
> >> > > + qerror_report(QERR_INVALID_PARAMETER_VALUE, "cpu_index",
> >> > > + "a CPU number");
> >> > > + return -1;
> >> > > }
> >> > > #endif
> >> > >
> >> > > diff --git a/qmp-commands.hx b/qmp-commands.hx
> >> > > index e5f157f..fcb6bf2 100644
> >> > > --- a/qmp-commands.hx
> >> > > +++ b/qmp-commands.hx
> >> > > @@ -429,6 +429,33 @@ Example:
> >> > >
> >> > > EQMP
> >> > >
> >> > > +#if defined(TARGET_I386)
> >> > > + {
> >> > > + .name = "inject_nmi",
> >> > > + .args_type = "cpu_index:i",
> >> > > + .params = "cpu",
> >> > > + .help = "inject an NMI on the given CPU",
> >> > > + .user_print = monitor_user_noop,
> >> > > + .mhandler.cmd_new = do_inject_nmi,
> >> > > + },
> >> > > +#endif
> >> > > +SQMP
> >> > > +inject_nmi
> >> > > +----------
> >> > > +
> >> > > +Inject an NMI on the given CPU (x86 only).
> >> > > +
> >> > > +Arguments:
> >> > > +
> >> > > +- "cpu_index": the index of the CPU to be injected NMI (json-int)
> >> >
> >> > Please, use cpu-index, that's what we're using for the human-monitor-command.
> >> >
> >> > Avi, Anthony, can you please ACK this new command?
> >> >
> >>
> >> I'd like to see cpu-index made optional; if not present, nmi all cpus
> >> (that's what the nmi button on many machines does, or at least I think
> >> that's what it does).
> >
> > Looks like a GUI feature to me,
>
> Really? Can't see how you can build "NMI to all CPUs" from "NMI this
> CPU". Or am I misunderstanding you?
I guess so. Avi referred to 'nmi button on many machines', I assumed he
meant a virtual machine GUI, am I wrong?
> > _might_ turn out to be an undesirable
> > side effect to client writers.
>
> They seem to be coping fine with optional arguments elsewhere.
Which we might want to review.
> > I guess I prefer a to-all-cpus argument.
>
> How would that look like? "cpu-index": "all"?
Like this:
{ "execute": "inject-nmi", "arguments": { "to-all-cpus": true } }
But this looks like an optimization to me, because it's also easy to do:
for cpu in query-cpus; do
inject-nmi cpu
Unless we want to do this in an "atomic" way, due to side effects I'm
not aware about.
> I find "optional json-int" a simpler schema than "either a json-int or
> the json-string "all".
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
