From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command Date: Tue, 3 May 2011 11:01:02 +0100 Message-ID: <20110503100102.GJ5832@shareable.org> References: <4D9CC044.2000705@codemonkey.ws> <4D9E0352.2050204@codemonkey.ws> <20110407185108.GE7100@redhat.com> <20110407191759.GG7100@redhat.com> <4D9E2F6F.3040008@codemonkey.ws> <20110408060457.GC25354@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Gleb Natapov , Peter Maydell , Lai Jiangshan , Jiangshan , kvm@vger.kernel.org, Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity , Luiz Capitulino To: Blue Swirl Return-path: Received: from mail2.shareable.org ([80.68.89.115]:39038 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751757Ab1ECKBG (ORCPT ); Tue, 3 May 2011 06:01:06 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Blue Swirl wrote: > On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov 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 =A0= 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 w= ithout > >> >>lots of changes. > >> >True. The ability to trigger any interrupt line is very useful fo= r > >> >debugging. I often re-implement it during debug. > >> > >> And it's a good thing to have, but exposing this as the only API t= o > >> 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 rar= e > > cases (only preconfigured Windows guests) that it doesn't warrant t= o > > name command as such. Management is in much better position to impl= ement > > functionality with such name since it knows what type of guest it r= uns > > and can tell agent to configure guest accordingly. >=20 > 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. =46or 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. =46or 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