On 06/11/2014 10:28 AM, Alexander Graf wrote: > > >> Am 11.06.2014 um 02:23 schrieb Peter Maydell <peter.mayd...@linaro.org>: >> >>> On 10 June 2014 19:09, Alexander Graf <ag...@suse.de> 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? 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? 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. > > > Alex > -- Alexey
