Re: [PATCH 13/16] target/arm: Implement virtual SError exceptions

[Peter Maydell]

On Sat, 9 Apr 2022 at 01:11, Richard Henderson
<richard.henderson@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.henderson@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