On 1/5/19 2:25 AM, Peter Maydell wrote:
> On Fri, 14 Dec 2018 at 05:24, Richard Henderson
> <[email protected]> wrote:
>>
>> The cryptographic internals are stubbed out for now,
>> but the enable and trap bits are checked.
>>
>> Signed-off-by: Richard Henderson <[email protected]>
>> ----
>
>> +static void QEMU_NORETURN pauth_trap(CPUARMState *env, int target_el,
>> + uintptr_t ra)
>> +{
>> + CPUState *cs = ENV_GET_CPU(env);
>> +
>> + cs->exception_index = EXCP_UDEF;
>> + env->exception.syndrome = syn_pactrap();
>> + env->exception.target_el = target_el;
>> + cpu_loop_exit_restore(cs, ra);
>
> This should use raise_exception(), or some variant on it that
> lets you pass in the ra, because otherwise you lose the
> "redirect EL1 exceptions to EL2" HCR.TGE behaviour.
> Or can we only ever call this for a target_el of 2 or 3?
This particular usage can only ever target EL 2 or 3,
in response to {SCR,HCR}.API being clear. AFAICS that
trap is properly directed already.
But, yes, raise_exception_ra would be useful.
r~
