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 C2854CA5FED for ; Tue, 6 Oct 2026 09:39:12 +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=O9HJH+uXkT13MNQK1cMIvKlsgzXLnzAXDk7pgKiWtZY=; b=papaTU6eNNNXLNQiuLUwULr2ZJ AVIor9UQRY+CMnKXHT0s4bWJivai+aZgpjCoSjuLL+kphQyZm3TgmdVj8HGsYhw69R6qy9JWVnqTW o3U7Hj6cJKTjURxuiXttztnYAPvyXoLD5SM3xP2WpuHlRQ+OP+LKEPX21f9vm4v8mqOHt8dmIsiI9 qURnQ6F4vQrpw6NzWsYuh+LrN4HvgmBzHu4h3AUMxvB11GDzsJpVz/D9kRlbEYBIlfa/Lia7+YCDa 6l+GdbHWebB5A0uGjEuypD6OjnmqlOj4GIOs7jdVG0vJYmZn6G3WjnGBNUf1I2I72STsgxdQlprjk ztlFQJdw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xE1dX-00000000Ouo-41Gl; Tue, 06 Oct 2026 09:39:03 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xE1dW-00000000OuP-073y for linux-arm-kernel@lists.infradead.org; Tue, 06 Oct 2026 09:39:02 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 2A2656022A; Tue, 6 Oct 2026 09:39:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2C6F1F000FF; Tue, 6 Oct 2026 09:39:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791279540; bh=O9HJH+uXkT13MNQK1cMIvKlsgzXLnzAXDk7pgKiWtZY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=kDru/Ioz3ij+3dRZx740U4Gb2cGeu3UNTE4DQltvVbtA/ea6TUMkTYu/uB5G+yg9E 3ZUXnlLTdBiCb6+KKvAJwkpdlI1udbxgfiacsddel5nbrfh1hr6XPp9RpRgQaxgLul HnwJHiRPtKNGE9DPC7ZfgIJy8AjOA56x36cOTH5nAdemdgkimQIyOm8HLxeMFijXiM 4QTvldbbnaN3eGZiN6zodlweXqAdhtJzDumYFFt+C6NV3iCqG1scgCmxxNpOfjnDTQ 8FM/zKBxkZ1rZjhEy2RDgXxRpj2kwvkFCC5tR0JgxnTS6Z4gz1NUhVY9FPCblWyUxI H0h68H5qx2qPw== 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 1xE1dS-0000000HMXc-1zsb; Tue, 06 Oct 2026 09:38:58 +0000 Date: Tue, 06 Oct 2026 10:42:06 +0100 Message-ID: <878q4b2mj5.wl-maz@kernel.org> From: Marc Zyngier To: Kohei Enju Cc: Tomohiro Misono , Catalin Marinas , Will Deacon , Mark Rutland , Jonathan Corbet , Shuah Khan , Randy Dunlap , Thomas Gleixner , Radu Rendec , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: Re: [PATCH 4/4] irqchip/gicv3: Add workaround for FUJITSU-MONAKA erratum E#030003 In-Reply-To: References: <20261002-monaka-fix-for-upstream-v1-0-4aec0b0cbe34@fujitsu.com> <20261002-monaka-fix-for-upstream-v1-4-4aec0b0cbe34@fujitsu.com> <86tsn42sqr.wl-maz@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/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: enju.kohei@fujitsu.com, 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, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-perf-users@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-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 Tue, 06 Oct 2026 10:08:19 +0100, Kohei Enju wrote: > > On 10/02 13:26, Marc Zyngier wrote: > > On Fri, 02 Oct 2026 11:26:52 +0100, > > Tomohiro Misono wrote: > > > > > > From: Kohei Enju > > > > > > On affected FUJITSU-MONAKA CPUs, an SGI generated by writing to > > > ICC_SGI0R_EL1, ICC_SGI1R_EL1, or ICC_ASGI1R_EL1 may be lost 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 this occurs, the system > > > register write does not complete, causing the issuing core to hang. > > > > > > > Is the SGI lost? Or is the sender core hanging? > > Both: the SGI is lost, and the sysreg write does not complete, causing > the sending core to hang. I don't think the two are distinguishable. You might want to simplify the commit message to simply say that the CPU hangs. [...] > > > + */ > > > + for_each_cpu(cpu, mask) > > > + gic_send_sgi_via_rdist(cpu, d->hwirq); > > > + > > > + /* Force the above writes to GICR_ISPENDR0 to be executed */ > > > + dsb(st); > > > > This doesn't force things to be executed. This is about completion of > > the access, and with an nGnRE mapping, it doesn't enforce that the > > stores actually reach the RDs, only an arbitrary point in the memory > > subsystem. The only way to guarantee this is to perform a read-back. > > Understood. > > I hadn't considered this when writing v1, but on further reflection, I > don't think gic_ipi_send_mask() needs to wait for the target CPUs to > handle the IPIs. It's not about the target CPU handling the IPI, that'd be crazy. It is about making sure that the IPI request has been observed by the HW and that it is not going to race with something else. > Given that the GICv2 driver does not wait for MMIO > write completion either, I don't think we need to ensure completion of > these writes before returning. GICv2 has different architectural requirements (i.e. none). GICv3 is a bit clearer, see the requirements at the end of 12.1.3 in IHI0069H.b. > > If my understanding is correct, I'll remove the dsb(st) in v2. > As indicated in the spec, you either need nGnRnE+DSB, or a read-back. Given that Linux uses nGnRE for all device mappings, read-back is the only option here. Thanks, M. -- Jazz isn't dead. It just smells funny.