On Tue, 17 May 2022 at 07:00, Richard Henderson
<richard.hender...@linaro.org> wrote:
>
> Instead of checking these bits in fp_exception_el and
> also in sve_exception_el, document that we must compare
> the results. The only place where we have not already
> checked that FP EL is zero is in rebuild_hflags_a64.
aarch64_cpu_dump_state() calls sve_exception_el() and doesn't
check against the FP exception EL.
> Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
> ---
> target/arm/helper.c | 52 ++++++++++++++-------------------------------
> 1 file changed, 16 insertions(+), 36 deletions(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index edeab4e473..05baa73986 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -6136,10 +6136,12 @@ static const ARMCPRegInfo minimal_ras_reginfo[] = {
> .access = PL2_RW, .fieldoffset = offsetof(CPUARMState, cp15.vsesr_el2)
> },
> };
>
> -/* Return the exception level to which exceptions should be taken
> - * via SVEAccessTrap. If an exception should be routed through
> - * AArch64.AdvSIMDFPAccessTrap, return 0; fp_exception_el should
> - * take care of raising that exception.
> +/*
> + * Return the exception level to which exceptions should be taken
> + * via SVEAccessTrap. This excludes the check for whether the exception
> + * should be routed through AArch64.AdvSIMDFPAccessTrap. That can easily
> + * be found by testing 0 < fp_exception_el <= sve_exception_el.
> + *
> * C.f. the ARM pseudocode function CheckSVEEnabled.
We should probably note that the pseudocode does *not* separate
out the FP trap checks, but has them all in the same function.
> */
> /*
> - * If SVE is disabled, but FP is enabled,
> - * then the effective len is 0.
> + * If either FP or SVE are disabled, translator does not need len.
> + * If SVE EL >= FP EL, FP exception has precedence, and translator
> + * does not need SVE EL. Save potential re-translations by forcing
> + * the unneeded data to zero.
> */
These comments say that if SVE EL == FP EL then the FP exception
has precedence, but looking at the pseudocode CheckNormalSVEEnabled()
it seems to be the other way around: eg if CPACR_EL1 has
"disabled at EL0" for both the .ZEN bits and the .FPEN bits
then the SVEAccessTrap() is handled first.
thanks
-- PMM
