Buggy branch in __init_el2_gicv3?

[Mark Rutland]

On Mon, Feb 14, 2022 at 12:34:12PM +0000, Joakim Tjernlund wrote:
> In init_el2_state calls __init_el2_gicv3 which looks:
> 
> /* GICv3 system register access */
> .macro __init_el2_gicv3
> 	mrs	x0, id_aa64pfr0_el1
> 	ubfx	x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
> 	cbz	x0, .Lskip_gicv3_\@
> 
> 	mrs_s	x0, SYS_ICC_SRE_EL2
> 	orr	x0, x0, #ICC_SRE_EL2_SRE	// Set ICC_SRE_EL2.SRE==1
> 	orr	x0, x0, #ICC_SRE_EL2_ENABLE	// Set ICC_SRE_EL2.Enable==1
> 	msr_s	SYS_ICC_SRE_EL2, x0
> 	isb					// Make sure SRE is now set
> 	mrs_s	x0, SYS_ICC_SRE_EL2		// Read SRE back,
> 	tbz     x0, #0, 1f
> //	tbz	x0, #0, .Lskip_gicv3_\@		// and check that it sticks
> 	msr_s	SYS_ICH_HCR_EL2, xzr		// Reset ICC_HCR_EL2 to defaults
> .Lskip_gicv3_\@:
> .endm
> 
> Note the tbz     x0, #0, 1f, this instruction causes my A53 CPU to jump far out of the macro and make the
> CPU go into EL0, failing with an exception a bit later. I believe the 1f is a bug and if I replace it with
>  tbz	x0, #0, .Lskip_gicv3_\@
> the CPU continue too boot.

You're right, that should be targetting `.Lskip_gicv3_\@`. It looks like that
was left behind in commit:

  114945d84a30a5fe ("arm64: Fix labels in el2_setup macros")

Marc?

> Why this is trigged is still a mystery to me, any pointers welcome :)

I believe this happens if EL3 has ICC_SRE_EL3.SRE == 0b0; in that case
ICC_SRE_EL2.SRE is RAZ/WI. i.e. your EL3 firmware isn't using GICv3 and hasn't
enabled it for lower ELs.

Thanks,
Mark.