qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [PATCH 0/4] hw/nmi: Remove @cpu_index argument
Date: Wed, 20 Mar 2024 13:55:33 +0000

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



reply via email to

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