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

[Alexander Graf]

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.


Alex

> 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