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

["Cédric Le Goater" <clegoate@redhat.com>]

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 ?

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

Thanks,

C.