qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v3 1/4] cpus: Define NMI callback
Date: Wed, 11 Jun 2014 02:21:35 +0200


> Am 11.06.2014 um 02:12 schrieb Alexey Kardashevskiy <address@hidden>:
> 
>> 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?

I think the closest thing we have today is the system_reset call ;).

> A device like hw/input/ps2.c?
> And HMP's do_mouse_button()? There are queues, I'll need to fight against
> them...

Yeah, nmi is a debug feature. As I said, I don't care all that much. IMHO we 
can just declare that the nmi call runs on vcpu0 always and call it a day.

Alex

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



reply via email to

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