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

[Blue Swirl <blauwirbel@gmail.com>]

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.