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

[Peter Maydell]

On Fri, 22 Mar 2024 at 14:08, Cédric Le Goater <clegoate@redhat.com> wrote:
>
> On 3/20/24 16:00, Peter Maydell wrote:
> > 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.)
>
> Oh that's interesting. Will that introduce an extra level of container
> with multiple machines below ?

No, I don't intend that we should have multiple machines in one
simulation, only that the thing which is "container for all the
machine's devices" shouldn't be a weirdly distinct type from
the SoC "container for devices" devices. What I'm primarily hoping
to remedy by making TYPE_MACHINE a subclass of TYPE_DEVICE to
deal with inconsistencies like:
 * reset of machine objects is nonstandard
 * machine models can't use facilities like having qdev gpio
   lines, so wind up calling qemu_allocate_irqs() directly

None of these are big things, but they're a bit paper-cut-ish.

-- PMM