target/arm: Report correct syndrome to AArch32 EL2 for trapped Neon/VFP insns

When an AArch32 Neon or VFP insn is trapped to AArch64 EL2, bits [19:0] of the syndrome in ESR_EL2 are RES0. However, when it is trapped to AArch32 EL2, the HSR syndrome information defines some extra fields: [5] : TA [3:0] : coproc where the TA bit is 1 for a trapped Neon insn and 0 for a trapped VFP insn, and the coproc field is 0b1010 when TA is 0, and 0 when TA is 1. We attempted to address this in commit fa33eead ("target/arm: Add coproc parameter to syn_fp_access_trap"), but got it wrong: we thought the RES0 condition was "is v8A" rather than "is EL2 AArch32", and we made all insns be TA=0 coproc = 0b1010 rather than only the VFP ones. Correct the condition we use to decide the coproc and TA fields. We set these fields unconditionally; later on in arm_cpu_do_interrupt_aarch64() we will squash them to zero if we are taking the exception to AArch64. NB: there is some disagreement between different revisions of the Arm ARM about the exact handling of 'coproc': * the v8A Arm ARM text says coproc is 0b1010 when TA is 1 * the v8A Arm ARM pseudocode in AArch32_CheckFPAdvSIMDTrap() sets coproc to 0b1010 when TA is 0 * the v7A Arm ARM text says coproc is 0b1010 when TA is 0 * the v7A Arm ARM pseudocode sets coproc to 0b1010 when TA is 0 The v7A Arm ARM pseudocode also disagrees with the v7A text, v8A text and v8A pseudocode in only setting TA to 1 for traps caused by HCPTR.TASE; the others set Ta for all trapped AdvSIMD insns (i.e. including traps caused by HCPTR.TCP10). We assume that the v8A pseudocode is incorrect about coproc (as it is the odd one out) and that the v7A pseudocode is incorrect about when TA is set (again, as it is the odd one out). Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/1153 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20260702184019.3431139-4-peter.maydell@linaro.org