From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60304 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8HPt-0003YX-4v for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:32:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8HPo-0003BW-P1 for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:32:25 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:55666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8HPo-0003Ax-97 for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:32:20 -0400 Received: by yib19 with SMTP id 19so1895791yib.4 for ; Fri, 08 Apr 2011 12:32:19 -0700 (PDT) Message-ID: <4D9F62BE.40308@codemonkey.ws> Date: Fri, 08 Apr 2011 14:32:14 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command References: <4D9CAE4B.7080305@siemens.com> <20110406160020.373cb5a2@doriath> <4D9CC044.2000705@codemonkey.ws> <4D9E0352.2050204@codemonkey.ws> <20110407185108.GE7100@redhat.com> <20110407191759.GG7100@redhat.com> <4D9E2F6F.3040008@codemonkey.ws> <20110408060457.GC25354@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Peter Maydell , Lai Jiangshan , Jiangshan , Gleb Natapov , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity , kvm@vger.kernel.org, Luiz Capitulino On 04/08/2011 02:17 PM, 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 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 >