Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp27801790rwd; Tue, 4 Jul 2023 08:04:20 -0700 (PDT) X-Google-Smtp-Source: APBJJlFVHBOwXTdcDWabS4hKJpIyErEY21syllGRh1fH/9RGrBOXllKRb+wFw62O3EKHBYPq4Y07 X-Received: by 2002:a17:90a:ab0d:b0:263:ba94:b15 with SMTP id m13-20020a17090aab0d00b00263ba940b15mr6599059pjq.4.1688483059773; Tue, 04 Jul 2023 08:04:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688483059; cv=none; d=google.com; s=arc-20160816; b=E/5YzBBkavsMfC1K9RWLCeeuv/S32dXk83656rxm/HmamozNApg1ln+Rm7GPct56fE z2tWLRn8JjB8tzkFA1JTZ904GWaWLuDK0oQTH0OUQI/LKjSqseDtTTs9tA0beuJJFqpi 5pUM+VbFczFX2MSNfQ7TjRbBkI6WG6Hx8U5tb0kWdpXSI6EBbx1i7eWVmquWZoihmOAi TU8Ud95uZ2It8NxAsKmif3web+udObjJMVmj3SH30oXOJKY21pqj4splh4w7QFRQ3YdU mA/30+zKAautneAX871dg3c9LNm1QWjyL0VZYj+Ibq2+A5EvMp+o04/ntK9jVeGMYsAj hu4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=8OYfbpD/tGci4FZpSQn7CKTYFJJh9az+RH98OWQxkWo=; fh=yZUu7xgbZLnxFKA0TXfA2ZUcbBQhgLn3jvXdCAqvcZg=; b=wN1j7SToqa8cpwpsVXq6UFbxFZJg0ryEPn4PeFX1mKGHPJYZFYlbxER4bee2rAhjR0 zCE6g+2BQfRiqLLtZ1p1fG62wHpWLoyQCQ5ordvgzHe6hoMMiYntdPDztcykgyYzcHO5 AKphduRrDt3M409TBQ/yhTDwi7Z+wDPAJYdwNeKKuu514thpwa30C+HWlWGGElBME+0a y+8pzDLIWQK88YYhWVKPxdMeDnr5/bv6y6uAsm+NA/6aqp8vwHRIjnrVLOrGF01ci8cS yv0YuHAR6P1IWw/imxU+6i0XMv4tFS/pUkuMGi1fojCTKTvnmbPDIpt+9dRnrs4vvOwH BgFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=B1dxsGnj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s191-20020a632cc8000000b0055ae2071a32si17863098pgs.611.2023.07.04.08.04.03; Tue, 04 Jul 2023 08:04:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=B1dxsGnj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231608AbjGDOpC (ORCPT + 99 others); Tue, 4 Jul 2023 10:45:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231382AbjGDOo7 (ORCPT ); Tue, 4 Jul 2023 10:44:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29B0B10D3 for ; Tue, 4 Jul 2023 07:44:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 816C1611DB for ; Tue, 4 Jul 2023 14:44:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E14A3C433C7; Tue, 4 Jul 2023 14:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688481892; bh=lxhuBwB0JRbnb5pA0aXShpARIqzZaHCZ0lxC4k4Ng+A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B1dxsGnjE3f9KhDfugOBUuNnqJdOOJgn8GJPek9hQUzRWwQrJRJBwo2Pl5MSpfzeP YgjlY3sAorwyAtvNEMD1LVXKDg3a8xNRIxU2AfRNKZ73JGbGfrNLqVj6mi5ANk6Y/6 kommWkCZTx3j4cddtI9ZC3Ojl6+HJceiIZQLFM2C/3s20P+y+yHnjut0X2jhLC5d6F djf/aFTuX8QMNshBzRS3byLHeOSqrDXWgMx6GF4lp4CWWanhEQ13tmg4a13r9VrgJh 76I5oMStMOPlUZmEMEcKdQ5hso45ehhfuSMVXr0JoKIPBVPyXl/Z/fS9+1mUSIh7rj XeHGmMe9+E5SA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1qGhGs-00ASU6-Eo; Tue, 04 Jul 2023 15:44:50 +0100 Date: Tue, 04 Jul 2023 15:44:50 +0100 Message-ID: <86ttujwxb1.wl-maz@kernel.org> From: Marc Zyngier To: Lorenzo Pieralisi Cc: linux-arm-kernel@lists.infradead.org, Hanks Chen , Cheng-Yuh.Wu@mediatek.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] irqchip/gic-v3: Workaround for GIC-700 erratum 2941627 In-Reply-To: <20230704123436.127449-1-lpieralisi@kernel.org> References: <20230704123436.127449-1-lpieralisi@kernel.org> 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/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: lpieralisi@kernel.org, linux-arm-kernel@lists.infradead.org, hanks.chen@mediatek.com, Cheng-Yuh.Wu@mediatek.com, 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-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Lorenzo, On Tue, 04 Jul 2023 13:34:36 +0100, Lorenzo Pieralisi wrote: > > GIC700 erratum 2941627 may cause GIC-700 missing SPIs wake > requests when SPIs are deactivated while targeting a > sleeping CPU - ie a CPU for which the redistributor: > > GICR_WAKER.ProcessorSleep == 1 > > This runtime situation can happen if an SPI that has been > activated on a core is retargeted to a different core, it > becomes pending and the target core subsequently enters a > power state quiescing the respective redistributor. > > When this situation is hit, the de-activation carried out > on the core that activated the SPI (through either ICC_EOIR1_EL1 > or ICC_DIR_EL1 register writes) does not trigger a wake > requests for the sleeping GIC redistributor even if the SPI > is pending. > > Fix the erratum by de-activating the SPI using the s/Fix/ Work around/ > redistributor GICD_ICACTIVER register if the runtime > conditions require it (ie the IRQ was retargeted between > activation and de-activation). > > Signed-off-by: Lorenzo Pieralisi > Cc: Marc Zyngier > --- > Documentation/arm64/silicon-errata.rst | 3 ++ > drivers/irqchip/irq-gic-v3.c | 71 +++++++++++++++++++++++++- > 2 files changed, 73 insertions(+), 1 deletion(-) > > diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst > index 9e311bc43e05..e77c57a0adf8 100644 > --- a/Documentation/arm64/silicon-errata.rst > +++ b/Documentation/arm64/silicon-errata.rst > @@ -141,6 +141,9 @@ stable kernels. > | ARM | MMU-500 | #841119,826419 | N/A | > +----------------+-----------------+-----------------+-----------------------------+ > +----------------+-----------------+-----------------+-----------------------------+ > +| ARM | GIC-700 | #2941627 | ARM64_ERRATUM_2941627 | > ++----------------+-----------------+-----------------+-----------------------------+ > ++----------------+-----------------+-----------------+-----------------------------+ > | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_845719 | > +----------------+-----------------+-----------------+-----------------------------+ > | Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 | > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index a605aa79435a..a0a9ccf23742 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -68,6 +68,8 @@ struct gic_chip_data { > static void __iomem *t241_dist_base_alias[T241_CHIPS_MAX] __read_mostly; > static DEFINE_STATIC_KEY_FALSE(gic_nvidia_t241_erratum); > > +static DEFINE_STATIC_KEY_FALSE(gic_arm64_2941627_erratum); > + > static struct gic_chip_data gic_data __read_mostly; > static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key); > > @@ -591,10 +593,35 @@ static void gic_irq_nmi_teardown(struct irq_data *d) > gic_irq_set_prio(d, GICD_INT_DEF_PRI); > } > > +static bool gic_arm64_erratum_2941627_needed(struct irq_data *d) > +{ > + if (!static_branch_unlikely(&gic_arm64_2941627_erratum)) > + return false; > + > + /* > + * The workaround is needed if the IRQ is an SPI and > + * the target cpu is different from the one we are > + * executing on. > + */ > + return !((gic_irq_in_rdist(d)) || gic_irq(d) >= 8192 || > + cpumask_equal(irq_data_get_effective_affinity_mask(d), > + cpumask_of(smp_processor_id()))); I dislike this statement for multiple reasons: - it is written as a negation, making it harder than strictly necessary to parse as it is the opposite of the comment above - gic_irq_in_rdist() and gic_irq(d) >= 8192 are two ways of checking the interrupt range -- maybe we should just do that - cpumask_equal() is *slow* if you have more that 64 CPUs, something that is increasingly common -- a better option would be to check whether the current CPU is in the mask or not, which would be enough as we only have a single affinity bit set - smp_processor_id() can check for preemption, which is pointless here, as we're doing things under the irq_desc raw spinlock. I would expect something like: enum gic_intid_range range = get_intid_range(d); return (range == SGI_RANGE || range == ESPI_RANGE) && !cpumask_test_cpu(raw_smp_processor_id(), irq_data_get_effective_affinity_mask(d)); > +} > + > static void gic_eoi_irq(struct irq_data *d) > { > write_gicreg(gic_irq(d), ICC_EOIR1_EL1); > isb(); > + > + if (gic_arm64_erratum_2941627_needed(d)) { > + /* > + * Make sure the GIC stream deactivate packet > + * issued by ICC_EOIR1_EL1 has completed before > + * deactivating through GICD_IACTIVER. > + */ > + dsb(sy); > + gic_poke_irq(d, GICD_ICACTIVER); > + } > } > > static void gic_eoimode1_eoi_irq(struct irq_data *d) > @@ -605,7 +632,11 @@ static void gic_eoimode1_eoi_irq(struct irq_data *d) > */ > if (gic_irq(d) >= 8192 || irqd_is_forwarded_to_vcpu(d)) > return; > - gic_write_dir(gic_irq(d)); > + > + if (!gic_arm64_erratum_2941627_needed(d)) > + gic_write_dir(gic_irq(d)); > + else > + gic_poke_irq(d, GICD_ICACTIVER); > } > > static int gic_set_type(struct irq_data *d, unsigned int type) > @@ -1796,6 +1827,25 @@ static bool gic_enable_quirk_nvidia_t241(void *data) > return true; > } > > +static bool gic_enable_quirk_arm64_2941627(void *data) > +{ > + /* > + * If CPUidle is not enabled the erratum runtime > + * conditions can't be hit, since that requires: > + * > + * - A core entering a deep power state with > + * the associated GIC redistributor asleep > + * and an IRQ active and pending targeted at it > + * - A different core handling the IRQ and > + * related GIC operations at the same time > + */ > + if (!IS_ENABLED(CONFIG_CPU_IDLE)) > + return false; Could this still hit on a system that traps WFI to EL3 and uses this as a way to enter a low-power mode? Thanks, M. -- Without deviation from the norm, progress is not possible.