| Message ID | 4D74A974.6090509@cn.fujitsu.com |
|---|---|
| State | New |
| Headers | show |
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
[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.
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.
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. >
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
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
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).
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?
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
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 >
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
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.
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
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 >
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
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
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 >
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.
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.
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.
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
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. >
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.
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.
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
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 >
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.
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.
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).
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.
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.
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.
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.
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?
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.
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.
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
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.
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
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 >
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(-)
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
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 >
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(-) >
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.
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
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
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
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(-)
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.
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
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
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",
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(-)