[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: Cédric Le Goater
Subject: Re: [PATCH 0/4] hw/nmi: Remove @cpu_index argument
Date: Fri, 22 Mar 2024 15:08:09 +0100
User-agent: Mozilla Thunderbird

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 ?

    /peripheral (container)
    /peripheral-anon (container)
    /peripheral (container)
    /peripheral-anon (container)
  /unattached (container)
    /sysbus (System)
    /system[0] (memory-region)



reply via email to

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