lkml.org 
[lkml]   [2018]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI
From
Date


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

\
 
 \ /
  Last update: 2018-06-13 11:49    [W:0.050 / U:0.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site