From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E6BD8274B56 for ; Tue, 21 Oct 2025 14:26:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761056776; cv=none; b=OMeFMIUbDHty896rx39a3u2k7y7taJPSDtpnIh713WuumnNXLgWcJUfw2gJQU/+k4izaO5xc6ut5hBB0nYI+jP4ceK1HkYH6ipLtSlwSLFoTqouXO056oqk9rUA1mlJZ1ceM5pOqk16SEkCU+fi26AC/bcoteN/YfiUtJbZBhIc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761056776; c=relaxed/simple; bh=qhBEg4NmsABlAETIyuHhA6FsECdejkHrMhImYu47Nbw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=pwxuB77rofpCWw1sJ/WKTCSN1G/FdwlXlMfoqUUCoAGjzuXTrhicfL34SdSnAbGgowK9twPJELh1lQG9RAWaOJJCa29/mQjX82hOcX/9A+vzEfBvTyGlhVVmYET+hRU3PI4lCRGvIU0E1y4OPwdX2hUz6/EQ8sjAz1PCdCxnVqk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AE+GQhB1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AE+GQhB1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A5D5C4CEF1; Tue, 21 Oct 2025 14:26:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761056775; bh=qhBEg4NmsABlAETIyuHhA6FsECdejkHrMhImYu47Nbw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AE+GQhB1tPMV6COeOaPOKKiAunc3raJCsehjk+OMDvhluYnwV6kdcbwi1G1d4nq/F bz6mfZb7EDsRzMp+T2ihEb/nXcWFHPPWhpI9jos7XOTc/gYWdx4pvjyO0rF99yUkz+ LRkbt8TohcAvz7RLFU/MT9YFamr8fw7qdVC9cJB4UCDuo7GdjkGH1e9XlhPxyapt/Y C8U514JO47DTOVHCUR7tN4TC1Mk5t5F5yWWHcd7OYhgXSEZT3kVd5zMN5ppaX3zhJq Yw68rkF1aOgPDlTiC4TNOP2RISavMgy4kv+W4qIByc9kA0QDB+RZWcX8opMuDce1VE p8J2eiIPLVd3g== 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.98.2) (envelope-from ) id 1vBDJV-0000000FsFY-0l3s; Tue, 21 Oct 2025 14:26:13 +0000 Date: Tue, 21 Oct 2025 15:26:12 +0100 Message-ID: <86cy6gwcu3.wl-maz@kernel.org> From: Marc Zyngier To: Jinqian Yang Cc: , , , , , , , , , Subject: Re: [PATCH] irqchip/gicv3-its: Clear cache with VINVALL for erratum 162100801 In-Reply-To: <20251021132401.3570140-1-yangjinqian1@huawei.com> References: <20251021132401.3570140-1-yangjinqian1@huawei.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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: yangjinqian1@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, yuzenghui@huawei.com, wangzhou1@hisilicon.com, jiangkunkun@huawei.com, tangnianyao@huawei.com, wangwudi@hisilicon.com, liuyonglong@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 21 Oct 2025 14:24:01 +0100, Jinqian Yang wrote: > > Use VINVALL to clear cache after VMOVP operation to avoid incomplete > cache cleanup. The previous implementation only cleared cache on one > ITS. This change sends VINVALL to every ITS to properly clear caches. This isn't the same thing. Why is that a better option? Also, VINVALL is broadcast to the RDs. Why does it need to be sent to each and every ITS? If GICR_INVALL, does GICR_INVLPIR work? Does anything work at all on this implementation? I'm getting very tired of this constant churn on all of your GIC implementations that are totally unable to correctly deliver vLPIs and vSGIs without either a deadlock or some corruption. At this stage, you should simply disable GICv4 on your HW and stick top something that actually works. This should give you the time to build HW that actually works. Thanks, M. -- Without deviation from the norm, progress is not possible.