Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI
From: Julien Thierry
Date: Wed Jun 13 2018 - 05:49:16 EST
On 13/06/18 10:36, Julien Thierry wrote:
On 13/06/18 10:20, Thomas Gleixner wrote:
On Wed, 13 Jun 2018, Julien Thierry wrote:
On 13/06/18 09:34, Peter Zijlstra wrote:
On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 5426627..dbc5e02 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -61,6 +61,8 @@
ÂÂÂ *ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ interrupt handler after suspending interrupts.
For
system
ÂÂÂ *ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ wakeup devices users need to implement wakeup
detection in
ÂÂÂ *ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ their interrupt handlers.
+ * IRQF_DELIVER_AS_NMI - Configure interrupt to be delivered as
non-maskable, if
+ *ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ supported by the chip.
ÂÂÂ */
NAK on the first 6 patches. You really _REALLY_ don't want to expose
NMIs to this level.
I've been working on something similar on arm64 side, and effectively
the one
thing that might be common to arm64 and intel is the interface to set an
interrupt as NMI. So I guess it would be nice to agree on the right
approach
for this.
The way I did it was by introducing a new irq_state and let the
irqchip driver
handle most of the work (if it supports that state):
https://lkml.org/lkml/2018/5/25/181
This has not been ACKed nor NAKed. So I am just asking whether this
is a more
suitable approach, and if not, is there any suggestions on how to do
this?
I really didn't pay attention to that as it's burried in the GIC/ARM
series
which is usually Marc's playground.
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).
But from your response this would be out of the question (in the
interrupt/irq/irqchip definitions).
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?
Actually scratch that last part, it is also missing a way for the driver
to actually communicate to the irqchip that its interrupt should be
treated as an NMI, so it wouldn't work...
--
Julien Thierry