[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: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 1/4] cpus: Define NMI callback
Date: Wed, 11 Jun 2014 19:04:41 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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


reply via email to

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