From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by aws-us-west-2-korg-lkml-1.web.codeaurora.org (Postfix) with ESMTP id 09486C004E4 for ; Wed, 13 Jun 2018 10:06:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BE251208AF for ; Wed, 13 Jun 2018 10:06:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE251208AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935209AbeFMKGd (ORCPT ); Wed, 13 Jun 2018 06:06:33 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:45246 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934226AbeFMKGb (ORCPT ); Wed, 13 Jun 2018 06:06:31 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D1DEC80D; Wed, 13 Jun 2018 03:06:30 -0700 (PDT) Received: from [10.1.206.75] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E1E313F557; Wed, 13 Jun 2018 03:06:26 -0700 (PDT) Subject: Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI To: Thomas Gleixner , Julien Thierry 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 , 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> From: Marc Zyngier Organization: ARM Ltd Message-ID: Date: Wed, 13 Jun 2018 11:06:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. I'm working my way through it ATM now that I have some brain cycles back. > 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. I can only agree with that. Allowing random driver to use request_irq() to make anything an NMI ultimately turns it into a complete mess ("hey, NMI is *faster*, let's use that"), and a potential source of horrible deadlocks. What I'd find more palatable is a way for an irqchip to be able to prioritize some interrupts based on a set of architecturally-defined requirements, and a separate NMI requesting/handling framework that is separate from the IRQ API, as the overall requirements are likely to completely different. It shouldn't have to be nearly as complex as the IRQ API, and require much stricter requirements in terms of what you can do there (flow handling should definitely be different). Thanks, M. -- Jazz is not dead. It just smells funny...