On 13/06/18 10:57, Thomas Gleixner wrote:
On Wed, 13 Jun 2018, Julien Thierry wrote:
On 13/06/18 10:20, Thomas Gleixner wrote:
Adding NMI delivery support at low level architecture irq chip level is
perfectly fine, but the exposure of that needs to be restricted very
much. Adding it to the generic interrupt control interfaces is not going to
happen. That's doomed to begin with and a complete abuse of the interface
as the handler can not ever be used for that.

Understood, however the need would be to provide a way for a driver to request
an interrupt to be delivered as an NMI (if irqchip supports it).

s/driver/specialized code written by people who know what they are doing/

But from your response this would be out of the question (in the
interrupt/irq/irqchip definitions).

Adding some magic to the irq chip is fine, because that's where the low
level integration needs to be done, but exposing it through the generic
interrupt subsystem is a NONO for obvious reasons.

Or somehow the concerned irqchip informs the arch it supports NMI delivery and
it is up to the interested drivers to query the arch whether NMI delivery is
supported by the system?

Yes, we need some infrastructure for that, but that needs to be separate
and with very limited exposure.

Right, makes sense. I'll check with Marc how such an infrastructure should be introduced.


Julien Thierry

Reply via email to