Re: [PATCH v4 06/48] arm64/sysreg: Update ICC_CR0_EL1 with LINK and LINK_IDLE fields

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing Context Synchronization Event (`isb()`) immediately following writes to `ICC_*_EL1` control registers.
- [High] CONSTRAINED UNPREDICTABLE behavior risk in `GIC CDEOI` system instruction encoding.
--

--- Patch [6]: [PATCH v4 06/48] arm64/sysreg: Update ICC_CR0_EL1 with LINK and LINK_IDLE fields ---
commit 5e4759df2a3d62aee0191d703caed6bd54abb692
Author: Sascha Bischoff <Sascha.Bischoff@arm.com>

arm64/sysreg: Update ICC_CR0_EL1 with LINK and LINK_IDLE fields

These fields have been added to the architecture since this register
was added to the generator, and were hence missing.

> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index 7cb61aca3797f..03f5e1755a633 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -3736,7 +3736,9 @@ Sysreg	ICC_CR0_EL1	3	1	12	0	1
>  Res0	63:39
>  Field	38	PID
>  Field	37:32	IPPT
> -Res0	31:1
> +Res0	31:3
> +Field	2	LINK_IDLE
> +Field	1	LINK
>  Field	0	EN
>  EndSysreg

[Severity: High]
This is a pre-existing issue, but since this patch updates the ICC_CR0_EL1
sysreg definitions, is it possible that context synchronization events are
missing after writes to these control registers?

For example, in drivers/irqchip/irq-gic-v5.c:gicv5_cpu_disable_interrupts(),
SYS_ICC_CR0_EL1 is written without an immediate isb():

drivers/irqchip/irq-gic-v5.c:gicv5_cpu_disable_interrupts() {
	cr0 = FIELD_PREP(ICC_CR0_EL1_EN, 0);
	write_sysreg_s(cr0, SYS_ICC_CR0_EL1);
}

A similar pattern occurs in gicv5_cpu_enable_interrupts(), write_ppi_sysreg_s(),
and gicv5_ppi_priority_init() for registers like SYS_ICC_PCR_EL1, 
SYS_ICC_PPI_SPENDR0_EL1, and SYS_ICC_PPI_PRIORITYR0_EL1. Is there a risk of
operating under a stale pipeline configuration if an ISB does not immediately
follow these writes?

[Severity: High]
This is a pre-existing issue, but while reviewing the GICv5 interactions,
does the CDEOI instruction encoding rely on compiler constraints instead of
hardcoding the required register?

In drivers/irqchip/irq-gic-v5.c:gicv5_handle_irq(), the instruction is
emitted using:

drivers/irqchip/irq-gic-v5.c:gicv5_handle_irq() {
	gic_insn(0, CDEOI);
}

If the compiler allocates a general-purpose register containing 0 instead of
explicitly using XZR (register 31), could this lead to a misencoded system
instruction and CONSTRAINED UNPREDICTABLE behavior?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=6