On Tue, 17 May 2022 at 07:00, Richard Henderson
<richard.henderson@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.
-/* 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.