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

[Peter Maydell]

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.

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