On Thu, Apr 14, 2011 at 12:55 PM, Daniel P. Berrange <berra...@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 <lcapitul...@redhat.com> >> wrote: >> > On Tue, 12 Apr 2011 21:31:18 +0300 >> > Blue Swirl <blauwir...@gmail.com> wrote: >> > >> >> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <a...@redhat.com> wrote: >> >> > On 04/11/2011 08:15 PM, Blue Swirl wrote: >> >> >> >> >> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<arm...@redhat.com> >> >> >> wrote: >> >> >> > Avi Kivity<a...@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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
