[Top][All Lists]

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

Re: [PATCH 0/4] hw/nmi: Remove @cpu_index argument

From: Mark Burton
Subject: Re: [PATCH 0/4] hw/nmi: Remove @cpu_index argument
Date: Wed, 20 Mar 2024 11:44:56 +0000

> On 20 Mar 2024, at 12:19, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> WARNING: This email originated from outside of Qualcomm. Please be wary of 
> any links or attachments, and do not enable macros.
> On 20/2/24 16:19, Thomas Huth wrote:
>> On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
>>> Have s390x always deliver NMI to the first CPU,
>>> remove the @cpu_index argument from handler,
>>> rename API as nmi_trigger() (not monitor specific).
>> Could you please add some rationale here why this is needed / desired?
> I'm not sure it is desired... I'm trying to get the NMI delivery
> working in heterogeneous machine, but now I'm wondering whether
> hw/core/nmi.c was designed with that in mind or likely not.
> I suppose in a complex machine you explicitly wire IRQ lines such
> NMI, so they are delivered to a particular INTC or CPU core, and
> there is no "broadcast this signal to all listeners registered
> for NMI events".

I think those two things are sort of similar. e.g. we could have a machine in 
which many of the components all receive a ‘reset’ signal, but that would 
indeed be wired up explicitly from the thing generating that reset signal and 
all the components wanting to receive it. And, yes, there may be components 
that are not reset by that signal….


>> Thanks,
>>  Thomas
>>> Philippe Mathieu-Daudé (4):
>>>   hw/nmi: Use object_child_foreach_recursive() in nmi_children()
>>>   hw/s390x/virtio-ccw: Always deliver NMI to first CPU
>>>   hw/nmi: Remove @cpu_index argument from NMIClass::nmi_handler()
>>>   hw/nmi: Remove @cpu_index argument from nmi_trigger()

reply via email to

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