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 CB5B0D41C04 for ; Wed, 13 Nov 2024 12:34:04 +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=5hsqUm12FEof3+bAs2FTVSQ4hQjnEsVfsz2dBx5ThWA=; b=RFKlc1tqtO0SYdqNC2G6cZ+kSr zjcR6nfkIDfL88Hk1sRRoMiROKHdeWQtI+anMU476BakiBaxnVDb0y6GcqUqsjN3ChqgEkX7Melpr PB0simZyfEIUAyrnJ8hY40QagHQRABbvru7R+58AbENIoJw4RxLoOf9BnlBx1RvJ+pxQiJectSPvb 5koz/AQ43PjhFt5BdqQU838vhPDFjcwD5itlyDLnFaPsOXvTqfNBkD5dsqtsl4yDG5P2Y0Fgkk1HP diX20mD0M6t4pfhABeRMs8Yl2zIFr1wd0lbPbtZD3Eg+Qe5utWx+FjZzArU4QuJpGMGHRBPFvkO47 3tEsIDWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tBCZC-00000006mMu-2zMO; Wed, 13 Nov 2024 12:33:50 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tBCWc-00000006m0j-1aHg for linux-arm-kernel@lists.infradead.org; Wed, 13 Nov 2024 12:31:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 45E875C5940; Wed, 13 Nov 2024 12:30:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F1EBC4CECD; Wed, 13 Nov 2024 12:31:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731501069; bh=ncYZGcwx/3TAZXD29CS4gICiU4uEOyKNClVDiIXWyrQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dK9FbbSFdVexks0CaUF/jsc3+A7q8N0MG0UVemYdqCUxO0Rf75KJUx9DiWSbldoxC aEwPNbl1dh824THUd44lcqXeL/pdiJ59wDl6J3bFqU3a4R+aFQicwjwqqeR5/CahdL +9EAUNtUalQzv+CwfvdHHlLEZZMT3HTZAuHAq4xr8AnlGbS0vl2ycwfQ47kYBKgi/E FnOfen3Zww8zkRDoBVsTCvl1JCOw55qI4zzdZvJ7us1fQhuucj3Pvp+qgh9J8xu0RO jpAmBJ1ePXtOossEzXVjtn776TN81CidYL4hccPCPleTOaXllVY4k6/RWvcZQEYjhw ce2xkxS10yZjA== 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 1tBCWY-00CVWF-Uw; Wed, 13 Nov 2024 12:31:07 +0000 Date: Wed, 13 Nov 2024 12:31:05 +0000 Message-ID: <86h68bz56e.wl-maz@kernel.org> From: Marc Zyngier To: Zhou Wang Cc: , , , , , Nianyao Tang Subject: Re: [PATCH v3] irqchip/gicv3-its: Add workaround for hip09 ITS erratum 162100801 In-Reply-To: <20241113062759.1042187-1-wangzhou1@hisilicon.com> References: <20241113062759.1042187-1-wangzhou1@hisilicon.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/29.4 (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: wangzhou1@hisilicon.com, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, wangwudi@hisilicon.com, prime.zeng@hisilicon.com, tangnianyao@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241113_043110_525614_AC7F7468 X-CRM114-Status: GOOD ( 29.26 ) 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 Wed, 13 Nov 2024 06:27:59 +0000, Zhou Wang wrote: > > When enabling GICv4.1 in hip09, VMAPP will fail to clear some caches > during unmapping operation, which will cause some vSGIs lost. > > To fix the issue, invalidate related vPE cache through GICR_INVALLR > after VMOVP. > > Suggested-by: Marc Zyngier > Signed-off-by: Nianyao Tang > Signed-off-by: Zhou Wang > --- > Documentation/arch/arm64/silicon-errata.rst | 2 + > arch/arm64/Kconfig | 11 ++++ > drivers/irqchip/irq-gic-v3-its.c | 56 +++++++++++++++++---- > 3 files changed, 58 insertions(+), 11 deletions(-) > > diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst > index 65bfab1b1861..77db10e944f0 100644 > --- a/Documentation/arch/arm64/silicon-errata.rst > +++ b/Documentation/arch/arm64/silicon-errata.rst > @@ -258,6 +258,8 @@ stable kernels. > | Hisilicon | Hip{08,09,10,10C| #162001900 | N/A | > | | ,11} SMMU PMCG | | | > +----------------+-----------------+-----------------+-----------------------------+ > +| Hisilicon | Hip09 | #162100801 | HISILICON_ERRATUM_162100801 | > ++----------------+-----------------+-----------------+-----------------------------+ > +----------------+-----------------+-----------------+-----------------------------+ > | Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 | > +----------------+-----------------+-----------------+-----------------------------+ > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 70d7f4f20225..0ea9c599681d 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1232,6 +1232,17 @@ config HISILICON_ERRATUM_161600802 > > If unsure, say Y. > > +config HISILICON_ERRATUM_162100801 > + bool "Hip09 162100801 erratum support" > + default y > + help > + When enabling GICv4.1 in hip09, VMAPP will fail to clear some caches > + during unmapping operation, which will cause some vSGIs lost. > + To fix the issue, invalidate related vPE cache through GICR_INVALLR > + after VMOVP. > + > + If unsure, say Y. > + > config QCOM_FALKOR_ERRATUM_1003 > bool "Falkor E1003: Incorrect translation due to ASID change" > default y > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 52f625e07658..2cd1826b4bbd 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -44,6 +44,7 @@ > #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1) > #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2) > #define ITS_FLAGS_FORCE_NON_SHAREABLE (1ULL << 3) > +#define ITS_FLAGS_WORKAROUND_HISILICON_162100801 (1ULL << 4) > > #define RD_LOCAL_LPI_ENABLED BIT(0) > #define RD_LOCAL_PENDTABLE_PREALLOCATED BIT(1) > @@ -61,6 +62,7 @@ static u32 lpi_id_bits; > #define LPI_PENDBASE_SZ ALIGN(BIT(LPI_NRBITS) / 8, SZ_64K) > > static u8 __ro_after_init lpi_prop_prio; > +static struct its_node *find_4_1_its(void); > > /* > * Collection structure - just an ID, and a redistributor address to > @@ -3797,6 +3799,22 @@ static void its_vpe_db_proxy_move(struct its_vpe *vpe, int from, int to) > raw_spin_unlock_irqrestore(&vpe_proxy.lock, flags); > } > > +static void its_vpe_4_1_invall_locked(int cpu, struct its_vpe *vpe) > +{ > + void __iomem *rdbase; > + u64 val; > + > + val = GICR_INVALLR_V; > + val |= FIELD_PREP(GICR_INVALLR_VPEID, vpe->vpe_id); > + > + raw_spin_lock(&gic_data_rdist_cpu(cpu)->rd_lock); > + rdbase = per_cpu_ptr(gic_rdists->rdist, cpu)->rd_base; > + gic_write_lpir(val, rdbase + GICR_INVALLR); > + > + wait_for_syncr(rdbase); > + raw_spin_unlock(&gic_data_rdist_cpu(cpu)->rd_lock); > +} > + > static int its_vpe_set_affinity(struct irq_data *d, > const struct cpumask *mask_val, > bool force) > @@ -3866,6 +3884,16 @@ static int its_vpe_set_affinity(struct irq_data *d, > vpe->col_idx = cpu; > > its_send_vmovp(vpe); > + > + /* > + * Version of ITS is same in one system. As there is no cache in ITS, > + * and only cache in related GICR should be clean, directly use > + * GICR_INVALLR to clean cache, which will get a better performance > + * here. > + */ I don't think this comment brings much. Maybe better to just drop it. > + if (find_4_1_its()->flags & ITS_FLAGS_WORKAROUND_HISILICON_162100801) > + its_vpe_4_1_invall_locked(cpu, vpe); > + Hold on, this is buggy. On a v4.0 implementation, this is obviously going to explode. You need to check the return value of find_4_1_its() for NULL. Thanks, M. -- Without deviation from the norm, progress is not possible.