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