On Sat, 9 Apr 2022 at 01:11, Richard Henderson
<richard.hender...@linaro.org> wrote:
>
> Virtual SError exceptions are raised by setting HCR_EL2.VSE,
> and are routed to EL1 just like other virtual exceptions.
>
> Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
> @@ -10041,6 +10048,20 @@ static void arm_cpu_do_interrupt_aarch32(CPUState
> *cs)
> mask = CPSR_A | CPSR_I | CPSR_F;
> offset = 4;
> break;
> + case EXCP_VSERR:
> + {
> + /* Construct the SError syndrome from AET and ExT fields. */
> + ARMMMUFaultInfo fi = { .type = ARMFault_AsyncExternal, };
> + env->exception.fsr = arm_fi_to_sfsc(&fi);
> + env->exception.fsr |= env->cp15.vsesr_el2 & 0xd000;
> + A32_BANKED_CURRENT_REG_SET(env, dfsr, env->exception.fsr);
> +
> + new_mode = ARM_CPU_MODE_ABT;
> + addr = 0x10;
> + mask = CPSR_A | CPSR_I;
> + offset = 8;
> + }
> + break;
> case EXCP_SMC:
Having looked at the following patch I came back to the AArch32 handling
of taking an SError in this patch...
(1) I think you need to look at TTBCR.EAE in the usual way to
decide whether to report the FSR in long-descriptor or
short-descriptor format
(2) maybe log the FSR value, the way we do for prefetch and
data aborts ?
(3) maybe mention that this is reported like a data abort but that
the DFAR has an unknown value ?
thanks
-- PMM
