[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 1/4] cpus: Define NMI callback

From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 1/4] cpus: Define NMI callback
Date: Wed, 11 Jun 2014 11:19:51 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 11.06.14 11:04, Alexey Kardashevskiy wrote:
On 06/11/2014 10:28 AM, Alexander Graf wrote:

Am 11.06.2014 um 02:23 schrieb Peter Maydell <address@hidden>:

On 10 June 2014 19:09, Alexander Graf <address@hidden> wrote:
I agree. I see two different paths forward:

  1) Use the patches as they are - they seem pretty sound and take the
existing x86/s390 only feature to spapr
  2) Model an "NMI" button. That button would get instantiated by the
machine model. That would allow the wiring to be defined by the board.
Monitor / QMP would only "press" that button (trigger an edge interrupt?
call a function? something).

I don't mind much either way - option 2 is the architecturally correct way
of doing this. Option 1 probably won't hurt us either.
In an ideal world I'd like (2), ie actually model front panel switches
per machine and with whatever the machine's behaviour actually
is. However pragmatically speaking that's an awful lot of work
(especially since it basically requires adding a lot of U/I which is
always controversial and hard to drive through). I think pragmatism
should probably win here.
Could we just stick a new nmi function callback into the machine class with the 
nmi command calling it?

MachineClass::nmi_monitor_handler()? Or interface?

That's an implementation detail to me - I don't care either way :).

What about x86/s390? Leave them alone? Or implement nmi_monitor_handler()
for them too? I did "grep TYPE_MACHINE", looks like I'll have to implement
TYPE_PC_MACHINE and TYPE_S390_MACHINE (or more), is that correct?

or the button device that implements the interface ;).

Really what I'd like to see eventually is that the "nmi" monitor command just searches for a device labeled "NMI button". That device implements a way (qemu_irq or callback) to trigger the NMI.

In the future when someone who's good at UIs wants to take a stab at it, he could then expose that button via the UI as well.

Anything that goes into that direction is a step into the right direction IMHO.


v1 of this was implementing an interface for a SPAPR machine (like
fw_path_provider) and it was pointed out that CPUClass is the right place.
Now I am _really_ confused :)

That gets us on the right track to the right direction without putting
too much work on Alexey's shoulders. Converting from there to an actual
button object should become reasonably straight forward later.


reply via email to

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