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

[Mark Burton]

> On 20 Mar 2024, at 16:00, 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 14:10, Mark Burton <mburton@qti.qualcomm.com> wrote:
>> 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).
> 
> I feel like that's a long way in the future, but my back-of-the-envelope
> design sketch of that is that the TYPE_MACHINE class that's implementing
> the "I am just a container for all the devices that the user has
> specified and wired together" machine would itself implement TYPE_NMI and
> when an NMI came in it would assert a GPIO line that the user could
> wire up, or not wire up, as they chose.
> 

Yeah - makes sense.
Cheers
Mark.



> Right now we can't do that though, because, among other reasons,
> TYPE_MACHINE isn't a TYPE_DEVICE. (I do want to fix that, though:
> I'm hoping it won't be too difficult.)
> 
> thanks
> -- PMM