From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Thierry Subject: Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI Date: Wed, 13 Jun 2018 11:25:18 +0100 Message-ID: <5c52d916-e405-e689-8fa1-d2dfb28ab3fd@arm.com> References: <1528851463-21140-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1528851463-21140-4-git-send-email-ricardo.neri-calderon@linux.intel.com> <20180613083419.GS12258@hirez.programming.kicks-ass.net> <26687332-ab8f-7f6d-909a-f0918dbfea86@arm.com> <344b838e-81e3-97d8-f90d-315fed7879c1@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Thomas Gleixner Cc: Peter Zijlstra , Ricardo Neri , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Ashok Raj , Borislav Petkov , Tony Luck , "Ravi V. Shankar" , x86@kernel.org, sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Jacob Pan , Daniel Lezcano , Andrew Morton , "Levin, Alexander (Sasha Levin)" , Randy Dunlap , Masami Hiramatsu , Marc Zyngier , Bartosz Golaszewski List-Id: iommu@lists.linux-foundation.org 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. Thanks, -- Julien Thierry From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by lists.ozlabs.org (Postfix) with ESMTP id 415NDl70zNzDr9J for ; Wed, 13 Jun 2018 20:25:25 +1000 (AEST) Subject: Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI To: Thomas Gleixner Cc: Peter Zijlstra , Ricardo Neri , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Ashok Raj , Borislav Petkov , Tony Luck , "Ravi V. Shankar" , x86@kernel.org, sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Jacob Pan , Daniel Lezcano , Andrew Morton , "Levin, Alexander (Sasha Levin)" , Randy Dunlap , Masami Hiramatsu , Marc Zyngier , Bartosz Golaszewski , Doug Berger , Palmer Dabbelt , iommu@lists.linux-foundation.org References: <1528851463-21140-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1528851463-21140-4-git-send-email-ricardo.neri-calderon@linux.intel.com> <20180613083419.GS12258@hirez.programming.kicks-ass.net> <26687332-ab8f-7f6d-909a-f0918dbfea86@arm.com> <344b838e-81e3-97d8-f90d-315fed7879c1@arm.com> From: Julien Thierry Message-ID: <5c52d916-e405-e689-8fa1-d2dfb28ab3fd@arm.com> Date: Wed, 13 Jun 2018 11:25:18 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. Thanks, -- Julien Thierry From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Thierry Date: Wed, 13 Jun 2018 10:25:18 +0000 Subject: Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI Message-Id: <5c52d916-e405-e689-8fa1-d2dfb28ab3fd@arm.com> List-Id: References: <1528851463-21140-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1528851463-21140-4-git-send-email-ricardo.neri-calderon@linux.intel.com> <20180613083419.GS12258@hirez.programming.kicks-ass.net> <26687332-ab8f-7f6d-909a-f0918dbfea86@arm.com> <344b838e-81e3-97d8-f90d-315fed7879c1@arm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Thomas Gleixner Cc: Peter Zijlstra , Ricardo Neri , Ingo Molnar , "H. Peter Anvin" , Andi Kleen , Ashok Raj , Borislav Petkov , Tony Luck , "Ravi V. Shankar" , x86@kernel.org, sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Jacob Pan , Daniel Lezcano , Andrew Morton , "Levin, Alexander (Sasha Levin)" , Randy Dunlap , Masami Hiramatsu , Marc Zyngier , Bartosz Golaszewski 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. Thanks, -- Julien Thierry