[Qemu-devel] [PATCH 0/2 V7] add inject-nmi qmp command

[Qemu-devel] [PATCH 0/2 V7] add inject-nmi qmp command

[Lai Jiangshan]

From: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Mon, 7 Mar 2011 17:08:46 +0800
Subject: [PATCH 0/2 V7] qemu,qmp: add inject-nmi qmp command

The new qmp command "inject-nmi" is different from the hmp
monitor command "nmi". The first one injects an NMI on all CPUs,
and the second one injects an NMI to the specified CPU.

The first one(qmp command) simulates the Real hardware NMI button,
but I don't want to change the existed hmp monitor command "nmi",
so I didn't change it except the handler name. Maybe we will
add a qmp command "inject-nmi-cpu" in future, but not now.
(it seems it is only requested by me currently)

The qmp command "inject-nmi" is only supported for x86 guest
currently, it will returns "Unsupported" error for non-x86 guest.
This error and this behavior are described in the comments.

Lai Jiangshan (2):
  qemu,qmp: QError: New QERR_UNSUPPORTED
  qemu,qmp: add inject-nmi qmp command

 hmp-commands.hx |    2 +-
 monitor.c       |   18 +++++++++++++++++-
 qerror.h        |    3 +++
 qmp-commands.hx |   29 +++++++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 2 deletions(-)

-- 
1.7.4

[Qemu-devel] [PATCH 1/2] qemu,qmp: QError: New QERR_UNSUPPORTED

[Lai Jiangshan]

From: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Mon, 7 Mar 2011 17:05:04 +0800
Subject: [PATCH 1/2] qemu,qmp: QError: New QERR_UNSUPPORTED

New QERR_UNSUPPORTED for unsupported commands or requests.

---
 qerror.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/qerror.h b/qerror.h
index f732d45..43cc87b 100644
--- a/qerror.h
+++ b/qerror.h
@@ -165,6 +165,9 @@ QError *qobject_to_qerror(const QObject *obj);
 #define QERR_UNDEFINED_ERROR \
     "{ 'class': 'UndefinedError', 'data': {} }"
 
+#define QERR_UNSUPPORTED \
+    "{ 'class': 'Unsupported', 'data': {} }"
+
 #define QERR_UNKNOWN_BLOCK_FORMAT_FEATURE \
     "{ 'class': 'UnknownBlockFormatFeature', 'data': { 'device': %s, 'format': %s, 'feature': %s } }"
 
-- 
1.7.4

[Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Lai Jiangshan]

From: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Mon, 7 Mar 2011 17:05:15 +0800
Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command

inject-nmi command injects an NMI on all CPUs of guest.
It is only supported for x86 guest currently, it will
returns "Unsupported" error for non-x86 guest.

---
 hmp-commands.hx |    2 +-
 monitor.c       |   18 +++++++++++++++++-
 qmp-commands.hx |   29 +++++++++++++++++++++++++++++
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 372bef4..8aea56c 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -743,7 +743,7 @@ ETEXI
         .args_type  = "cpu_index:i",
         .params     = "cpu",
         .help       = "inject an NMI on the given CPU",
-        .mhandler.cmd = do_inject_nmi,
+        .mhandler.cmd = do_inject_nmi_cpu,
     },
 #endif
 STEXI
diff --git a/monitor.c b/monitor.c
index 22ae3bb..aebcc0c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2555,7 +2555,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 void do_inject_nmi_cpu(Monitor *mon, const QDict *qdict)
 {
     CPUState *env;
     int cpu_index = qdict_get_int(qdict, "cpu_index");
@@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict *qdict)
             break;
         }
 }
+
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    CPUState *env;
+
+    for (env = first_cpu; env != NULL; env = env->next_cpu)
+        cpu_interrupt(env, CPU_INTERRUPT_NMI);
+
+    return 0;
+}
+#else
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    qerror_report(QERR_UNSUPPORTED);
+    return -1;
+}
 #endif
 
 static void do_info_status_print(Monitor *mon, const QObject *data)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index df40a3d..51f479e 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -430,6 +430,35 @@ Example:
 EQMP
 
     {
+        .name       = "inject-nmi",
+        .args_type  = "",
+        .params     = "",
+        .help       = "Inject an NMI on guest.\n"
+                      "Returns \"Unsupported\" error when the guest does"
+                      "not support NMI injection",
+        .user_print = monitor_user_noop,
+        .mhandler.cmd_new = do_inject_nmi,
+    },
+
+SQMP
+inject-nmi
+----------
+
+Inject an NMI on guest.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "inject-nmi" }
+<- { "return": {} }
+
+Note: inject-nmi is only supported for x86 guest currently, it will
+      returns "Unsupported" error for non-x86 guest.
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
-- 
1.7.4

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Daniel P. Berrange]

On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan <laijs@cn.fujitsu.com>
> Date: Mon, 7 Mar 2011 17:05:15 +0800
> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
> 
> inject-nmi command injects an NMI on all CPUs of guest.
> It is only supported for x86 guest currently, it will
> returns "Unsupported" error for non-x86 guest.
> 
> ---
>  hmp-commands.hx |    2 +-
>  monitor.c       |   18 +++++++++++++++++-
>  qmp-commands.hx |   29 +++++++++++++++++++++++++++++
>  3 files changed, 47 insertions(+), 2 deletions(-)

Does anyone have any feedback on this addition, or are all new
QMP patch proposals blocked pending Anthony's QAPI work ?

We'd like to support it in libvirt and thus want it to be
available in QMP, as well as HMP.

> @@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict *qdict)
>              break;
>          }
>  }
> +
> +static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +    CPUState *env;
> +
> +    for (env = first_cpu; env != NULL; env = env->next_cpu)
> +        cpu_interrupt(env, CPU_INTERRUPT_NMI);
> +
> +    return 0;
> +}
> +#else
> +static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +    qerror_report(QERR_UNSUPPORTED);
> +    return -1;
> +}
>  #endif
>  

Interesting that with HMP you need to specify a single CPU index, but
with QMP it is injecting to all CPUs at once. Is there any compelling
reason why we'd ever need the ability to only inject to a single CPU
from an app developer POV ?

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Markus Armbruster]

[Note cc: Anthony]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
>> From: Lai Jiangshan <laijs@cn.fujitsu.com>
>> Date: Mon, 7 Mar 2011 17:05:15 +0800
>> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
>> 
>> inject-nmi command injects an NMI on all CPUs of guest.
>> It is only supported for x86 guest currently, it will
>> returns "Unsupported" error for non-x86 guest.
>> 
>> ---
>>  hmp-commands.hx |    2 +-
>>  monitor.c       |   18 +++++++++++++++++-
>>  qmp-commands.hx |   29 +++++++++++++++++++++++++++++
>>  3 files changed, 47 insertions(+), 2 deletions(-)
>
> Does anyone have any feedback on this addition, or are all new
> QMP patch proposals blocked pending Anthony's QAPI work ?

That would be bad.  Anthony, what's holding this back?

> We'd like to support it in libvirt and thus want it to be
> available in QMP, as well as HMP.
>
>> @@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict *qdict)
>>              break;
>>          }
>>  }
>> +
>> +static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
>> +{
>> +    CPUState *env;
>> +
>> +    for (env = first_cpu; env != NULL; env = env->next_cpu)
>> +        cpu_interrupt(env, CPU_INTERRUPT_NMI);
>> +
>> +    return 0;
>> +}
>> +#else
>> +static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
>> +{
>> +    qerror_report(QERR_UNSUPPORTED);
>> +    return -1;
>> +}
>>  #endif
>>  
>
> Interesting that with HMP you need to specify a single CPU index, but
> with QMP it is injecting to all CPUs at once. Is there any compelling
> reason why we'd ever need the ability to only inject to a single CPU
> from an app developer POV ?

Quoting my own executive summary on this issue:

* Real hardware's NMI button injects all CPUs.  This is the primary use
  case.

* Lai said injecting a single CPU can be useful for debugging.  Was
  deemed acceptable as secondary use case.

  Lai also pointed out that the human monitor's nmi command injects a
  single CPU.  That was dismissed as irrelevant for QMP.

* No other use cases have been presented.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Luiz Capitulino]

On Mon, 04 Apr 2011 14:19:58 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> [Note cc: Anthony]
> 
> "Daniel P. Berrange" <berrange@redhat.com> writes:
> 
> > On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
> >> From: Lai Jiangshan <laijs@cn.fujitsu.com>
> >> Date: Mon, 7 Mar 2011 17:05:15 +0800
> >> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
> >> 
> >> inject-nmi command injects an NMI on all CPUs of guest.
> >> It is only supported for x86 guest currently, it will
> >> returns "Unsupported" error for non-x86 guest.
> >> 
> >> ---
> >>  hmp-commands.hx |    2 +-
> >>  monitor.c       |   18 +++++++++++++++++-
> >>  qmp-commands.hx |   29 +++++++++++++++++++++++++++++
> >>  3 files changed, 47 insertions(+), 2 deletions(-)
> >
> > Does anyone have any feedback on this addition, or are all new
> > QMP patch proposals blocked pending Anthony's QAPI work ?

No, we agreed on merging stuff against current QMP.

> That would be bad.  Anthony, what's holding this back?

I remember Anthony asked for errors descriptions.

> 
> > We'd like to support it in libvirt and thus want it to be
> > available in QMP, as well as HMP.
> >
> >> @@ -2566,6 +2566,22 @@ static void do_inject_nmi(Monitor *mon, const QDict *qdict)
> >>              break;
> >>          }
> >>  }
> >> +
> >> +static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
> >> +{
> >> +    CPUState *env;
> >> +
> >> +    for (env = first_cpu; env != NULL; env = env->next_cpu)
> >> +        cpu_interrupt(env, CPU_INTERRUPT_NMI);
> >> +
> >> +    return 0;
> >> +}
> >> +#else
> >> +static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
> >> +{
> >> +    qerror_report(QERR_UNSUPPORTED);
> >> +    return -1;
> >> +}
> >>  #endif
> >>  
> >
> > Interesting that with HMP you need to specify a single CPU index, but
> > with QMP it is injecting to all CPUs at once. Is there any compelling
> > reason why we'd ever need the ability to only inject to a single CPU
> > from an app developer POV ?
> 
> Quoting my own executive summary on this issue:
> 
> * Real hardware's NMI button injects all CPUs.  This is the primary use
>   case.
> 
> * Lai said injecting a single CPU can be useful for debugging.  Was
>   deemed acceptable as secondary use case.
> 
>   Lai also pointed out that the human monitor's nmi command injects a
>   single CPU.  That was dismissed as irrelevant for QMP.
> 
> * No other use cases have been presented.
> 

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/04/2011 07:19 AM, Markus Armbruster wrote:
> [Note cc: Anthony]
>
> "Daniel P. Berrange"<berrange@redhat.com>  writes:
>
>> On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
>>> From: Lai Jiangshan<laijs@cn.fujitsu.com>
>>> Date: Mon, 7 Mar 2011 17:05:15 +0800
>>> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
>>>
>>> inject-nmi command injects an NMI on all CPUs of guest.
>>> It is only supported for x86 guest currently, it will
>>> returns "Unsupported" error for non-x86 guest.
>>>
>>> ---
>>>   hmp-commands.hx |    2 +-
>>>   monitor.c       |   18 +++++++++++++++++-
>>>   qmp-commands.hx |   29 +++++++++++++++++++++++++++++
>>>   3 files changed, 47 insertions(+), 2 deletions(-)
>> Does anyone have any feedback on this addition, or are all new
>> QMP patch proposals blocked pending Anthony's QAPI work ?
> That would be bad.  Anthony, what's holding this back?

It doesn't pass checkpath.pl.

But I'd also expect this to come through Luiz's QMP tree.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Luiz Capitulino]

On Mon, 04 Apr 2011 08:09:29 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 04/04/2011 07:19 AM, Markus Armbruster wrote:
> > [Note cc: Anthony]
> >
> > "Daniel P. Berrange"<berrange@redhat.com>  writes:
> >
> >> On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
> >>> From: Lai Jiangshan<laijs@cn.fujitsu.com>
> >>> Date: Mon, 7 Mar 2011 17:05:15 +0800
> >>> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
> >>>
> >>> inject-nmi command injects an NMI on all CPUs of guest.
> >>> It is only supported for x86 guest currently, it will
> >>> returns "Unsupported" error for non-x86 guest.
> >>>
> >>> ---
> >>>   hmp-commands.hx |    2 +-
> >>>   monitor.c       |   18 +++++++++++++++++-
> >>>   qmp-commands.hx |   29 +++++++++++++++++++++++++++++
> >>>   3 files changed, 47 insertions(+), 2 deletions(-)
> >> Does anyone have any feedback on this addition, or are all new
> >> QMP patch proposals blocked pending Anthony's QAPI work ?
> > That would be bad.  Anthony, what's holding this back?
> 
> It doesn't pass checkpath.pl.
> 
> But I'd also expect this to come through Luiz's QMP tree.

I had this ready in my tree some time ago, but you commented on that
version asking for errors descriptions and other things, so I didn't
push it.

But we have to set expectations here. My tree will eventually die,
specially wrt new interfaces where I expect you to jump in ASAP. First
because you have to be sure a new interface "conforms" to QAPI, and
second (and more importantly) because it's time to pass this on to
someone else (preferably you).

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Lai Jiangshan]

On 04/04/2011 09:09 PM, Anthony Liguori wrote:
> On 04/04/2011 07:19 AM, Markus Armbruster wrote:
>> [Note cc: Anthony]
>>
>> "Daniel P. Berrange"<berrange@redhat.com>  writes:
>>
>>> On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
>>>> From: Lai Jiangshan<laijs@cn.fujitsu.com>
>>>> Date: Mon, 7 Mar 2011 17:05:15 +0800
>>>> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
>>>>
>>>> inject-nmi command injects an NMI on all CPUs of guest.
>>>> It is only supported for x86 guest currently, it will
>>>> returns "Unsupported" error for non-x86 guest.
>>>>
>>>> ---
>>>>   hmp-commands.hx |    2 +-
>>>>   monitor.c       |   18 +++++++++++++++++-
>>>>   qmp-commands.hx |   29 +++++++++++++++++++++++++++++
>>>>   3 files changed, 47 insertions(+), 2 deletions(-)
>>> Does anyone have any feedback on this addition, or are all new
>>> QMP patch proposals blocked pending Anthony's QAPI work ?
>> That would be bad.  Anthony, what's holding this back?
> 
> It doesn't pass checkpath.pl.
> 
> But I'd also expect this to come through Luiz's QMP tree.
> 
> Regards,
> 
> Anthony Liguori
> 

Hi, Anthony,

I cannot find checkpath.pl in the source tree.
And how/where to write errors descriptions? Is the following description
suitable?

##
# @inject-nmi:
#
# Inject an NMI on the guest.
#
# Returns: Nothing on success.
#          If the guest(non-x86) does not support NMI injection, Unsupported
#
# Since: 0.15.0
##
{ 'command': 'inject-nmi' }


Thanks,
Lai

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Lai Jiangshan]

On 04/20/2011 09:53 AM, Lai Jiangshan wrote:
> On 04/04/2011 09:09 PM, Anthony Liguori wrote:
>> On 04/04/2011 07:19 AM, Markus Armbruster wrote:
>>> [Note cc: Anthony]
>>>
>>> "Daniel P. Berrange"<berrange@redhat.com>  writes:
>>>
>>>> On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
>>>>> From: Lai Jiangshan<laijs@cn.fujitsu.com>
>>>>> Date: Mon, 7 Mar 2011 17:05:15 +0800
>>>>> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
>>>>>
>>>>> inject-nmi command injects an NMI on all CPUs of guest.
>>>>> It is only supported for x86 guest currently, it will
>>>>> returns "Unsupported" error for non-x86 guest.
>>>>>
>>>>> ---
>>>>>   hmp-commands.hx |    2 +-
>>>>>   monitor.c       |   18 +++++++++++++++++-
>>>>>   qmp-commands.hx |   29 +++++++++++++++++++++++++++++
>>>>>   3 files changed, 47 insertions(+), 2 deletions(-)
>>>> Does anyone have any feedback on this addition, or are all new
>>>> QMP patch proposals blocked pending Anthony's QAPI work ?
>>> That would be bad.  Anthony, what's holding this back?
>>
>> It doesn't pass checkpath.pl.
>>
>> But I'd also expect this to come through Luiz's QMP tree.
>>
>> Regards,
>>
>> Anthony Liguori
>>
> 
> Hi, Anthony,
> 
> I cannot find checkpath.pl in the source tree.

Sorry, I found it in the mainline tree.

> And how/where to write errors descriptions? Is the following description
> suitable?
> 
> ##
> # @inject-nmi:
> #
> # Inject an NMI on the guest.
> #
> # Returns: Nothing on success.
> #          If the guest(non-x86) does not support NMI injection, Unsupported
> #
> # Since: 0.15.0
> ##
> { 'command': 'inject-nmi' }
> 
> 
> Thanks,
> Lai
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Luiz Capitulino]

On Wed, 20 Apr 2011 09:53:56 +0800
Lai Jiangshan <laijs@cn.fujitsu.com> wrote:

> On 04/04/2011 09:09 PM, Anthony Liguori wrote:
> > On 04/04/2011 07:19 AM, Markus Armbruster wrote:
> >> [Note cc: Anthony]
> >>
> >> "Daniel P. Berrange"<berrange@redhat.com>  writes:
> >>
> >>> On Mon, Mar 07, 2011 at 05:46:28PM +0800, Lai Jiangshan wrote:
> >>>> From: Lai Jiangshan<laijs@cn.fujitsu.com>
> >>>> Date: Mon, 7 Mar 2011 17:05:15 +0800
> >>>> Subject: [PATCH 2/2] qemu,qmp: add inject-nmi qmp command
> >>>>
> >>>> inject-nmi command injects an NMI on all CPUs of guest.
> >>>> It is only supported for x86 guest currently, it will
> >>>> returns "Unsupported" error for non-x86 guest.
> >>>>
> >>>> ---
> >>>>   hmp-commands.hx |    2 +-
> >>>>   monitor.c       |   18 +++++++++++++++++-
> >>>>   qmp-commands.hx |   29 +++++++++++++++++++++++++++++
> >>>>   3 files changed, 47 insertions(+), 2 deletions(-)
> >>> Does anyone have any feedback on this addition, or are all new
> >>> QMP patch proposals blocked pending Anthony's QAPI work ?
> >> That would be bad.  Anthony, what's holding this back?
> > 
> > It doesn't pass checkpath.pl.
> > 
> > But I'd also expect this to come through Luiz's QMP tree.
> > 
> > Regards,
> > 
> > Anthony Liguori
> > 
> 
> Hi, Anthony,
> 
> I cannot find checkpath.pl in the source tree.

It's ./scripts/checkpatch.pl

> And how/where to write errors descriptions? Is the following description
> suitable?
> 
> ##
> # @inject-nmi:
> #
> # Inject an NMI on the guest.
> #
> # Returns: Nothing on success.
> #          If the guest(non-x86) does not support NMI injection, Unsupported
> #
> # Since: 0.15.0
> ##
> { 'command': 'inject-nmi' }
> 
> 
> Thanks,
> Lai
> 

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Avi Kivity]

On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
> Interesting that with HMP you need to specify a single CPU index, but
> with QMP it is injecting to all CPUs at once. Is there any compelling
> reason why we'd ever need the ability to only inject to a single CPU
> from an app developer POV ?

When a PC has an NMI button, it is (I presume) connected to all CPUs' 
LINT1 pin, which is often configured as an NMI input.  So the all-cpu 
variant corresponds to real hardware, while the single-cpu variant doesn't.

wrt the app developer POV, the only use I'm aware of is that you can 
configure Windows to dump core when the NMI button is pressed and thus 
debug driver problems.  It's likely more reliable when sent to all cpus.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/04/2011 07:54 AM, Avi Kivity wrote:
> On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
>> Interesting that with HMP you need to specify a single CPU index, but
>> with QMP it is injecting to all CPUs at once. Is there any compelling
>> reason why we'd ever need the ability to only inject to a single CPU
>> from an app developer POV ?
>
> When a PC has an NMI button, it is (I presume) connected to all CPUs' 
> LINT1 pin, which is often configured as an NMI input.  So the all-cpu 
> variant corresponds to real hardware, while the single-cpu variant 
> doesn't.
>
> wrt the app developer POV, the only use I'm aware of is that you can 
> configure Windows to dump core when the NMI button is pressed and thus 
> debug driver problems.  It's likely more reliable when sent to all cpus.

It either needs to be removed from HMP or added to QMP.  HMP shouldn't 
have more features than QMP (even if those features are non-sensible).

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Luiz Capitulino]

On Mon, 04 Apr 2011 08:05:48 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 04/04/2011 07:54 AM, Avi Kivity wrote:
> > On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
> >> Interesting that with HMP you need to specify a single CPU index, but
> >> with QMP it is injecting to all CPUs at once. Is there any compelling
> >> reason why we'd ever need the ability to only inject to a single CPU
> >> from an app developer POV ?
> >
> > When a PC has an NMI button, it is (I presume) connected to all CPUs' 
> > LINT1 pin, which is often configured as an NMI input.  So the all-cpu 
> > variant corresponds to real hardware, while the single-cpu variant 
> > doesn't.
> >
> > wrt the app developer POV, the only use I'm aware of is that you can 
> > configure Windows to dump core when the NMI button is pressed and thus 
> > debug driver problems.  It's likely more reliable when sent to all cpus.
> 
> It either needs to be removed from HMP or added to QMP.  HMP shouldn't 
> have more features than QMP (even if those features are non-sensible).

Is anyone against changing HMP behavior to send it to all CPUs?

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/06/2011 12:47 PM, Luiz Capitulino wrote:
> On Mon, 04 Apr 2011 08:05:48 -0500
> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>> On 04/04/2011 07:54 AM, Avi Kivity wrote:
>>> On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
>>>> Interesting that with HMP you need to specify a single CPU index, but
>>>> with QMP it is injecting to all CPUs at once. Is there any compelling
>>>> reason why we'd ever need the ability to only inject to a single CPU
>>>> from an app developer POV ?
>>> When a PC has an NMI button, it is (I presume) connected to all CPUs'
>>> LINT1 pin, which is often configured as an NMI input.  So the all-cpu
>>> variant corresponds to real hardware, while the single-cpu variant
>>> doesn't.
>>>
>>> wrt the app developer POV, the only use I'm aware of is that you can
>>> configure Windows to dump core when the NMI button is pressed and thus
>>> debug driver problems.  It's likely more reliable when sent to all cpus.
>> It either needs to be removed from HMP or added to QMP.  HMP shouldn't
>> have more features than QMP (even if those features are non-sensible).
> Is anyone against changing HMP behavior to send it to all CPUs?

Makes sense to me.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Luiz Capitulino]

On Wed, 06 Apr 2011 13:03:37 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 04/06/2011 12:47 PM, Luiz Capitulino wrote:
> > On Mon, 04 Apr 2011 08:05:48 -0500
> > Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >
> >> On 04/04/2011 07:54 AM, Avi Kivity wrote:
> >>> On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
> >>>> Interesting that with HMP you need to specify a single CPU index, but
> >>>> with QMP it is injecting to all CPUs at once. Is there any compelling
> >>>> reason why we'd ever need the ability to only inject to a single CPU
> >>>> from an app developer POV ?
> >>> When a PC has an NMI button, it is (I presume) connected to all CPUs'
> >>> LINT1 pin, which is often configured as an NMI input.  So the all-cpu
> >>> variant corresponds to real hardware, while the single-cpu variant
> >>> doesn't.
> >>>
> >>> wrt the app developer POV, the only use I'm aware of is that you can
> >>> configure Windows to dump core when the NMI button is pressed and thus
> >>> debug driver problems.  It's likely more reliable when sent to all cpus.
> >> It either needs to be removed from HMP or added to QMP.  HMP shouldn't
> >> have more features than QMP (even if those features are non-sensible).
> > Is anyone against changing HMP behavior to send it to all CPUs?
> 
> Makes sense to me.

So, Lai, in order to get this merged could you please do the following:

 1. Address checkpath.pl errors

 2. Change the HMP to use this implementation, which send the NMI
    to all CPUs

 3. Any other review comments I might be missing :)

> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Jan Kiszka]

On 2011-04-06 20:08, Luiz Capitulino wrote:
> On Wed, 06 Apr 2011 13:03:37 -0500
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
>> On 04/06/2011 12:47 PM, Luiz Capitulino wrote:
>>> On Mon, 04 Apr 2011 08:05:48 -0500
>>> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>>
>>>> On 04/04/2011 07:54 AM, Avi Kivity wrote:
>>>>> On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
>>>>>> Interesting that with HMP you need to specify a single CPU index, but
>>>>>> with QMP it is injecting to all CPUs at once. Is there any compelling
>>>>>> reason why we'd ever need the ability to only inject to a single CPU
>>>>>> from an app developer POV ?
>>>>> When a PC has an NMI button, it is (I presume) connected to all CPUs'
>>>>> LINT1 pin, which is often configured as an NMI input.  So the all-cpu
>>>>> variant corresponds to real hardware, while the single-cpu variant
>>>>> doesn't.
>>>>>
>>>>> wrt the app developer POV, the only use I'm aware of is that you can
>>>>> configure Windows to dump core when the NMI button is pressed and thus
>>>>> debug driver problems.  It's likely more reliable when sent to all cpus.
>>>> It either needs to be removed from HMP or added to QMP.  HMP shouldn't
>>>> have more features than QMP (even if those features are non-sensible).
>>> Is anyone against changing HMP behavior to send it to all CPUs?
>>
>> Makes sense to me.
> 
> So, Lai, in order to get this merged could you please do the following:
> 
>  1. Address checkpath.pl errors
> 
>  2. Change the HMP to use this implementation, which send the NMI
>     to all CPUs

HMP is currently x86-only, thus it's probably OK to model it after some
PC feature (though I don't know if there aren't NMI buttons with BP-only
wirings). But will the consolidate version be defined for all
architectures? We should avoid "exporting" x86-specific assumptions.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Luiz Capitulino]

On Wed, 06 Apr 2011 20:17:47 +0200
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 2011-04-06 20:08, Luiz Capitulino wrote:
> > On Wed, 06 Apr 2011 13:03:37 -0500
> > Anthony Liguori <anthony@codemonkey.ws> wrote:
> > 
> >> On 04/06/2011 12:47 PM, Luiz Capitulino wrote:
> >>> On Mon, 04 Apr 2011 08:05:48 -0500
> >>> Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >>>
> >>>> On 04/04/2011 07:54 AM, Avi Kivity wrote:
> >>>>> On 04/04/2011 01:59 PM, Daniel P. Berrange wrote:
> >>>>>> Interesting that with HMP you need to specify a single CPU index, but
> >>>>>> with QMP it is injecting to all CPUs at once. Is there any compelling
> >>>>>> reason why we'd ever need the ability to only inject to a single CPU
> >>>>>> from an app developer POV ?
> >>>>> When a PC has an NMI button, it is (I presume) connected to all CPUs'
> >>>>> LINT1 pin, which is often configured as an NMI input.  So the all-cpu
> >>>>> variant corresponds to real hardware, while the single-cpu variant
> >>>>> doesn't.
> >>>>>
> >>>>> wrt the app developer POV, the only use I'm aware of is that you can
> >>>>> configure Windows to dump core when the NMI button is pressed and thus
> >>>>> debug driver problems.  It's likely more reliable when sent to all cpus.
> >>>> It either needs to be removed from HMP or added to QMP.  HMP shouldn't
> >>>> have more features than QMP (even if those features are non-sensible).
> >>> Is anyone against changing HMP behavior to send it to all CPUs?
> >>
> >> Makes sense to me.
> > 
> > So, Lai, in order to get this merged could you please do the following:
> > 
> >  1. Address checkpath.pl errors
> > 
> >  2. Change the HMP to use this implementation, which send the NMI
> >     to all CPUs
> 
> HMP is currently x86-only, thus it's probably OK to model it after some
> PC feature (though I don't know if there aren't NMI buttons with BP-only
> wirings). But will the consolidate version be defined for all
> architectures? We should avoid "exporting" x86-specific assumptions.

Right, but honestly speaking, I don't know how this works for other arches.

So, the best thing to do is to have a general design that can be used
by any architecture. Of course that we can also add a new command later
if needed.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Peter Maydell]

On 6 April 2011 20:00, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Wed, 06 Apr 2011 20:17:47 +0200
> Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> HMP is currently x86-only, thus it's probably OK to model it after some
>> PC feature (though I don't know if there aren't NMI buttons with BP-only
>> wirings). But will the consolidate version be defined for all
>> architectures? We should avoid "exporting" x86-specific assumptions.
>
> Right, but honestly speaking, I don't know how this works for other arches.
>
> So, the best thing to do is to have a general design that can be used
> by any architecture. Of course that we can also add a new command later
> if needed.

Well, I'm not sure "send a random interrupt to the core" makes
much sense for ARM... So what are we actually trying to model here?
Some sort of way to do "press a front panel switch" via remote monitor
protocol? I guess you could have an API for boards to register any
switches they had...

-- PMM

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/06/2011 02:27 PM, Peter Maydell wrote:
>> Right, but honestly speaking, I don't know how this works for other arches.
>>
>> So, the best thing to do is to have a general design that can be used
>> by any architecture. Of course that we can also add a new command later
>> if needed.
> Well, I'm not sure "send a random interrupt to the core" makes
> much sense for ARM... So what are we actually trying to model here?
> Some sort of way to do "press a front panel switch" via remote monitor
> protocol? I guess you could have an API for boards to register any
> switches they had...

http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm

If an OS is totally hosed (spinning with interrupts disabled), and NMI 
can be used to generate a crash dump.

It's a debug feature and modelling it exactly the way we are probably 
makes sense for other architectures too.  The real semantics are 
basically force guest crash dump.

Regards,

Anthony Liguori

> -- PMM
>

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Jan Kiszka]

On 2011-04-06 21:34, Anthony Liguori wrote:
> On 04/06/2011 02:27 PM, Peter Maydell wrote:
>>> Right, but honestly speaking, I don't know how this works for other arches.
>>>
>>> So, the best thing to do is to have a general design that can be used
>>> by any architecture. Of course that we can also add a new command later
>>> if needed.
>> Well, I'm not sure "send a random interrupt to the core" makes
>> much sense for ARM... So what are we actually trying to model here?
>> Some sort of way to do "press a front panel switch" via remote monitor
>> protocol? I guess you could have an API for boards to register any
>> switches they had...
> 
> http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
> 
> If an OS is totally hosed (spinning with interrupts disabled), and NMI 
> can be used to generate a crash dump.
> 
> It's a debug feature and modelling it exactly the way we are probably 
> makes sense for other architectures too.  The real semantics are 
> basically force guest crash dump.

Right, it's a debugging tool. And that does not necessarily means it has
to match real hardware. I could imagine scenarios where it could be
helpful to direct the NMI to a specific core, e.g. in AMP setups if only
one OS ran wild.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Peter Maydell]

On 6 April 2011 20:34, Anthony Liguori <anthony@codemonkey.ws> wrote:
> http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
>
> If an OS is totally hosed (spinning with interrupts disabled), and NMI can
> be used to generate a crash dump.
>
> It's a debug feature and modelling it exactly the way we are probably makes
> sense for other architectures too.  The real semantics are basically force
> guest crash dump.

Ah, right. (There isn't really an equivalent to this on ARM since
we don't have a real NMI equivalent. So any implementation for ARM
qemu would be board dependent since you could wire a watchdog up to
any interrupt.)

Should we try to pick a command name that says what it's supposed to
do rather than how it happens to be implemented on x86 ?

-- PMM

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/07/2011 01:10 PM, Peter Maydell wrote:
> On 6 April 2011 20:34, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
>>
>> If an OS is totally hosed (spinning with interrupts disabled), and NMI can
>> be used to generate a crash dump.
>>
>> It's a debug feature and modelling it exactly the way we are probably makes
>> sense for other architectures too.  The real semantics are basically force
>> guest crash dump.
> Ah, right. (There isn't really an equivalent to this on ARM since
> we don't have a real NMI equivalent. So any implementation for ARM
> qemu would be board dependent since you could wire a watchdog up to
> any interrupt.)
>
> Should we try to pick a command name that says what it's supposed to
> do rather than how it happens to be implemented on x86 ?

Yup, I was thinking the same thing after I sent the note above.  If we 
call it 'force-crash-dump', we can implement it as an NMI on target-i386 
and potentially as something else on a different target.

Regards,

Anthony Liguori

> -- PMM
>

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Gleb Natapov]

On Thu, Apr 07, 2011 at 01:32:50PM -0500, Anthony Liguori wrote:
> On 04/07/2011 01:10 PM, Peter Maydell wrote:
> >On 6 April 2011 20:34, Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >>http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
> >>
> >>If an OS is totally hosed (spinning with interrupts disabled), and NMI can
> >>be used to generate a crash dump.
> >>
> >>It's a debug feature and modelling it exactly the way we are probably makes
> >>sense for other architectures too.  The real semantics are basically force
> >>guest crash dump.
> >Ah, right. (There isn't really an equivalent to this on ARM since
> >we don't have a real NMI equivalent. So any implementation for ARM
> >qemu would be board dependent since you could wire a watchdog up to
> >any interrupt.)
> >
> >Should we try to pick a command name that says what it's supposed to
> >do rather than how it happens to be implemented on x86 ?
> 
> Yup, I was thinking the same thing after I sent the note above.  If
> we call it 'force-crash-dump', we can implement it as an NMI on
> target-i386 and potentially as something else on a different target.
> 
NMI does not have to generate crash dump on every guest we support.
Actually even for windows guest it does not generate one without
tweaking registry. For all I know there is a guest that checks mail when
NMI arrives. Lets give meaningful name, like inject-nmi, for nmi
injection command.

--
			Gleb.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Blue Swirl]

On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Thu, Apr 07, 2011 at 01:32:50PM -0500, Anthony Liguori wrote:
>> On 04/07/2011 01:10 PM, Peter Maydell wrote:
>> >On 6 April 2011 20:34, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> >>http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
>> >>
>> >>If an OS is totally hosed (spinning with interrupts disabled), and NMI can
>> >>be used to generate a crash dump.
>> >>
>> >>It's a debug feature and modelling it exactly the way we are probably makes
>> >>sense for other architectures too.  The real semantics are basically force
>> >>guest crash dump.
>> >Ah, right. (There isn't really an equivalent to this on ARM since
>> >we don't have a real NMI equivalent. So any implementation for ARM
>> >qemu would be board dependent since you could wire a watchdog up to
>> >any interrupt.)
>> >
>> >Should we try to pick a command name that says what it's supposed to
>> >do rather than how it happens to be implemented on x86 ?
>>
>> Yup, I was thinking the same thing after I sent the note above.  If
>> we call it 'force-crash-dump', we can implement it as an NMI on
>> target-i386 and potentially as something else on a different target.
>>
> NMI does not have to generate crash dump on every guest we support.
> Actually even for windows guest it does not generate one without
> tweaking registry. For all I know there is a guest that checks mail when
> NMI arrives. Lets give meaningful name, like inject-nmi, for nmi
> injection command.

I'd prefer something more generic like these:
raise /apic@fee00000:l1int
lower /i44FX-pcihost/e1000@03.0/pinD

The clumsier syntax shouldn't be a problem, since this would be a
system developer tool.

Some kind of IRQ registration would be needed for this to work without
lots of changes.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Gleb Natapov]

On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
> On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Thu, Apr 07, 2011 at 01:32:50PM -0500, Anthony Liguori wrote:
> >> On 04/07/2011 01:10 PM, Peter Maydell wrote:
> >> >On 6 April 2011 20:34, Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >> >>http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=/liaai/crashdump/liaaicrashdumpnmiipmi.htm
> >> >>
> >> >>If an OS is totally hosed (spinning with interrupts disabled), and NMI can
> >> >>be used to generate a crash dump.
> >> >>
> >> >>It's a debug feature and modelling it exactly the way we are probably makes
> >> >>sense for other architectures too.  The real semantics are basically force
> >> >>guest crash dump.
> >> >Ah, right. (There isn't really an equivalent to this on ARM since
> >> >we don't have a real NMI equivalent. So any implementation for ARM
> >> >qemu would be board dependent since you could wire a watchdog up to
> >> >any interrupt.)
> >> >
> >> >Should we try to pick a command name that says what it's supposed to
> >> >do rather than how it happens to be implemented on x86 ?
> >>
> >> Yup, I was thinking the same thing after I sent the note above.  If
> >> we call it 'force-crash-dump', we can implement it as an NMI on
> >> target-i386 and potentially as something else on a different target.
> >>
> > NMI does not have to generate crash dump on every guest we support.
> > Actually even for windows guest it does not generate one without
> > tweaking registry. For all I know there is a guest that checks mail when
> > NMI arrives. Lets give meaningful name, like inject-nmi, for nmi
> > injection command.
> 
> I'd prefer something more generic like these:
> raise /apic@fee00000:l1int
> lower /i44FX-pcihost/e1000@03.0/pinD
> 
> The clumsier syntax shouldn't be a problem, since this would be a
> system developer tool.
> 
> Some kind of IRQ registration would be needed for this to work without
> lots of changes.
True. The ability to trigger any interrupt line is very useful for
debugging. I often re-implement it during debug.

--
			Gleb.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/07/2011 02:17 PM, Gleb Natapov wrote:
> On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
>> On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov<gleb@redhat.com>  wrote:
>>
>> I'd prefer something more generic like these:
>> raise /apic@fee00000:l1int
>> lower /i44FX-pcihost/e1000@03.0/pinD
>>
>> The clumsier syntax shouldn't be a problem, since this would be a
>> system developer tool.
>>
>> Some kind of IRQ registration would be needed for this to work without
>> lots of changes.
> True. The ability to trigger any interrupt line is very useful for
> debugging. I often re-implement it during debug.

And it's a good thing to have, but exposing this as the only API to do 
something as simple as generating a guest crash dump is not the 
friendliest thing in the world to do to users.

Regards,

Anthony Liguori

> --
> 			Gleb.
>

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Gleb Natapov]

On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
> On 04/07/2011 02:17 PM, Gleb Natapov wrote:
> >On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
> >>On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov<gleb@redhat.com>  wrote:
> >>
> >>I'd prefer something more generic like these:
> >>raise /apic@fee00000:l1int
> >>lower /i44FX-pcihost/e1000@03.0/pinD
> >>
> >>The clumsier syntax shouldn't be a problem, since this would be a
> >>system developer tool.
> >>
> >>Some kind of IRQ registration would be needed for this to work without
> >>lots of changes.
> >True. The ability to trigger any interrupt line is very useful for
> >debugging. I often re-implement it during debug.
> 
> And it's a good thing to have, but exposing this as the only API to
> do something as simple as generating a guest crash dump is not the
> friendliest thing in the world to do to users.
> 
Well, this is not intended to be used by regular users directly and
management can provide nicer interface for issuing NMI. But really,
my point is that NMI actually generates guest core dump in such rare
cases (only preconfigured Windows guests) that it doesn't warrant to
name command as such. Management is in much better position to implement
functionality with such name since it knows what type of guest it runs
and can tell agent to configure guest accordingly.

--
			Gleb.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Blue Swirl]

On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov <gleb@redhat.com> wrote:
> On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
>> On 04/07/2011 02:17 PM, Gleb Natapov wrote:
>> >On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
>> >>On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov<gleb@redhat.com>  wrote:
>> >>
>> >>I'd prefer something more generic like these:
>> >>raise /apic@fee00000:l1int
>> >>lower /i44FX-pcihost/e1000@03.0/pinD
>> >>
>> >>The clumsier syntax shouldn't be a problem, since this would be a
>> >>system developer tool.
>> >>
>> >>Some kind of IRQ registration would be needed for this to work without
>> >>lots of changes.
>> >True. The ability to trigger any interrupt line is very useful for
>> >debugging. I often re-implement it during debug.
>>
>> And it's a good thing to have, but exposing this as the only API to
>> do something as simple as generating a guest crash dump is not the
>> friendliest thing in the world to do to users.
>>
> Well, this is not intended to be used by regular users directly and
> management can provide nicer interface for issuing NMI. But really,
> my point is that NMI actually generates guest core dump in such rare
> cases (only preconfigured Windows guests) that it doesn't warrant to
> name command as such. Management is in much better position to implement
> functionality with such name since it knows what type of guest it runs
> and can tell agent to configure guest accordingly.

Does the management need to know about each and every debugging
oriented interface? For example, "info regs",  "info mem", "info irq"
and tracepoints?

I think giving IRQs symbolic names could solve some other problems as
well. Maybe it should be possible to connect IRQs in a configuration
file and even with command line:
-device port90,irqid=p90out -device pckbd,irqid=kbdout -device
and,in=p90out,in=kbdout,out=sreset device system_reset,in=sreset

or

 -device and,in=/i44FX-pcihost/PIIX3/i8042/out1,in=/i44FX-pcihost/PIIX3/p90/out1,out=/QEMU/system_reset

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/08/2011 02:17 PM, Blue Swirl wrote:
> On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov<gleb@redhat.com>  wrote:
>> On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
>>> On 04/07/2011 02:17 PM, Gleb Natapov wrote:
>>>> On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
>>>>> On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov<gleb@redhat.com>    wrote:
>>>>>
>>>>> I'd prefer something more generic like these:
>>>>> raise /apic@fee00000:l1int
>>>>> lower /i44FX-pcihost/e1000@03.0/pinD
>>>>>
>>>>> The clumsier syntax shouldn't be a problem, since this would be a
>>>>> system developer tool.
>>>>>
>>>>> Some kind of IRQ registration would be needed for this to work without
>>>>> lots of changes.
>>>> True. The ability to trigger any interrupt line is very useful for
>>>> debugging. I often re-implement it during debug.
>>> And it's a good thing to have, but exposing this as the only API to
>>> do something as simple as generating a guest crash dump is not the
>>> friendliest thing in the world to do to users.
>>>
>> Well, this is not intended to be used by regular users directly and
>> management can provide nicer interface for issuing NMI. But really,
>> my point is that NMI actually generates guest core dump in such rare
>> cases (only preconfigured Windows guests) that it doesn't warrant to
>> name command as such. Management is in much better position to implement
>> functionality with such name since it knows what type of guest it runs
>> and can tell agent to configure guest accordingly.
> Does the management need to know about each and every debugging
> oriented interface? For example, "info regs",  "info mem", "info irq"
> and tracepoints?
>
> I think giving IRQs symbolic names could solve some other problems as
> well. Maybe it should be possible to connect IRQs in a configuration
> file and even with command line:
> -device port90,irqid=p90out -device pckbd,irqid=kbdout -device
> and,in=p90out,in=kbdout,out=sreset device system_reset,in=sreset

You really want devices to have properties and for the device properties 
to be discoverable.  For instance:

struct DeviceInfo
{
      .name = "and",
      .properties = {
           DEFINE_IRQ_IN(AndDevice, in[0]),
           DEFINE_IRQ_IN(AndDevice, in[1]),
           DEFINE_IRQ_OUT(AndDevice, out),
      },
};

And then you can do:

-device port90,id=port90 -device pckbd,id=pckbd \
-device and,in[0]=port90.out,in[1]=pckbd.out,id=reset_and \
-device system_reset.in=reset_and

Regards,

Anthony Liguori

> or
>
>   -device and,in=/i44FX-pcihost/PIIX3/i8042/out1,in=/i44FX-pcihost/PIIX3/p90/out1,out=/QEMU/system_reset
>

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Blue Swirl]

On Fri, Apr 8, 2011 at 10:32 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 04/08/2011 02:17 PM, Blue Swirl wrote:
>>
>> On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov<gleb@redhat.com>  wrote:
>>>
>>> On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
>>>>
>>>> On 04/07/2011 02:17 PM, Gleb Natapov wrote:
>>>>>
>>>>> On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
>>>>>>
>>>>>> On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov<gleb@redhat.com>
>>>>>>  wrote:
>>>>>>
>>>>>> I'd prefer something more generic like these:
>>>>>> raise /apic@fee00000:l1int
>>>>>> lower /i44FX-pcihost/e1000@03.0/pinD
>>>>>>
>>>>>> The clumsier syntax shouldn't be a problem, since this would be a
>>>>>> system developer tool.
>>>>>>
>>>>>> Some kind of IRQ registration would be needed for this to work without
>>>>>> lots of changes.
>>>>>
>>>>> True. The ability to trigger any interrupt line is very useful for
>>>>> debugging. I often re-implement it during debug.
>>>>
>>>> And it's a good thing to have, but exposing this as the only API to
>>>> do something as simple as generating a guest crash dump is not the
>>>> friendliest thing in the world to do to users.
>>>>
>>> Well, this is not intended to be used by regular users directly and
>>> management can provide nicer interface for issuing NMI. But really,
>>> my point is that NMI actually generates guest core dump in such rare
>>> cases (only preconfigured Windows guests) that it doesn't warrant to
>>> name command as such. Management is in much better position to implement
>>> functionality with such name since it knows what type of guest it runs
>>> and can tell agent to configure guest accordingly.
>>
>> Does the management need to know about each and every debugging
>> oriented interface? For example, "info regs",  "info mem", "info irq"
>> and tracepoints?
>>
>> I think giving IRQs symbolic names could solve some other problems as
>> well. Maybe it should be possible to connect IRQs in a configuration
>> file and even with command line:
>> -device port90,irqid=p90out -device pckbd,irqid=kbdout -device
>> and,in=p90out,in=kbdout,out=sreset device system_reset,in=sreset
>
> You really want devices to have properties and for the device properties to
> be discoverable.  For instance:
>
> struct DeviceInfo
> {
>     .name = "and",
>     .properties = {
>          DEFINE_IRQ_IN(AndDevice, in[0]),
>          DEFINE_IRQ_IN(AndDevice, in[1]),
>          DEFINE_IRQ_OUT(AndDevice, out),
>     },
> };
>
> And then you can do:
>
> -device port90,id=port90 -device pckbd,id=pckbd \
> -device and,in[0]=port90.out,in[1]=pckbd.out,id=reset_and \
> -device system_reset.in=reset_and

Exactly. Given a NAND device, we could construct entire machines from
CLI or for example co-simulate SoCs with FPGAs using cells based on
the net lists.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Jamie Lokier]

Blue Swirl wrote:
> On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
> >> On 04/07/2011 02:17 PM, Gleb Natapov wrote:
> >> >On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
> >> >>On Thu, Apr 7, 2011 at 9:51 PM, Gleb Natapov<gleb@redhat.com>  wrote:
> >> >>
> >> >>I'd prefer something more generic like these:
> >> >>raise /apic@fee00000:l1int
> >> >>lower /i44FX-pcihost/e1000@03.0/pinD
> >> >>
> >> >>The clumsier syntax shouldn't be a problem, since this would be a
> >> >>system developer tool.
> >> >>
> >> >>Some kind of IRQ registration would be needed for this to work without
> >> >>lots of changes.
> >> >True. The ability to trigger any interrupt line is very useful for
> >> >debugging. I often re-implement it during debug.
> >>
> >> And it's a good thing to have, but exposing this as the only API to
> >> do something as simple as generating a guest crash dump is not the
> >> friendliest thing in the world to do to users.
> >>
> > Well, this is not intended to be used by regular users directly and
> > management can provide nicer interface for issuing NMI. But really,
> > my point is that NMI actually generates guest core dump in such rare
> > cases (only preconfigured Windows guests) that it doesn't warrant to
> > name command as such. Management is in much better position to implement
> > functionality with such name since it knows what type of guest it runs
> > and can tell agent to configure guest accordingly.
> 
> Does the management need to know about each and every debugging
> oriented interface? For example, "info regs",  "info mem", "info irq"
> and tracepoints?

Linux uses NMI for performance tracing, profiling, watchdog etc. so in
practice, NMI is very similar to the other IRQs.  I.e. highly guest
specific and depending on what's wired up to it.  Injecting NMI to all
CPUs at once does not make any sense for those Linux guests.

For Windows crash dumps, I think it makes sense to have a "button
wired to NMI" device, rather than inject-nmi directly, but I can see
that inject-nmi solves the intended problem quite neatly.

For Linux crash dumps, for example, there are other key combinations,
as well as watchdog devices, that can be used to trigger them.  A
virtual "button wired to GPIO/PCI-IRQ/etc." device might be quite
handy for debugging Linux guests, and would fit comfortably in a
management interface.

-- Jamie

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Avi Kivity]

On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>
> And it's a good thing to have, but exposing this as the only API to do 
> something as simple as generating a guest crash dump is not the 
> friendliest thing in the world to do to users.

nmi is a fine name for something that corresponds to a real-life nmi 
button (often labeled "NMI").

generate-crash-dump is a wrong name for something that doesn't generate 
a crash dump (the guest may not be configured for it, or it may fail to 
work).  I'd expect that to be host-side functionality.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Markus Armbruster]

Avi Kivity <avi@redhat.com> writes:

> On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>>
>> And it's a good thing to have, but exposing this as the only API to
>> do something as simple as generating a guest crash dump is not the
>> friendliest thing in the world to do to users.
>
> nmi is a fine name for something that corresponds to a real-life nmi
> button (often labeled "NMI").

Agree.

> generate-crash-dump is a wrong name for something that doesn't
> generate a crash dump (the guest may not be configured for it, or it
> may fail to work).

Or the OS uses the NMI button for something else.

>                     I'd expect that to be host-side functionality.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Blue Swirl]

On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Avi Kivity <avi@redhat.com> writes:
>
>> On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>>>
>>> And it's a good thing to have, but exposing this as the only API to
>>> do something as simple as generating a guest crash dump is not the
>>> friendliest thing in the world to do to users.
>>
>> nmi is a fine name for something that corresponds to a real-life nmi
>> button (often labeled "NMI").
>
> Agree.

We could also introduce an alias mechanism for user friendly names, so
nmi could be used in addition of full path. Aliases could be useful
for device paths as well.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Avi Kivity]

On 04/11/2011 08:15 PM, Blue Swirl wrote:
> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@redhat.com>  wrote:
> >  Avi Kivity<avi@redhat.com>  writes:
> >
> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
> >>>
> >>>  And it's a good thing to have, but exposing this as the only API to
> >>>  do something as simple as generating a guest crash dump is not the
> >>>  friendliest thing in the world to do to users.
> >>
> >>  nmi is a fine name for something that corresponds to a real-life nmi
> >>  button (often labeled "NMI").
> >
> >  Agree.
>
> We could also introduce an alias mechanism for user friendly names, so
> nmi could be used in addition of full path. Aliases could be useful
> for device paths as well.

Yes.  Perhaps limited to the human monitor.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Blue Swirl]

On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <avi@redhat.com> wrote:
> On 04/11/2011 08:15 PM, Blue Swirl wrote:
>>
>> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@redhat.com>
>>  wrote:
>> >  Avi Kivity<avi@redhat.com>  writes:
>> >
>> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>> >>>
>> >>>  And it's a good thing to have, but exposing this as the only API to
>> >>>  do something as simple as generating a guest crash dump is not the
>> >>>  friendliest thing in the world to do to users.
>> >>
>> >>  nmi is a fine name for something that corresponds to a real-life nmi
>> >>  button (often labeled "NMI").
>> >
>> >  Agree.
>>
>> We could also introduce an alias mechanism for user friendly names, so
>> nmi could be used in addition of full path. Aliases could be useful
>> for device paths as well.
>
> Yes.  Perhaps limited to the human monitor.

I'd limit all debugging commands (including NMI) to the human monitor.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Luiz Capitulino]

On Tue, 12 Apr 2011 21:31:18 +0300
Blue Swirl <blauwirbel@gmail.com> wrote:

> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <avi@redhat.com> wrote:
> > On 04/11/2011 08:15 PM, Blue Swirl wrote:
> >>
> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@redhat.com>
> >>  wrote:
> >> >  Avi Kivity<avi@redhat.com>  writes:
> >> >
> >> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
> >> >>>
> >> >>>  And it's a good thing to have, but exposing this as the only API to
> >> >>>  do something as simple as generating a guest crash dump is not the
> >> >>>  friendliest thing in the world to do to users.
> >> >>
> >> >>  nmi is a fine name for something that corresponds to a real-life nmi
> >> >>  button (often labeled "NMI").
> >> >
> >> >  Agree.
> >>
> >> We could also introduce an alias mechanism for user friendly names, so
> >> nmi could be used in addition of full path. Aliases could be useful
> >> for device paths as well.
> >
> > Yes.  Perhaps limited to the human monitor.
> 
> I'd limit all debugging commands (including NMI) to the human monitor.

Why?

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Blue Swirl]

On Wed, Apr 13, 2011 at 4:08 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Tue, 12 Apr 2011 21:31:18 +0300
> Blue Swirl <blauwirbel@gmail.com> wrote:
>
>> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <avi@redhat.com> wrote:
>> > On 04/11/2011 08:15 PM, Blue Swirl wrote:
>> >>
>> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@redhat.com>
>> >>  wrote:
>> >> >  Avi Kivity<avi@redhat.com>  writes:
>> >> >
>> >> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>> >> >>>
>> >> >>>  And it's a good thing to have, but exposing this as the only API to
>> >> >>>  do something as simple as generating a guest crash dump is not the
>> >> >>>  friendliest thing in the world to do to users.
>> >> >>
>> >> >>  nmi is a fine name for something that corresponds to a real-life nmi
>> >> >>  button (often labeled "NMI").
>> >> >
>> >> >  Agree.
>> >>
>> >> We could also introduce an alias mechanism for user friendly names, so
>> >> nmi could be used in addition of full path. Aliases could be useful
>> >> for device paths as well.
>> >
>> > Yes.  Perhaps limited to the human monitor.
>>
>> I'd limit all debugging commands (including NMI) to the human monitor.
>
> Why?

Do they have any real use in production environment? Also, we should
have the freedom to change the debugging facilities (for example, to
improve some internal implementation) as we want without regard to
compatibility to previous versions.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Markus Armbruster]

Blue Swirl <blauwirbel@gmail.com> writes:

> On Wed, Apr 13, 2011 at 4:08 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
>> On Tue, 12 Apr 2011 21:31:18 +0300
>> Blue Swirl <blauwirbel@gmail.com> wrote:
>>
>>> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <avi@redhat.com> wrote:
>>> > On 04/11/2011 08:15 PM, Blue Swirl wrote:
>>> >>
>>> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@redhat.com>
>>> >>  wrote:
>>> >> >  Avi Kivity<avi@redhat.com>  writes:
>>> >> >
>>> >> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>>> >> >>>
>>> >> >>>  And it's a good thing to have, but exposing this as the only API to
>>> >> >>>  do something as simple as generating a guest crash dump is not the
>>> >> >>>  friendliest thing in the world to do to users.
>>> >> >>
>>> >> >>  nmi is a fine name for something that corresponds to a real-life nmi
>>> >> >>  button (often labeled "NMI").
>>> >> >
>>> >> >  Agree.
>>> >>
>>> >> We could also introduce an alias mechanism for user friendly names, so
>>> >> nmi could be used in addition of full path. Aliases could be useful
>>> >> for device paths as well.
>>> >
>>> > Yes.  Perhaps limited to the human monitor.
>>>
>>> I'd limit all debugging commands (including NMI) to the human monitor.
>>
>> Why?
>
> Do they have any real use in production environment? Also, we should
> have the freedom to change the debugging facilities (for example, to
> improve some internal implementation) as we want without regard to
> compatibility to previous versions.

For what it's worth, Lai (original poster) has been trying for many
months to get inject-nmi into QMP, and I suspect he has a really good
reason for his super-human persistence.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Daniel P. Berrange]

On Wed, Apr 13, 2011 at 10:56:21PM +0300, Blue Swirl wrote:
> On Wed, Apr 13, 2011 at 4:08 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > On Tue, 12 Apr 2011 21:31:18 +0300
> > Blue Swirl <blauwirbel@gmail.com> wrote:
> >
> >> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <avi@redhat.com> wrote:
> >> > On 04/11/2011 08:15 PM, Blue Swirl wrote:
> >> >>
> >> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@redhat.com>
> >> >>  wrote:
> >> >> >  Avi Kivity<avi@redhat.com>  writes:
> >> >> >
> >> >> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
> >> >> >>>
> >> >> >>>  And it's a good thing to have, but exposing this as the only API to
> >> >> >>>  do something as simple as generating a guest crash dump is not the
> >> >> >>>  friendliest thing in the world to do to users.
> >> >> >>
> >> >> >>  nmi is a fine name for something that corresponds to a real-life nmi
> >> >> >>  button (often labeled "NMI").
> >> >> >
> >> >> >  Agree.
> >> >>
> >> >> We could also introduce an alias mechanism for user friendly names, so
> >> >> nmi could be used in addition of full path. Aliases could be useful
> >> >> for device paths as well.
> >> >
> >> > Yes.  Perhaps limited to the human monitor.
> >>
> >> I'd limit all debugging commands (including NMI) to the human monitor.
> >
> > Why?
> 
> Do they have any real use in production environment? Also, we should
> have the freedom to change the debugging facilities (for example, to
> improve some internal implementation) as we want without regard to
> compatibility to previous versions.

We have users of libvirt requesting that we add an API for triggering
a NMI. They want this for support in a production environment, to be
able to initiate Windows crash dumps.  We really don't want to have to
use HMP passthrough for this, instead of a proper QMP command.

More generally I don't want to see stuff in HMP, that isn't in the QMP.
We already have far too much that we have to do via HMP passthrough in
libvirt due to lack of QMP commands, to the extent that we might as
well have just ignored QMP and continued with HMP for everything.

If we want the flexibility to change the debugging commands between
releases then we should come up with a plan to do this within the
scope of QMP, not restrict them to HMP only.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Blue Swirl]

On Thu, Apr 14, 2011 at 12:55 PM, Daniel P. Berrange
<berrange@redhat.com> wrote:
> On Wed, Apr 13, 2011 at 10:56:21PM +0300, Blue Swirl wrote:
>> On Wed, Apr 13, 2011 at 4:08 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
>> > On Tue, 12 Apr 2011 21:31:18 +0300
>> > Blue Swirl <blauwirbel@gmail.com> wrote:
>> >
>> >> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <avi@redhat.com> wrote:
>> >> > On 04/11/2011 08:15 PM, Blue Swirl wrote:
>> >> >>
>> >> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@redhat.com>
>> >> >>  wrote:
>> >> >> >  Avi Kivity<avi@redhat.com>  writes:
>> >> >> >
>> >> >> >>  On 04/08/2011 12:41 AM, Anthony Liguori wrote:
>> >> >> >>>
>> >> >> >>>  And it's a good thing to have, but exposing this as the only API to
>> >> >> >>>  do something as simple as generating a guest crash dump is not the
>> >> >> >>>  friendliest thing in the world to do to users.
>> >> >> >>
>> >> >> >>  nmi is a fine name for something that corresponds to a real-life nmi
>> >> >> >>  button (often labeled "NMI").
>> >> >> >
>> >> >> >  Agree.
>> >> >>
>> >> >> We could also introduce an alias mechanism for user friendly names, so
>> >> >> nmi could be used in addition of full path. Aliases could be useful
>> >> >> for device paths as well.
>> >> >
>> >> > Yes.  Perhaps limited to the human monitor.
>> >>
>> >> I'd limit all debugging commands (including NMI) to the human monitor.
>> >
>> > Why?
>>
>> Do they have any real use in production environment? Also, we should
>> have the freedom to change the debugging facilities (for example, to
>> improve some internal implementation) as we want without regard to
>> compatibility to previous versions.
>
> We have users of libvirt requesting that we add an API for triggering
> a NMI. They want this for support in a production environment, to be
> able to initiate Windows crash dumps.  We really don't want to have to
> use HMP passthrough for this, instead of a proper QMP command.

OK, maybe I shouldn't be very proud of my imagination.

> More generally I don't want to see stuff in HMP, that isn't in the QMP.
> We already have far too much that we have to do via HMP passthrough in
> libvirt due to lack of QMP commands, to the extent that we might as
> well have just ignored QMP and continued with HMP for everything.
>
> If we want the flexibility to change the debugging commands between
> releases then we should come up with a plan to do this within the
> scope of QMP, not restrict them to HMP only.

If there is a need for the debugging facilities, full QMP support and
some level of compatibility is fine.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Anthony Liguori]

On 04/07/2011 01:51 PM, Gleb Natapov wrote:
> NMI does not have to generate crash dump on every guest we support.
> Actually even for windows guest it does not generate one without
> tweaking registry. For all I know there is a guest that checks mail when
> NMI arrives.

And for all we know, a guest can respond to an ACPI poweroff event by 
tweeting the star spangled banner but we still call the corresponding 
QMP command system_poweroff.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Gleb Natapov]

On Thu, Apr 07, 2011 at 04:39:58PM -0500, Anthony Liguori wrote:
> On 04/07/2011 01:51 PM, Gleb Natapov wrote:
> >NMI does not have to generate crash dump on every guest we support.
> >Actually even for windows guest it does not generate one without
> >tweaking registry. For all I know there is a guest that checks mail when
> >NMI arrives.
> 
> And for all we know, a guest can respond to an ACPI poweroff event
> by tweeting the star spangled banner but we still call the
> corresponding QMP command system_poweroff.
> 
Correct :) But at least system_poweroff implements ACPI poweroff as
defined by ACPI spec. NMI is not designed as core dump event and is not
used as such by majority of the guests.

--
			Gleb.

Re: [Qemu-devel] [PATCH 2/2 V7] qemu, qmp: add inject-nmi qmp command

[Jamie Lokier]

Gleb Natapov wrote:
> On Thu, Apr 07, 2011 at 04:39:58PM -0500, Anthony Liguori wrote:
> > On 04/07/2011 01:51 PM, Gleb Natapov wrote:
> > >NMI does not have to generate crash dump on every guest we support.
> > >Actually even for windows guest it does not generate one without
> > >tweaking registry. For all I know there is a guest that checks mail when
> > >NMI arrives.
> > 
> > And for all we know, a guest can respond to an ACPI poweroff event
> > by tweeting the star spangled banner but we still call the
> > corresponding QMP command system_poweroff.
> > 
> Correct :) But at least system_poweroff implements ACPI poweroff as
> defined by ACPI spec. NMI is not designed as core dump event and is not
> used as such by majority of the guests.

Imho acpi_poweroff or poweroff_button would have been a clearer name.
Or even 'sendkey poweroff' - it's just a button someone on the
keyboard on a lot of systems anyway.  Next to the email button and what
looks, on my laptop, like the play-a-tune button :-)

I put system_poweroff into some QEMU-controlling scripts once, and was
disappointed when several guests ignored it.

But it's done now.

-- Jamie

Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command

[Avi Kivity]

On 04/08/2011 12:39 AM, Anthony Liguori wrote:
> On 04/07/2011 01:51 PM, Gleb Natapov wrote:
>> NMI does not have to generate crash dump on every guest we support.
>> Actually even for windows guest it does not generate one without
>> tweaking registry. For all I know there is a guest that checks mail when
>> NMI arrives.
>
> And for all we know, a guest can respond to an ACPI poweroff event by 
> tweeting the star spangled banner but we still call the corresponding 
> QMP command system_poweroff.
>

A better name for it would be system_power_button.  While guests that 
blast away national anthems when the button is pressed are rare (no 
doubt to the high localization costs), it's possible to configure an OS 
to go into S3 sleep when the button is pressed (I used to do it when I 
had a desktop at home).

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command

[Lai Jiangshan]

These patches are applied for "http://repo.or.cz/r/qemu/aliguori.git glib".

These patches add QAPI inject-nmi. They are passed checkpatch.pl and the build.

But the result qemu executable file is not tested, because the result
qemu of "http://repo.or.cz/r/qemu/aliguori.git glib" can't work in my box.

Lai Jiangshan (3):
  QError: Introduce QERR_UNSUPPORTED
  qapi,nmi: add inject-nmi qmp command
  qapi-hmp: Convert HMP nmi to use QMP

 hmp-commands.hx  |   18 ++++++++----------
 hmp.c            |   12 ++++++++++++
 hmp.h            |    1 +
 monitor.c        |   14 --------------
 qapi-schema.json |   12 ++++++++++++
 qerror.c         |    4 ++++
 qerror.h         |    3 +++
 qmp.c            |   17 +++++++++++++++++
 8 files changed, 57 insertions(+), 24 deletions(-)

-- 
1.7.4

Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command

[Lai Jiangshan]

Hi, Anthony Liguori

Any suggestion?

Although all command line interfaces will be converted to to use QMP interfaces in 0.16,
I hope inject-nmi come into QAPI earlier, 0.15.

Thanks,
Lai

Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command

[Luiz Capitulino]

On Thu, 21 Apr 2011 11:23:54 +0800
Lai Jiangshan <laijs@cn.fujitsu.com> wrote:

> 
> Hi, Anthony Liguori
> 
> Any suggestion?
> 
> Although all command line interfaces will be converted to to use QMP interfaces in 0.16,
> I hope inject-nmi come into QAPI earlier, 0.15.

I don't know what Anthony thinks about adding new commands like this one that
early to the new QMP interface, but adding them to current QMP will certainly
cause less code churn on your side. That's what I'd recommend for now.

Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command

[Anthony Liguori]

On 04/26/2011 08:26 AM, Luiz Capitulino wrote:
> On Thu, 21 Apr 2011 11:23:54 +0800
> Lai Jiangshan<laijs@cn.fujitsu.com>  wrote:
>
>>
>> Hi, Anthony Liguori
>>
>> Any suggestion?
>>
>> Although all command line interfaces will be converted to to use QMP interfaces in 0.16,
>> I hope inject-nmi come into QAPI earlier, 0.15.
>
> I don't know what Anthony thinks about adding new commands like this one that
> early to the new QMP interface, but adding them to current QMP will certainly
> cause less code churn on your side. That's what I'd recommend for now.

Yeah, sorry, this whole series has been confused in the QAPI discussion.

I did not intend for QAPI to be disruptive to current development.

As far as I can tell, the last series that was posted (before the QAPI 
post) still had checkpatch.pl issues (scripts/checkpatch.pl btw) and we 
had agreed that once that was resolved, it would come in through Luiz's 
tree.

Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command

[Lai Jiangshan]

On 04/26/2011 09:29 PM, Anthony Liguori wrote:
> On 04/26/2011 08:26 AM, Luiz Capitulino wrote:
>> On Thu, 21 Apr 2011 11:23:54 +0800
>> Lai Jiangshan<laijs@cn.fujitsu.com>  wrote:
>>
>>>
>>> Hi, Anthony Liguori
>>>
>>> Any suggestion?
>>>
>>> Although all command line interfaces will be converted to to use QMP interfaces in 0.16,
>>> I hope inject-nmi come into QAPI earlier, 0.15.
>>
>> I don't know what Anthony thinks about adding new commands like this one that
>> early to the new QMP interface, but adding them to current QMP will certainly
>> cause less code churn on your side. That's what I'd recommend for now.
> 
> Yeah, sorry, this whole series has been confused in the QAPI discussion.
> 
> I did not intend for QAPI to be disruptive to current development.
> 
> As far as I can tell, the last series that was posted (before the QAPI post) still had checkpatch.pl issues (scripts/checkpatch.pl btw) and we had agreed that once that was resolved, it would come in through Luiz's tree.
> 

Sorry, I didn't caught the meaning.
Fix checkpatch.pl issues of V7 Patch, and sent it again?

Thanks,
Lai

Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command

[Luiz Capitulino]

On Wed, 27 Apr 2011 09:54:34 +0800
Lai Jiangshan <laijs@cn.fujitsu.com> wrote:

> On 04/26/2011 09:29 PM, Anthony Liguori wrote:
> > On 04/26/2011 08:26 AM, Luiz Capitulino wrote:
> >> On Thu, 21 Apr 2011 11:23:54 +0800
> >> Lai Jiangshan<laijs@cn.fujitsu.com>  wrote:
> >>
> >>>
> >>> Hi, Anthony Liguori
> >>>
> >>> Any suggestion?
> >>>
> >>> Although all command line interfaces will be converted to to use QMP interfaces in 0.16,
> >>> I hope inject-nmi come into QAPI earlier, 0.15.
> >>
> >> I don't know what Anthony thinks about adding new commands like this one that
> >> early to the new QMP interface, but adding them to current QMP will certainly
> >> cause less code churn on your side. That's what I'd recommend for now.
> > 
> > Yeah, sorry, this whole series has been confused in the QAPI discussion.
> > 
> > I did not intend for QAPI to be disruptive to current development.
> > 
> > As far as I can tell, the last series that was posted (before the QAPI post) still had checkpatch.pl issues (scripts/checkpatch.pl btw) and we had agreed that once that was resolved, it would come in through Luiz's tree.
> > 
> 
> Sorry, I didn't caught the meaning.
> Fix checkpatch.pl issues of V7 Patch, and sent it again?

Yes, my recommendation for your series is:

 1. Address checkpatch.pl errors

 2. Change the HMP to use your implementation, which send the NMI
    to all CPUs

 3. Any other _code_ review comments I might be missing

[Qemu-devel] [PATCH 0/2 V9] hmp,qmp: add inject-nmi

[Lai Jiangshan]

Adds new QERR_UNSUPPORTED, converts "nmi" to "inject-nmi" and
make it supports qmp.

Lai Jiangshan (2):
  qemu,qmp: QError: New QERR_UNSUPPORTED
  qmp,inject-nmi: convert do_inject_nmi() to QObject


 hmp-commands.hx |   21 +++++++++++----------
 monitor.c       |   20 +++++++++++++-------
 qerror.c        |    4 ++++
 qerror.h        |    3 +++
 qmp-commands.hx |   29 +++++++++++++++++++++++++++++
 5 files changed, 60 insertions(+), 17 deletions(-)

-- 
1.7.4

Re: [Qemu-devel] [PATCH 0/2 V9] hmp,qmp: add inject-nmi

[Luiz Capitulino]

On Thu, 28 Apr 2011 11:35:20 +0800
Lai Jiangshan <laijs@cn.fujitsu.com> wrote:

> 
> 
> Adds new QERR_UNSUPPORTED, converts "nmi" to "inject-nmi" and
> make it supports qmp.

Lai, unfortunately this series still have some issues (like changing
the HMP command name). I think V7 was the best submission so far, so
I decided to do this: I've incorporated your v7 patches in a new series
and fixed a few issues. I'll submit it for review.

[Qemu-devel] [PATCH 1/2 V9] qemu, qmp: QError: New QERR_UNSUPPORTED

[Lai Jiangshan]

New QERR_UNSUPPORTED for unsupported commands or requests.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 qerror.c |    4 ++++
 qerror.h |    3 +++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/qerror.c b/qerror.c
index 4855604..f905887 100644
--- a/qerror.c
+++ b/qerror.c
@@ -206,6 +206,10 @@ static const QErrorStringTable qerror_table[] = {
                      "supported by this qemu version: %(feature)",
     },
     {
+        .error_fmt = QERR_UNSUPPORTED,
+        .desc      = "Unsupported: %(detail)",
+    },
+    {
         .error_fmt = QERR_VNC_SERVER_FAILED,
         .desc      = "Could not start VNC server on %(target)",
     },
diff --git a/qerror.h b/qerror.h
index df61d2c..b3455ce 100644
--- a/qerror.h
+++ b/qerror.h
@@ -168,6 +168,9 @@ QError *qobject_to_qerror(const QObject *obj);
 #define QERR_UNKNOWN_BLOCK_FORMAT_FEATURE \
     "{ 'class': 'UnknownBlockFormatFeature', 'data': { 'device': %s, 'format': %s, 'feature': %s } }"
 
+#define QERR_UNSUPPORTED \
+    "{ 'class': 'Unsupported', 'data': { 'detail': %s } }"
+
 #define QERR_VNC_SERVER_FAILED \
     "{ 'class': 'VNCServerFailed', 'data': { 'target': %s } }"
 
-- 
1.7.4

[Qemu-devel] [PATCH 2/2 V9] qmp, inject-nmi: convert do_inject_nmi() to QObject

[Lai Jiangshan]

Make we can inject NMI via qemu-monitor-protocol.
We use "inject-nmi" for the command name, the meaning is clearer.
The behavior is cheanged to "injecting NMI to all CPU" which
simulates the Real hardware NMI button.

The command "inject-nmi" is only supported for x86 guest
currently, it will returns "Unsupported" error for non-x86 guest.
This error and this behavior are described in the comments.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 hmp-commands.hx |   21 +++++++++++----------
 monitor.c       |   20 +++++++++++++-------
 qmp-commands.hx |   29 +++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+), 17 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 834e6a8..b511850 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -737,19 +737,20 @@ The values that can be specified here depend on the machine type, but are
 the same that can be specified in the @code{-boot} command line option.
 ETEXI
 
-#if defined(TARGET_I386)
     {
-        .name       = "nmi",
-        .args_type  = "cpu_index:i",
-        .params     = "cpu",
-        .help       = "inject an NMI on the given CPU",
-        .mhandler.cmd = do_inject_nmi,
+        .name       = "inject-nmi",
+        .args_type  = "",
+        .params     = "",
+        .help       = "Inject an NMI on guest.\n"
+                      "Returns \"Unsupported\" error when the guest does"
+                      "not support NMI injection",
+        .user_print = monitor_user_noop,
+        .mhandler.cmd_new = do_inject_nmi,
     },
-#endif
 STEXI
-@item nmi @var{cpu}
-@findex nmi
-Inject an NMI on the given CPU (x86 only).
+@item inject-nmi
+@findex inject-nmi
+Inject an NMI on the guest (x86 only).
 ETEXI
 
     {
diff --git a/monitor.c b/monitor.c
index 5f3bc72..129eed1 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2544,16 +2544,22 @@ 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");
 
-    for (env = first_cpu; env != NULL; env = env->next_cpu)
-        if (env->cpu_index == cpu_index) {
-            cpu_interrupt(env, CPU_INTERRUPT_NMI);
-            break;
-        }
+    for (env = first_cpu; env != NULL; env = env->next_cpu) {
+        cpu_interrupt(env, CPU_INTERRUPT_NMI);
+    }
+
+    return 0;
+}
+#else
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    qerror_report(QERR_UNSUPPORTED,
+                  "Injecting NMI is unsupported for the non-x86 guest");
+    return -1;
 }
 #endif
 
diff --git a/qmp-commands.hx b/qmp-commands.hx
index fbd98ee..e1b9b40 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -430,6 +430,35 @@ Example:
 EQMP
 
     {
+        .name       = "inject-nmi",
+        .args_type  = "",
+        .params     = "",
+        .help       = "Inject an NMI on guest.\n"
+                      "Returns \"Unsupported\" error when the guest does"
+                      "not support NMI injection",
+        .user_print = monitor_user_noop,
+        .mhandler.cmd_new = do_inject_nmi,
+    },
+
+SQMP
+inject-nmi
+----------
+
+Inject an NMI on guest.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "inject-nmi" }
+<- { "return": {} }
+
+Note: inject-nmi is only supported for x86 guest currently, it will
+      returns "Unsupported" error for non-x86 guest.
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
-- 
1.7.4

Re: [Qemu-devel] [RFC PATCH 0/3 V8] QAPI: add inject-nmi qmp command

[Michael Roth]

On 04/20/2011 01:19 AM, Lai Jiangshan wrote:
>
>
> These patches are applied for "http://repo.or.cz/r/qemu/aliguori.git glib".
>
> These patches add QAPI inject-nmi. They are passed checkpatch.pl and the build.
>
> But the result qemu executable file is not tested, because the result
> qemu of "http://repo.or.cz/r/qemu/aliguori.git glib" can't work in my box.

What issues are you seeing using the binary from the glib tree? AFAIK 
that tree should be functional, except potentially with TCG. I've only 
been using it with KVM and --enable-io-thread though so don't know for sure.

>
> Lai Jiangshan (3):
>    QError: Introduce QERR_UNSUPPORTED
>    qapi,nmi: add inject-nmi qmp command
>    qapi-hmp: Convert HMP nmi to use QMP
>
>   hmp-commands.hx  |   18 ++++++++----------
>   hmp.c            |   12 ++++++++++++
>   hmp.h            |    1 +
>   monitor.c        |   14 --------------
>   qapi-schema.json |   12 ++++++++++++
>   qerror.c         |    4 ++++
>   qerror.h         |    3 +++
>   qmp.c            |   17 +++++++++++++++++
>   8 files changed, 57 insertions(+), 24 deletions(-)
>

[Qemu-devel] [RFC PATCH 1/3 V8] QError: Introduce QERR_UNSUPPORTED

[Lai Jiangshan]

New QERR_UNSUPPORTED for unsupported commands or requests.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 qerror.c |    4 ++++
 qerror.h |    3 +++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/qerror.c b/qerror.c
index c76257f..bafe520 100644
--- a/qerror.c
+++ b/qerror.c
@@ -213,6 +213,10 @@ static const QErrorStringTable qerror_table[] = {
         .desc      = "Cannot set union '%(name)' of type '%(type)' to value '%(new-value)' because it already is set to value '%(value)'"
     },
     {
+        .error_fmt = QERR_UNSUPPORTED,
+        .desc      = "Unsupported: %(detail)",
+    },
+    {
         .error_fmt = QERR_VNC_SERVER_FAILED,
         .desc      = "Could not start VNC server on %(target)",
     },
diff --git a/qerror.h b/qerror.h
index 1f98be1..01ec87d 100644
--- a/qerror.h
+++ b/qerror.h
@@ -193,6 +193,9 @@ void qerror_set_desc(QError *qerr, const char *fmt);
 #define QERR_UNION_MULTIPLE_ENTRIES \
     "{ 'class': 'UnionMultipleEntries', 'data': { 'name': %s, 'type': %s, 'value': %s, 'new-value': %s } }"
 
+#define QERR_UNSUPPORTED \
+    "{ 'class': 'Unsupported', 'data': { 'detail': %s } }"
+
 #define QERR_VNC_SERVER_FAILED \
     "{ 'class': 'VNCServerFailed', 'data': { 'target': %s } }"
 
-- 
1.7.4

[Qemu-devel] [RFC PATCH 2/3 V8] qapi, nmi: add inject-nmi qmp command

[Lai Jiangshan]

inject-nmi command injects an NMI on all CPUs of guest.
It is only supported for x86 guest currently, it will
returns "Unsupported" error for non-x86 guest.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 qapi-schema.json |   12 ++++++++++++
 qmp.c            |   17 +++++++++++++++++
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index de6c9a3..6a94d78 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1498,3 +1498,15 @@
 # Since: 0.14.0
 ##
 { 'option': 'vnc', 'data': 'VncConfig', 'implicit': 'address' }
+
+##
+# @inject-nmi:
+#
+# Inject an NMI on the guest.
+#
+# Returns: Nothing on success.
+#          If the guest(non-x86) does not support NMI injection, Unsupported
+#
+# Since: 0.15.0
+##
+{ 'command': 'inject-nmi' }
diff --git a/qmp.c b/qmp.c
index 9fdde8f..dac411a 100644
--- a/qmp.c
+++ b/qmp.c
@@ -379,3 +379,20 @@ StatusInfo *qmp_query_status(Error **errp)
 
     return info;
 }
+
+#if defined(TARGET_I386)
+void qmp_inject_nmi(Error **errp)
+{
+    CPUState *env;
+
+    for (env = first_cpu; env != NULL; env = env->next_cpu) {
+        cpu_interrupt(env, CPU_INTERRUPT_NMI);
+    }
+}
+#else
+void qmp_inject_nmi(Error **errp)
+{
+    error_set(errp, QERR_UNSUPPORTED,
+              "Injecting NMI is unsupported for the non-x86 guest");
+}
+#endif
-- 
1.7.4

[Qemu-devel] [RFC PATCH 3/3 V8] qapi-hmp: Convert HMP nmi to use QMP

[Lai Jiangshan]

Convert the name of HMP nmi to inject-nmi, and use QMP inject-nmi.
The behavier is also changed, it injects NMI to all CPUs of the guest.
When the guest is non-x86, it reports "Unsupported" error.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 hmp-commands.hx |   18 ++++++++----------
 hmp.c           |   12 ++++++++++++
 hmp.h           |    1 +
 monitor.c       |   14 --------------
 4 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index c0719eb..70a9dd9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -705,19 +705,17 @@ The values that can be specified here depend on the machine type, but are
 the same that can be specified in the @code{-boot} command line option.
 ETEXI
 
-#if defined(TARGET_I386)
     {
-        .name       = "nmi",
-        .args_type  = "cpu_index:i",
-        .params     = "cpu",
-        .help       = "inject an NMI on the given CPU",
-        .mhandler.cmd = do_inject_nmi,
+        .name       = "inject-nmi",
+        .args_type  = "",
+        .params     = "",
+        .help       = "inject an NMI on the guest",
+        .mhandler.cmd = hmp_inject_nmi,
     },
-#endif
 STEXI
-@item nmi @var{cpu}
-@findex nmi
-Inject an NMI on the given CPU (x86 only).
+@item inject-nmi
+@findex inject-nmi
+Inject an NMI on the guest (x86 only).
 ETEXI
 
     {
diff --git a/hmp.c b/hmp.c
index 758b085..07170fd 100644
--- a/hmp.c
+++ b/hmp.c
@@ -369,6 +369,18 @@ void hmp_closefd(Monitor *mon, const QDict *qdict)
     monitor_printf(mon, "closefd: Command Not Supported, use QMP\n");
 }
 
+void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
+{
+    Error *err = NULL;
+
+    qmp_inject_nmi(&err);
+
+    if (err) {
+        monitor_printf(mon, "inject-nmi: %s\n", error_get_pretty(err));
+        error_free(err);
+    }
+}
+
 void hmp_info_version(Monitor *mon)
 {
     VersionInfo *info;
diff --git a/hmp.h b/hmp.h
index d205b3e..3bc1f54 100644
--- a/hmp.h
+++ b/hmp.h
@@ -31,6 +31,7 @@ void hmp_migrate_set_speed(Monitor *mon, const QDict *qdict);
 void hmp_migrate_set_downtime(Monitor *mon, const QDict *qdict);
 void hmp_getfd(Monitor *mon, const QDict *qdict);
 void hmp_closefd(Monitor *mon, const QDict *qdict);
+void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
 
 void hmp_info_version(Monitor *mon);
 void hmp_info_status(Monitor *mon);
diff --git a/monitor.c b/monitor.c
index 25a4ab5..925c143 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1768,20 +1768,6 @@ 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)
-{
-    CPUState *env;
-    int cpu_index = qdict_get_int(qdict, "cpu_index");
-
-    for (env = first_cpu; env != NULL; env = env->next_cpu)
-        if (env->cpu_index == cpu_index) {
-            cpu_interrupt(env, CPU_INTERRUPT_NMI);
-            break;
-        }
-}
-#endif
-
 static qemu_acl *find_acl(Monitor *mon, const char *name)
 {
     qemu_acl *acl = qemu_acl_find(name);
-- 
1.7.4