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

[Alexey Kardashevskiy]

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?

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