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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 756FFC433FE for ; Thu, 10 Nov 2022 07:56:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zTRdRvJYdE8XeBQB6fQu/IAHUHZ2msHkRraneic0BiA=; b=Ool8mKr6XUkp0k 0uV1JNhhX+Asv2RZXCArj9AolO6Y8qOSkBhXa+/ry2fQITcRK2xpovpitcPyARB7HgjZ/NkBHwqDz wy+blM5lIJd8Pr2b2xncrnmUWG0ZoB43jPkKZ04w8nCcwUd0SqFVgynlPOPHbzvMXe4M9XO08gtDx KVRFHdz3RmNAmWziaLbbn0u/adobFMC+ph90LIVk17rYG7fth0Gh0IKlKYN1Z5xrZIKwsjp5hmLX0 dpBBG3SbSu8q8Fmf5iG1HpVDJvAXcPGcGKm+nvKnxn5xbLOYzpPYjfd/bwufeMDtiw/LCdw6JWB7k hepB0SQxSHAbqfUBTZQg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ot2PL-0044Pq-KG; Thu, 10 Nov 2022 07:55:31 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ot2PI-0044PO-JU for linux-arm-kernel@lists.infradead.org; Thu, 10 Nov 2022 07:55:30 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 451CAB820E4; Thu, 10 Nov 2022 07:55:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5552C433D6; Thu, 10 Nov 2022 07:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668066926; bh=zueNbw+jPJTDWHCg8mwDS8nIwETIt+nDl7eJklC7Ipk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mlg3WM6Cn+trZxeUjquZK4DcP8Zfp4sf25FroXLLO0vl2RF5FGJh3Vd19XtxJRsON 6u7Zg/I99FSvcJacwNIsIaGIJ5sE0uxhHfqpwl+iPx3PwVRw9lE24FF17g7S46soVi sboO3SGu1z6+XU05YjofYbw+HWr7MWq5a5NIZvuwdjTj6y8DQtjrfmWAWddIoA4eqM IB2tU0A4Vw2bv4UUvNhNuFvgdzXeG4LvoVYKfDjpy/K8UUfddkNlYrLE7dtW1aMqE3 Bs5XPPUkzCdCLHGA6T/XF34soptCmow2iQlQ6uW7K9+iwEp0CKMAHh/Ux9nH0u2M8N 0NMJdAcnGkvJQ== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ot2PD-00562k-D6; Thu, 10 Nov 2022 07:55:23 +0000 Date: Thu, 10 Nov 2022 07:54:54 +0000 Message-ID: <87o7tfutv5.wl-maz@kernel.org> From: Marc Zyngier To: Mukesh Ojha Cc: , , , Thomas Gleixner , lkml Subject: Re: Query on handling some special Group0 interrupt in Linux In-Reply-To: <8d6f41f6-96ae-2f34-4bc7-58b63bf55159@quicinc.com> References: <86tu38oupr.wl-maz@kernel.org> <8d6f41f6-96ae-2f34-4bc7-58b63bf55159@quicinc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: quic_mojha@quicinc.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221109_235528_959315_EDF4F13E X-CRM114-Status: GOOD ( 43.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 09 Nov 2022 19:57:24 +0000, Mukesh Ojha wrote: > > Hi Marc, > > Thanks for your reply. > > On 11/9/2022 11:50 PM, Marc Zyngier wrote: > > On Wed, 09 Nov 2022 16:20:35 +0000, > > Mukesh Ojha wrote: > >> > >> Hi, > >> > >> I was working on a use case where both el2/el3 are implemented and we > >> have a watchdog interrupt (SPI), which is used for detecting software > >> hangs and cause device reset; If that interrupt's current cpu affinity > >> is on a core, where interrupts are disabled, we won't be able to serve > >> it or if this interrupt comes on a core which has interrupt enabled, > >> calling panic() or with smp_send_stop(), we would not be able > >> to know the call stack of the other cores which is running with > >> interrupt disabled. > >> > >> I was thinking of configuring both a watchdog irq(SPI) and IPI_STOP > >> (SGI) or any reserve IPI as an FIQ. And from the watchdog irq handler, > >> I was thinking of calling panic() which eventually sends IPI_STOP(SGI > >> FIQ) to all the cores. And with this we will able to dump all the core > >> call stack. > >> > >> I am able to achieve this but wanted to know if this is acceptable to > >> the community to support/allow such use cases like above and enable > >> group0 interrupt from GIC for some special use cases. > > > > For a start, we only deal with Group-1 interrupts in Linux. Group-0 > > interrupts are for the firmware, and we really don't want to see them > > (this is consistent with your HW having EL3). > > What is the downside of it we support this ? I see one of the > implementation here. > > https://elixir.bootlin.com/linux/v6.0.7/source/drivers/irqchip/irq-apple-aic.c#L510 You do realise that this system doesn't even have a GIC, and only uses FIQ to represent per-CPU interrupts, right? > > > We also mask IRQ and FIQ at the same time, so this is a non-starter. > This can be taken care if we support this. No. We've made the decision not to treat IRQ and FIQ differently, because FIQ only matters for systems with a single security domain such as VMs or wonky systems such as the above. With that, all systems behave the same and are treated the same, making the rules for interrupt preemption understandable and we don't have to think of IRQ and FIQ racing with each other. > > > > > If you want to be able to deliver an interrupt while the interrupts > > are masked, what you are looking for is the NMI framework, for which > > you can register SPIs as (pseudo-)NMI. > > Yes, kind of NMI. I have already looked into this. Since, in our > system El2 is implemented and each physical interrupt get routed to > hypervisor and later vIrq comes to El1 and each interrupt > enable/disable call exercise pmr register trap can cause latency in > regular run(like multiple VM). Then your hypervisor needs fixing. There is no need to trap accesses to PMR. Also, PMR being per-CPU, there should be no extra overhead depending on the number of VM even if you were trapping PMR (for example to work around broken HW). To sum it up, none of the above makes much sense to me. > Since, some of the use-case could be special like i have mentioned > in my initial mail where such interrupt will be fatal and system will > get reset after that. I am not able to think of any other use case than > this but can this not be considered as one of the feature. Well, we don't add stuff to the kernel based on idle considerations, and what you are describing so far matches 100% the requirement for an NMI-like feature. The architecture has two ways to implement almost-NMIs: interrupt priorities (our current crop of pseudo-NMIs) and the ARMv8.8 FEAT_NMI. The former is already there, and there are patches on the list for the latter. Do we need a third way that only works for odd corner cases and that adds a huge amount of complexity? No, thank you. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel