Messages in this thread | | | Subject | Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI | From | Julien Thierry <> | Date | Wed, 13 Jun 2018 10:49:05 +0100 |
| |
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
| |