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

[Alexander Graf <agraf@suse.de>]

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 <peter.maydell@linaro.org>:
>>>
>>>> On 10 June 2014 19:09, Alexander Graf <agraf@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?

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
>>
>