mbox series

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

Message ID 20240220150833.13674-1-philmd@linaro.org
Headers show
Series hw/nmi: Remove @cpu_index argument | expand

Message

Philippe Mathieu-Daudé Feb. 20, 2024, 3:08 p.m. UTC
Have s390x always deliver NMI to the first CPU,
remove the @cpu_index argument from handler,
rename API as nmi_trigger() (not monitor specific).

Philippe Mathieu-Daudé (4):
  hw/nmi: Use object_child_foreach_recursive() in nmi_children()
  hw/s390x/virtio-ccw: Always deliver NMI to first CPU
  hw/nmi: Remove @cpu_index argument from NMIClass::nmi_handler()
  hw/nmi: Remove @cpu_index argument from nmi_trigger()

 qapi/run-state.json        |  5 +++--
 include/hw/nmi.h           | 24 ++++++++++++++++++++++--
 hw/core/nmi.c              | 24 +++++++++---------------
 hw/hppa/machine.c          |  8 +++++---
 hw/i386/x86.c              |  7 ++++---
 hw/intc/m68k_irqc.c        |  6 ++++--
 hw/ipmi/ipmi.c             |  3 +--
 hw/m68k/q800-glue.c        |  6 ++++--
 hw/misc/macio/gpio.c       |  6 ++++--
 hw/ppc/pnv.c               |  6 ++++--
 hw/ppc/spapr.c             |  6 ++++--
 hw/s390x/s390-virtio-ccw.c |  8 ++++----
 hw/watchdog/watchdog.c     |  2 +-
 system/cpus.c              |  2 +-
 hmp-commands.hx            |  2 +-
 15 files changed, 71 insertions(+), 44 deletions(-)

Comments

Thomas Huth Feb. 20, 2024, 3:19 p.m. UTC | #1
On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
> Have s390x always deliver NMI to the first CPU,
> remove the @cpu_index argument from handler,
> rename API as nmi_trigger() (not monitor specific).

Could you please add some rationale here why this is needed / desired?

Thanks,
  Thomas


> Philippe Mathieu-Daudé (4):
>    hw/nmi: Use object_child_foreach_recursive() in nmi_children()
>    hw/s390x/virtio-ccw: Always deliver NMI to first CPU
>    hw/nmi: Remove @cpu_index argument from NMIClass::nmi_handler()
>    hw/nmi: Remove @cpu_index argument from nmi_trigger()
> 
>   qapi/run-state.json        |  5 +++--
>   include/hw/nmi.h           | 24 ++++++++++++++++++++++--
>   hw/core/nmi.c              | 24 +++++++++---------------
>   hw/hppa/machine.c          |  8 +++++---
>   hw/i386/x86.c              |  7 ++++---
>   hw/intc/m68k_irqc.c        |  6 ++++--
>   hw/ipmi/ipmi.c             |  3 +--
>   hw/m68k/q800-glue.c        |  6 ++++--
>   hw/misc/macio/gpio.c       |  6 ++++--
>   hw/ppc/pnv.c               |  6 ++++--
>   hw/ppc/spapr.c             |  6 ++++--
>   hw/s390x/s390-virtio-ccw.c |  8 ++++----
>   hw/watchdog/watchdog.c     |  2 +-
>   system/cpus.c              |  2 +-
>   hmp-commands.hx            |  2 +-
>   15 files changed, 71 insertions(+), 44 deletions(-)
>
Philippe Mathieu-Daudé Feb. 20, 2024, 8:05 p.m. UTC | #2
On 20/2/24 16:19, Thomas Huth wrote:
> On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
>> Have s390x always deliver NMI to the first CPU,
>> remove the @cpu_index argument from handler,
>> rename API as nmi_trigger() (not monitor specific).
> 
> Could you please add some rationale here why this is needed / desired?

Heterogeneous machines, a NMI have to reach all NMI-aware HW.

See also "Remove cpu_interrupt() from hw/":
https://lore.kernel.org/qemu-devel/20240220192625.17944-1-philmd@linaro.org/
Philippe Mathieu-Daudé March 20, 2024, 11:19 a.m. UTC | #3
On 20/2/24 16:19, Thomas Huth wrote:
> On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
>> Have s390x always deliver NMI to the first CPU,
>> remove the @cpu_index argument from handler,
>> rename API as nmi_trigger() (not monitor specific).
> 
> Could you please add some rationale here why this is needed / desired?

I'm not sure it is desired... I'm trying to get the NMI delivery
working in heterogeneous machine, but now I'm wondering whether
hw/core/nmi.c was designed with that in mind or likely not.

I suppose in a complex machine you explicitly wire IRQ lines such
NMI, so they are delivered to a particular INTC or CPU core, and
there is no "broadcast this signal to all listeners registered
for NMI events".

> 
> Thanks,
>   Thomas
> 
> 
>> Philippe Mathieu-Daudé (4):
>>    hw/nmi: Use object_child_foreach_recursive() in nmi_children()
>>    hw/s390x/virtio-ccw: Always deliver NMI to first CPU
>>    hw/nmi: Remove @cpu_index argument from NMIClass::nmi_handler()
>>    hw/nmi: Remove @cpu_index argument from nmi_trigger()
Mark Burton March 20, 2024, 11:44 a.m. UTC | #4
> On 20 Mar 2024, at 12:19, Philippe Mathieu-Daudé <philmd@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 20/2/24 16:19, Thomas Huth wrote:
>> On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
>>> Have s390x always deliver NMI to the first CPU,
>>> remove the @cpu_index argument from handler,
>>> rename API as nmi_trigger() (not monitor specific).
>> 
>> Could you please add some rationale here why this is needed / desired?
> 
> I'm not sure it is desired... I'm trying to get the NMI delivery
> working in heterogeneous machine, but now I'm wondering whether
> hw/core/nmi.c was designed with that in mind or likely not.
> 
> I suppose in a complex machine you explicitly wire IRQ lines such
> NMI, so they are delivered to a particular INTC or CPU core, and
> there is no "broadcast this signal to all listeners registered
> for NMI events".
> 

I think those two things are sort of similar. e.g. we could have a machine in which many of the components all receive a ‘reset’ signal, but that would indeed be wired up explicitly from the thing generating that reset signal and all the components wanting to receive it. And, yes, there may be components that are not reset by that signal….

Cheers
Mark.


>> 
>> Thanks,
>>  Thomas
>> 
>> 
>>> Philippe Mathieu-Daudé (4):
>>>   hw/nmi: Use object_child_foreach_recursive() in nmi_children()
>>>   hw/s390x/virtio-ccw: Always deliver NMI to first CPU
>>>   hw/nmi: Remove @cpu_index argument from NMIClass::nmi_handler()
>>>   hw/nmi: Remove @cpu_index argument from nmi_trigger()
>
Peter Maydell March 20, 2024, noon UTC | #5
On Wed, 20 Mar 2024 at 11:20, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> On 20/2/24 16:19, Thomas Huth wrote:
> > On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
> >> Have s390x always deliver NMI to the first CPU,
> >> remove the @cpu_index argument from handler,
> >> rename API as nmi_trigger() (not monitor specific).
> >
> > Could you please add some rationale here why this is needed / desired?
>
> I'm not sure it is desired... I'm trying to get the NMI delivery
> working in heterogeneous machine, but now I'm wondering whether
> hw/core/nmi.c was designed with that in mind or likely not.
>
> I suppose in a complex machine you explicitly wire IRQ lines such
> NMI, so they are delivered to a particular INTC or CPU core, and
> there is no "broadcast this signal to all listeners registered
> for NMI events".

I think in a complex heterogenous machine you do want the
monitor NMI command to do something sensible, but the
definition of "sensible" is going to be machine-specific:
probably it will be "raise NMI in some way on some core in
the main application processor cluster", and it's the machine
model that's going to know what "sensible" is for that machine.

The current hw/core/nmi.c code is a bit odd because it's partly
working with a cpu_index and partly not: the code passes cpu_index
around, but in practice for the QMP command the user can't set
which CPU to operate on, and for everything except s390 the
implementation doesn't care anyway. My impression from the IRC
discussion is that it's not really necessary for the S390 that
the monitor user be able to specify which CPU to NMI (and in any
case you can only do that from the HMP command, not the QMP
command, AIUI), so getting rid of that weird inconsistency makes
sense to me: and that's what this patchset is doing.

What NMI probably ought to be is board-specific: so it's like
having some notional front panel switch labeled "NMI", and the
board gets to decide what that means (which is usually going to be
"send some NMI like interrupt to the first CPU in the main cluster",
but could be something else). It doesn't need to be like a
front panel switch with a rotary-selector for 'pick a CPU'
plus a button for "send NMI to that CPU". In fact we're quite
close to "it's a board thing" already, because almost every
implementation of the TYPE_NMI interface is actually a machine
model. (The exceptions are hw/intc/m68k_irqc.c,
hw/m68k/q800-glue.c and hw/misc/macio/gpio.c.)

So I think that:
 * we should indeed drop the cpu_index stuff, per this patch:
   it's unnecessary cruft we don't really use
 * we should look at whether the three classes listed above
   which implement TYPE_NMI on a non-machine-model are really
   the right way to do that, i.e. whether it would be a lot of
   effort to effectively switch to having nmi_monitor_handler
   be a simple method on MachineClass. Not walking the QOM
   tree would make the NMI infrastructure rather simpler.
   (But I just looked at the macio case, and it's inside a
   PCI device, so at best that's a bunch of clunky plumbing.)
 * failing that, we should look at whether we should really
   continue to walk the whole QOM tree calling methods on every
   TYPE_NMI object, or whether we can say "once we've found one
   implementation we're done". This also depends on those three
   non-MachineClass implementations, because obviously there's
   only ever one MachineClass object in the system. This is
   kind of useful for heterogenous boards which use the m68k
   or ppc devices listed above (seems highly unlikely), but it
   would mean you can override the default "those objects handle
   NMI" by having your heterogenous board implement TYPE_NMI,
   and then since it's earlier in the QOM tree that will be
   the method called, not the ones on specific devices.
   (This one I think we can easily do -- my quick check suggests
   that TYPE_M68K_IRQ is only used in the m68k virt board,
   TYPE_GLUE is only used in the m68k q800 board, and
   TYPE_MACIO_GPIO is only used in the ppc mac99 board. So in
   fact in all cases there's only ever one TYPE_NMI interface
   present in the system.)

The last two aren't blockers for heterogenous-system work,
though: they just seem to me like nice cleanup of this interface.

thanks
-- PMM
Mark Burton March 20, 2024, 12:31 p.m. UTC | #6
> On 20 Mar 2024, at 13: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 11:20, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>> 
>> On 20/2/24 16:19, Thomas Huth wrote:
>>> On 20/02/2024 16.08, Philippe Mathieu-Daudé wrote:
>>>> Have s390x always deliver NMI to the first CPU,
>>>> remove the @cpu_index argument from handler,
>>>> rename API as nmi_trigger() (not monitor specific).
>>> 
>>> Could you please add some rationale here why this is needed / desired?
>> 
>> I'm not sure it is desired... I'm trying to get the NMI delivery
>> working in heterogeneous machine, but now I'm wondering whether
>> hw/core/nmi.c was designed with that in mind or likely not.
>> 
>> I suppose in a complex machine you explicitly wire IRQ lines such
>> NMI, so they are delivered to a particular INTC or CPU core, and
>> there is no "broadcast this signal to all listeners registered
>> for NMI events".
> 
> I think in a complex heterogenous machine you do want the
> monitor NMI command to do something sensible, but the
> definition of "sensible" is going to be machine-specific:
> probably it will be "raise NMI in some way on some core in
> the main application processor cluster", and it's the machine
> model that's going to know what "sensible" is for that machine.
> 
> The current hw/core/nmi.c code is a bit odd because it's partly
> working with a cpu_index and partly not: the code passes cpu_index
> around, but in practice for the QMP command the user can't set
> which CPU to operate on, and for everything except s390 the
> implementation doesn't care anyway. My impression from the IRC
> discussion is that it's not really necessary for the S390 that
> the monitor user be able to specify which CPU to NMI (and in any
> case you can only do that from the HMP command, not the QMP
> command, AIUI), so getting rid of that weird inconsistency makes
> sense to me: and that's what this patchset is doing.
> 
> What NMI probably ought to be is board-specific: so it's like
> having some notional front panel switch labeled "NMI", and the

Do the youngsters of today know what one of those is ?
	:-)


Is there a reason for not using a GPIO interface for ’NMI’ - wiring it up like any other wire?

Cheers
Mark.

> board gets to decide what that means (which is usually going to be
> "send some NMI like interrupt to the first CPU in the main cluster",
> but could be something else). It doesn't need to be like a
> front panel switch with a rotary-selector for 'pick a CPU'
> plus a button for "send NMI to that CPU". In fact we're quite
> close to "it's a board thing" already, because almost every
> implementation of the TYPE_NMI interface is actually a machine
> model. (The exceptions are hw/intc/m68k_irqc.c,
> hw/m68k/q800-glue.c and hw/misc/macio/gpio.c.)
> 
> So I think that:
> * we should indeed drop the cpu_index stuff, per this patch:
>   it's unnecessary cruft we don't really use
> * we should look at whether the three classes listed above
>   which implement TYPE_NMI on a non-machine-model are really
>   the right way to do that, i.e. whether it would be a lot of
>   effort to effectively switch to having nmi_monitor_handler
>   be a simple method on MachineClass. Not walking the QOM
>   tree would make the NMI infrastructure rather simpler.
>   (But I just looked at the macio case, and it's inside a
>   PCI device, so at best that's a bunch of clunky plumbing.)
> * failing that, we should look at whether we should really
>   continue to walk the whole QOM tree calling methods on every
>   TYPE_NMI object, or whether we can say "once we've found one
>   implementation we're done". This also depends on those three
>   non-MachineClass implementations, because obviously there's
>   only ever one MachineClass object in the system. This is
>   kind of useful for heterogenous boards which use the m68k
>   or ppc devices listed above (seems highly unlikely), but it
>   would mean you can override the default "those objects handle
>   NMI" by having your heterogenous board implement TYPE_NMI,
>   and then since it's earlier in the QOM tree that will be
>   the method called, not the ones on specific devices.
>   (This one I think we can easily do -- my quick check suggests
>   that TYPE_M68K_IRQ is only used in the m68k virt board,
>   TYPE_GLUE is only used in the m68k q800 board, and
>   TYPE_MACIO_GPIO is only used in the ppc mac99 board. So in
>   fact in all cases there's only ever one TYPE_NMI interface
>   present in the system.)
> 
> The last two aren't blockers for heterogenous-system work,
> though: they just seem to me like nice cleanup of this interface.
> 
> thanks
> -- PMM
Peter Maydell March 20, 2024, 1:55 p.m. UTC | #7
On Wed, 20 Mar 2024 at 12:31, Mark Burton <mburton@qti.qualcomm.com> wrote:
> > On 20 Mar 2024, at 13:00, Peter Maydell <peter.maydell@linaro.org> wrote:
> > What NMI probably ought to be is board-specific: so it's like
> > having some notional front panel switch labeled "NMI", and the
>
> Do the youngsters of today know what one of those is ?
>         :-)
>
>
> Is there a reason for not using a GPIO interface for ’NMI’ - wiring it up like any other wire?

The places we want to generate 'NMI' are:
 * when the user uses the 'nmi' command in the monitor
 * in the generic "a watchdog timer expired" handling code (in the
   case where the user used a monitor command to say "trigger an NMI
   if the watchdog times out")
 * when the user requested to send the VM an NMI via IPMI

In all those cases we don't have a pointer to the board or
any kind of idea of what a GPIO wire would be, and because at
the moment TYPE_MACHINE is not a subclass of TYPE_DEVICE a
machine model can't have external GPIO lines anyway. From
a convenience point of view all those callsites simply want
to be able to call a function to say "trigger an NMI please"
(which is what nmi_monitor_handle() does). Beyond that the
implementation of that function is just whatever is convenient.

If in your particular machine model it makes sense to have NMI
be something you deal with via GPIO wiring, you can implement the
TYPE_NMI interface on your machine class to work by raising a
GPIO line.

thanks
-- PMM
Mark Burton March 20, 2024, 2:09 p.m. UTC | #8
> On 20 Mar 2024, at 14:55, 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 12:31, Mark Burton <mburton@qti.qualcomm.com> wrote:
>>> On 20 Mar 2024, at 13:00, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> What NMI probably ought to be is board-specific: so it's like
>>> having some notional front panel switch labeled "NMI", and the
>> 
>> Do the youngsters of today know what one of those is ?
>>        :-)
>> 
>> 
>> Is there a reason for not using a GPIO interface for ’NMI’ - wiring it up like any other wire?
> 
> The places we want to generate 'NMI' are:
> * when the user uses the 'nmi' command in the monitor
> * in the generic "a watchdog timer expired" handling code (in the
>   case where the user used a monitor command to say "trigger an NMI
>   if the watchdog times out")
> * when the user requested to send the VM an NMI via IPMI
> 
> In all those cases we don't have a pointer to the board or
> any kind of idea of what a GPIO wire would be, and because at
> the moment TYPE_MACHINE is not a subclass of TYPE_DEVICE a
> machine model can't have external GPIO lines anyway. From
> a convenience point of view all those callsites simply want
> to be able to call a function to say "trigger an NMI please"
> (which is what nmi_monitor_handle() does). Beyond that the
> implementation of that function is just whatever is convenient.
> 
> If in your particular machine model it makes sense to have NMI
> be something you deal with via GPIO wiring, you can implement the
> TYPE_NMI interface on your machine class to work by raising a
> GPIO line.


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). 

Cheers
Mark.


> 
> thanks
> -- PMM
Peter Maydell March 20, 2024, 3 p.m. UTC | #9
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
Mark Burton March 20, 2024, 3:40 p.m. UTC | #10
> 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
Cédric Le Goater March 22, 2024, 2:08 p.m. UTC | #11
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.
Peter Maydell March 22, 2024, 2:55 p.m. UTC | #12
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