[PATCH v3] irqchip/gicv3-its: Add workaround for hip09 ITS erratum 162100801
Marc Zyngier
maz at kernel.org
Wed Nov 13 04:31:05 PST 2024
On Wed, 13 Nov 2024 06:27:59 +0000,
Zhou Wang <wangzhou1 at hisilicon.com> 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 <maz at kernel.org>
> Signed-off-by: Nianyao Tang <tangnianyao at huawei.com>
> Signed-off-by: Zhou Wang <wangzhou1 at hisilicon.com>
> ---
> 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.
More information about the linux-arm-kernel
mailing list