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 8B60DEB64DD for ; Mon, 7 Aug 2023 09:51:09 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=G3aixPxrJA7SNvmFPHv5b8nOKL7HYa7JEJg5bPmffi8=; b=HtahEv7tXlC4IN 344GHn32okUzxbPFkSpHfZBEIyJP8XprPS5o6KX+6fmtRb53+DxSVuHRQlDnsWNZ4F0C6uz74iROE kJVGl+1A83oElAKGrDaTmkysTus4gEw1N337fIiojMChti7z1fYntHuMNpwgb1GmS6WI8x4fQz2zj 0dTfKHLriW6gGEvo3utWvs4gPB2G+MPnwEFGpGvX2tPpRWHGrdcAhxbeyrRfKWHR3joMhpR+GoE6O k06hr4kBsRnMLXW2697jrKuw/8i/ij/I28uo+T1FbUOg+vPO/bKuESCFDWWHBA+rZGXSK+qTIJL/H sKrlY539IKk3SuLSSD4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qSwsr-00Gbp7-2i; Mon, 07 Aug 2023 09:50:41 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qSwsn-00Gbkr-2x for linux-arm-kernel@lists.infradead.org; Mon, 07 Aug 2023 09:50:40 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 990C31FB; Mon, 7 Aug 2023 02:51:13 -0700 (PDT) Received: from FVFF77S0Q05N.cambridge.arm.com (FVFF77S0Q05N.cambridge.arm.com [10.1.32.139]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE1003F59C; Mon, 7 Aug 2023 02:50:27 -0700 (PDT) Date: Mon, 7 Aug 2023 10:50:25 +0100 From: Mark Rutland To: Douglas Anderson , Marc Zyngier Cc: Catalin Marinas , Will Deacon , Sumit Garg , Daniel Thompson , linux-perf-users@vger.kernel.org, ito-yuichi@fujitsu.com, Chen-Yu Tsai , Ard Biesheuvel , Stephen Boyd , Peter Zijlstra , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, kgdb-bugreport@lists.sourceforge.net, Masayoshi Mizuma , "Rafael J . Wysocki" , Lecopzer Chen , Masayoshi Mizuma , linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 1/7] irqchip/gic-v3: Enable support for SGIs to act as NMIs Message-ID: References: <20230601213440.2488667-1-dianders@chromium.org> <20230601143109.v9.1.I1223c11c88937bd0cbd9b086d4ef216985797302@changeid> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230601143109.v9.1.I1223c11c88937bd0cbd9b086d4ef216985797302@changeid> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230807_025038_050413_4308C35B X-CRM114-Status: GOOD ( 30.56 ) 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 Hi Doug, On Thu, Jun 01, 2023 at 02:31:45PM -0700, Douglas Anderson wrote: > From: Sumit Garg > > Add support to handle SGIs as pseudo NMIs. As SGIs or IPIs default to a > special flow handler: handle_percpu_devid_fasteoi_ipi(), so skip NMI > handler update in case of SGIs. I couldn't find handle_percpu_devid_fasteoi_ipi() in mainline, and when researching I found that we changed that in commit: 6abbd6988971aaa6 ("irqchip/gic, gic-v3: Make SGIs use handle_percpu_devid_irq()") ... which was in v5.11, so it looks like this is stale? Since that commit, SGIs are treated the same as PPIs/EPPIs, and use handle_percpu_devid_irq() by default. IIUC handle_percpu_devid_irq() isn't NMI safe, and so to run in an NMI context those should use handle_percpu_devid_fasteoi_nmi(). Marc, does that sound right to you? i.e. SGI NMIs should be handled exactly the same as PPI NMIs, and use handle_percpu_devid_fasteoi_nmi()? I have some comments below assuming that SGI NMIs should use handle_percpu_devid_fasteoi_nmi(). > Also, enable NMI support prior to gic_smp_init() as allocation of SGIs > as IRQs/NMIs happen as part of this routine. This bit looks fine to me. > Signed-off-by: Sumit Garg > Reviewed-by: Masayoshi Mizuma > Tested-by: Chen-Yu Tsai > Signed-off-by: Douglas Anderson > --- > > (no changes since v1) > > drivers/irqchip/irq-gic-v3.c | 29 +++++++++++++++++++++-------- > 1 file changed, 21 insertions(+), 8 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 0c6c1af9a5b7..ed37e02d4c5f 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -525,6 +525,7 @@ static u32 gic_get_ppi_index(struct irq_data *d) > static int gic_irq_nmi_setup(struct irq_data *d) > { > struct irq_desc *desc = irq_to_desc(d->irq); > + u32 idx; > > if (!gic_supports_nmi()) > return -EINVAL; > @@ -542,16 +543,22 @@ static int gic_irq_nmi_setup(struct irq_data *d) > return -EINVAL; > > /* desc lock should already be held */ > - if (gic_irq_in_rdist(d)) { > - u32 idx = gic_get_ppi_index(d); > + switch (get_intid_range(d)) { > + case SGI_RANGE: > + break; > + case PPI_RANGE: > + case EPPI_RANGE: > + idx = gic_get_ppi_index(d); > > /* Setting up PPI as NMI, only switch handler for first NMI */ > if (!refcount_inc_not_zero(&ppi_nmi_refs[idx])) { > refcount_set(&ppi_nmi_refs[idx], 1); > desc->handle_irq = handle_percpu_devid_fasteoi_nmi; > } > - } else { > + break; > + default: > desc->handle_irq = handle_fasteoi_nmi; > + break; > } As above, I reckon this isn't right, and we should treat all rdist interrupts (which are all percpu) the same. I reckon what we should be doing here is make ppi_nmi_refs cover all of the rdist interrupts (e.g. make that rdist_nmi_refs, add a gic_get_rdist_idx() helper), and then here have something like: if (gic_irq_in_rdist(d)) { u32 idx = gic_get_rdist_idx(d); /* * Setting up a percpu interrupt as NMI, only switch handler * for first NMI */ if (!refcount_inc_not_zero(&rdist_nmi_refs[idx])) { refcount_set(&ppi_nmi_refs[idx], 1); desc->handle_irq = handle_percpu_devid_fasteoi_nmi; } } ... as an aside, it'd be nicer if we could switch the handler at request time, as then we wouldn't need the refcount at all, but I couldn't see a good irqchip hook to hang that off, so I don't think that needs to change as a prerequisite. > > gic_irq_set_prio(d, GICD_INT_NMI_PRI); > @@ -562,6 +569,7 @@ static int gic_irq_nmi_setup(struct irq_data *d) > static void gic_irq_nmi_teardown(struct irq_data *d) > { > struct irq_desc *desc = irq_to_desc(d->irq); > + u32 idx; > > if (WARN_ON(!gic_supports_nmi())) > return; > @@ -579,14 +587,20 @@ static void gic_irq_nmi_teardown(struct irq_data *d) > return; > > /* desc lock should already be held */ > - if (gic_irq_in_rdist(d)) { > - u32 idx = gic_get_ppi_index(d); > + switch (get_intid_range(d)) { > + case SGI_RANGE: > + break; > + case PPI_RANGE: > + case EPPI_RANGE: > + idx = gic_get_ppi_index(d); > > /* Tearing down NMI, only switch handler for last NMI */ > if (refcount_dec_and_test(&ppi_nmi_refs[idx])) > desc->handle_irq = handle_percpu_devid_irq; > - } else { > + break; > + default: > desc->handle_irq = handle_fasteoi_irq; > + break; > } Same comments as for gic_irq_nmi_setup() here. > > gic_irq_set_prio(d, GICD_INT_DEF_PRI); > @@ -2001,6 +2015,7 @@ static int __init gic_init_bases(phys_addr_t dist_phys_base, > > gic_dist_init(); > gic_cpu_init(); > + gic_enable_nmi_support(); > gic_smp_init(); > gic_cpu_pm_init(); > > @@ -2013,8 +2028,6 @@ static int __init gic_init_bases(phys_addr_t dist_phys_base, > gicv2m_init(handle, gic_data.domain); > } > > - gic_enable_nmi_support(); > - This bit looks fine to me. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel