[PATCH] irqchip/gicv3-its: Clear cache with VINVALL for erratum 162100801

[PATCH] irqchip/gicv3-its: Clear cache with VINVALL for erratum 162100801

[Jinqian Yang]

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.

Fixes: f82e62d470cc ("irqchip/gicv3-its: Add workaround for hip09 ITS erratum 162100801")
Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com>
---
 arch/arm64/Kconfig               |  2 +-
 drivers/irqchip/irq-gic-v3-its.c | 25 +++++++++++--------------
 2 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6663ffd23f25..d4848a8396a9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1268,7 +1268,7 @@ config HISILICON_ERRATUM_162100801
 	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
+	  To fix the issue, invalidate related vPE cache through VINVALL
 	  after VMOVP.
 
 	  If unsure, say Y.
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 467cb78435a9..767ac171e440 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -66,7 +66,6 @@ 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
@@ -1405,6 +1404,14 @@ static void its_send_vmapp(struct its_node *its,
 	its_send_single_vcommand(its, its_build_vmapp_cmd, &desc);
 }
 
+static void its_send_vinvall(struct its_node *its, struct its_vpe *vpe)
+{
+	struct its_cmd_desc desc;
+
+	desc.its_vinvall_cmd.vpe = vpe;
+	its_send_single_vcommand(its, its_build_vinvall_cmd, &desc);
+}
+
 static void its_send_vmovp(struct its_vpe *vpe)
 {
 	struct its_cmd_desc desc = {};
@@ -1442,17 +1449,12 @@ static void its_send_vmovp(struct its_vpe *vpe)
 
 		desc.its_vmovp_cmd.col = &its->collections[col_id];
 		its_send_single_vcommand(its, its_build_vmovp_cmd, &desc);
+		if (is_v4_1(its) && (its->flags &
+			    ITS_FLAGS_WORKAROUND_HISILICON_162100801))
+			its_send_vinvall(its, vpe);
 	}
 }
 
-static void its_send_vinvall(struct its_node *its, struct its_vpe *vpe)
-{
-	struct its_cmd_desc desc;
-
-	desc.its_vinvall_cmd.vpe = vpe;
-	its_send_single_vcommand(its, its_build_vinvall_cmd, &desc);
-}
-
 static void its_send_vinv(struct its_device *dev, u32 event_id)
 {
 	struct its_cmd_desc desc;
@@ -3910,7 +3912,6 @@ static int its_vpe_set_affinity(struct irq_data *d,
 	struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
 	unsigned int from, cpu = nr_cpu_ids;
 	struct cpumask *table_mask;
-	struct its_node *its;
 	unsigned long flags;
 
 	/*
@@ -3974,10 +3975,6 @@ static int its_vpe_set_affinity(struct irq_data *d,
 
 	its_send_vmovp(vpe);
 
-	its = find_4_1_its();
-	if (its && its->flags & ITS_FLAGS_WORKAROUND_HISILICON_162100801)
-		its_vpe_4_1_invall_locked(cpu, vpe);
-
 	its_vpe_db_proxy_move(vpe, from, cpu);
 
 out:
-- 
2.33.0

Re: [PATCH] irqchip/gicv3-its: Clear cache with VINVALL for erratum 162100801

[Marc Zyngier]

On Tue, 21 Oct 2025 14:24:01 +0100,
Jinqian Yang <yangjinqian1@huawei.com> 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.