[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/2 V7] qemu,qmp: add inject-nmi qmp command
Date: Fri, 08 Apr 2011 14:32:14 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 04/08/2011 02:17 PM, Blue Swirl wrote:
On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov<address@hidden>  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<address@hidden>    wrote:

I'd prefer something more generic like these:
raise /address@hidden:l1int
lower /i44FX-pcihost/address@hidden/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


Anthony Liguori



reply via email to

[Prev in Thread] Current Thread [Next in Thread]