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

[Mark Burton]

> On 20 Mar 2024, at 14:55, Peter Maydell <peter.maydell@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 Wed, 20 Mar 2024 at 12:31, Mark Burton <mburton@qti.qualcomm.com> wrote:
>>> On 20 Mar 2024, at 13:00, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> What NMI probably ought to be is board-specific: so it's like
>>> having some notional front panel switch labeled "NMI", and the
>> 
>> Do the youngsters of today know what one of those is ?
>>        :-)
>> 
>> 
>> Is there a reason for not using a GPIO interface for ’NMI’ - wiring it up 
>> like any other wire?
> 
> The places we want to generate 'NMI' are:
> * when the user uses the 'nmi' command in the monitor
> * in the generic "a watchdog timer expired" handling code (in the
>   case where the user used a monitor command to say "trigger an NMI
>   if the watchdog times out")
> * when the user requested to send the VM an NMI via IPMI
> 
> In all those cases we don't have a pointer to the board or
> any kind of idea of what a GPIO wire would be, and because at
> the moment TYPE_MACHINE is not a subclass of TYPE_DEVICE a
> machine model can't have external GPIO lines anyway. From
> a convenience point of view all those callsites simply want
> to be able to call a function to say "trigger an NMI please"
> (which is what nmi_monitor_handle() does). Beyond that the
> implementation of that function is just whatever is convenient.
> 
> If in your particular machine model it makes sense to have NMI
> be something you deal with via GPIO wiring, you can implement the
> TYPE_NMI interface on your machine class to work by raising a
> GPIO line.


I’d broaden this to all ’signals’ (IRQ, Reset etc) - and I guess similar 
statements apply, with the “bridge” between the function and the GPIO mechanism 
moved closer or further from the originator(s) of the activity.

The issue isn’t my “machine” model, rather the compose-ability of (any) such 
machine.  A-priori, a model writer doesn’t know if they should respond directly 
to an NMI or not - Hence they dont know if they should implement the TYPE_NMI 
or not. That’s a decision only the machine composer knows.
My suggestion would be to use a GPIO interface to models, which can then be 
appropriately wired. (And, hence, to have a single place that implements the 
TYPE_NMI interface and provides the GPIO wire ready for wiring to appropriate 
devices). 

Cheers
Mark.


> 
> thanks
> -- PMM