On Thu, Apr 14, 2011 at 12:55 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: >> > On Tue, 12 Apr 2011 21:31:18 +0300 >> > Blue Swirl <blauwirbel@xxxxxxxxx> wrote: >> > >> >> On Tue, Apr 12, 2011 at 10:52 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: >> >> > On 04/11/2011 08:15 PM, Blue Swirl wrote: >> >> >> >> >> >> On Mon, Apr 11, 2011 at 10:01 AM, Markus Armbruster<armbru@xxxxxxxxxx> >> >> >> Âwrote: >> >> >> > ÂAvi Kivity<avi@xxxxxxxxxx> Â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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
