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 37CCFCCF2C4 for ; Sat, 17 Oct 2026 12:24:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wi8JAuyO0hOC6x1GjHB6+POlI9OZtGzMwfqaNCzV4YM=; b=x7vRZcLW6k+Fgt9Pe837/BwC84 7QUunoTvmE1AnbM2xXN0p3F/vdpjhWH9ckrigQqBVVLAQ10OXlzEeGka3i1if+jpvdytvbwz7a79b ZrWvthyezbfZ3qJkZT7aLUyRXQKYkVVSb8yt19EDYfOlhRN70VDVqkedrmMe6dBx/zpfw7YrGjYlu J/P9nNW5kj4SKTCdGGLmWnqlAF9Tb588a0klW8nvnVSyUaeY8u8TLVYcyuA8kBegrTVNgBbgcvlU1 j9W6Aez/eEK3iwtnLuagby1LSZLAT94E0WC/F4SXOqkwVex1wA1jBDEh9H2Dx0SUgNd1/6mrJjd8e vH3ljg3A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xI3SP-00000004kdr-1Qi5; Sat, 17 Oct 2026 12:24:13 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xI3SN-00000004kdh-19EP for linux-arm-kernel@lists.infradead.org; Sat, 17 Oct 2026 12:24:11 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B80B943E00; Sat, 17 Oct 2026 12:24:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95EEE1F000C4; Sat, 17 Oct 2026 12:24:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792239849; bh=wi8JAuyO0hOC6x1GjHB6+POlI9OZtGzMwfqaNCzV4YM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Mq40XWY43s/jjXrpkL4Of1aCM+O3gjKOwh8nrilRguUM2IRLv66qI1pszUbqMyiuw eLmkxIe/o2XuutqLoQAj1DGTNHeaSxwvK6fkj1JPV4WQR7V2pEEm2PCPmAAHr06pz9 pA9P94R3QpIs7V5GWiRn3ZzGLW1DLB3WIeCweoc+dWeyffBiF4xUIq66YOnDECLmG9 6N3OfN3cQ4n5sYEnk9sihRQOfYGiyFb0M3fVGsgiE0PKeK/rq4t86HQmn+sM91RbfW K/x45dhBztHhBPkKvUQ7itJpbEmJFC78qHl5A6zOuVGWl9s8fBOJFfkinVQFl38Zsn Q4veWv+9RwWLg== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xI3SJ-000000045T1-02z6; Sat, 17 Oct 2026 12:24:07 +0000 Date: Sat, 17 Oct 2026 13:27:20 +0100 Message-ID: <87wlrg8qc7.wl-maz@kernel.org> From: Marc Zyngier To: Tomohiro Misono Cc: Catalin Marinas , Will Deacon , Mark Rutland , Jonathan Corbet , Shuah Khan , Randy Dunlap , Thomas Gleixner , Radu Rendec , Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Kohei Enju , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-perf-users@vger.kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v2 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003 In-Reply-To: <20261016-monaka-fix-for-upstream-v2-4-fc7ede7f9f48@fujitsu.com> References: <20261016-monaka-fix-for-upstream-v2-0-fc7ede7f9f48@fujitsu.com> <20261016-monaka-fix-for-upstream-v2-4-fc7ede7f9f48@fujitsu.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/30.1 (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: misono.tomohiro@fujitsu.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org, tglx@kernel.org, radu@rendec.net, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, enju.kohei@fujitsu.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-perf-users@vger.kernel.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 16 Oct 2026 11:00:48 +0100, Tomohiro Misono wrote: > > From: Kohei Enju > > On affected FUJITSU-MONAKA CPUs, the erratum may occur when an SGI is > generated by writing to ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1, > if the operation races with CPU interface processing triggered by the > arrival of a higher-priority interrupt, an update to a pending > interrupt, or a transition of the PE to the Sleep state. When the > erratum occurs, the SGI is lost and the system register write does not > complete, causing the issuing core to hang. > > Guest accesses to these registers are not affected by this erratum, as > they are trapped to EL2 and handled without issuing the affected system > register write. > > Work around the erratum by writing 1 to the bit corresponding to the > target SGI INTID in GICR_ISPENDR0 of each target PE's GIC Redistributor, > instead of writing to the affected system registers. > > Accessing a target PE's GICR_ISPENDR0 requires its Redistributor base to > have been discovered. Affected platforms conform to SBBR, which requires > PSCI for secondary CPU boot. They therefore do not use the ACPI Parking > protocol, which sends an IPI before the secondary CPU has initialized > its Redistributor. With PSCI, a secondary CPU discovers its > Redistributor before becoming an IPI target. > > Signed-off-by: Kohei Enju You are posting a patch on behalf of someone else, you need to add your own SoB: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.3-rc7#n448 > --- > Changes in v2: > - Clarify the erratum description and document that virtual accesses are > unaffected. > - Remove the gic_send_sgi_via_rdist() helper. > - Remove the write-count rationale. > - Use the CPU MIDR instead of the SoC ID for filtering. > > Note that I have left the dsb(st) after the GICR_ISPENDR0 writes > unchanged, pending clarification of the required completion point. If > the writes must be observed by a specific component before > gic_ipi_send_mask() returns, I will use the appropriate mechanism to > provide that guarantee. See below. [...] > @@ -1386,6 +1391,17 @@ static void gic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask) > */ > dsb(ishst); > > + if (static_branch_unlikely(&gic_fujitsu_030003_erratum)) { > + for_each_cpu(cpu, mask) { > + void __iomem *base = gic_data_rdist_sgi_base_cpu(cpu); > + > + writel_relaxed(BIT(d->hwirq), base + GICR_ISPENDR0); > + } > + > + dsb(st); What is this DSB achieving? As far as I can tell, not much. The memory type is nGnRE, so DSB doesn't force writes to reach the end-point, and only guarantee ordering that system register SGI generation doesn't provide. So either (a) there is a functional requirement on this HW to have a DSB, and needs to be documented, (b) or there is a need for end-point synchronisation, which needs to be enforced by a read back (knowing that the sysreg doesn't provide this guarantee), and this needs to be documented, (c) or this is completely superfluous and can be dropped Which case are we in? Thanks, M. -- Jazz isn't dead. It just smells funny.