[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH v3 1/4] cpus: Define NMI callback
Date: Wed, 11 Jun 2014 10:12:54 +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 04:09 AM, Alexander Graf wrote:
> On 06/10/2014 06:29 PM, Paolo Bonzini wrote:
>> Il 10/06/2014 16:48, Luiz Capitulino ha scritto:
>>> > The s390 restart interrupt is a per-vcpu interrupt, which we really
>>> > don't want to inject on _all_ vcpus. OTOH, we want to inject that
>>> > interrupt on any vcpu - we don't care which one it is. So I'd really
>>> > like an "inject nmi on default cpu" option.
>>> We could define a default CPU for the command. What isn't going to work
>>> is to use the human monitor's "current CPU" concept (set with the cpu
>>> command).
>> It isn't going to work, but to me it seems like a bug.  Why was the NMI
>> command even converted to QAPI if it cannot work?  Let's just use
>> monitor_set_cpu from qmp_cpu and call it a day.
>> The amount of churn that Alexey is going through for this feature is
>> unreasonable.
> 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).

Ufff... A button? Any good existing example? A device like hw/input/ps2.c?
And HMP's do_mouse_button()? There are queues, I'll need to fight against

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


reply via email to

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