qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 01/18] target/arm: Allow raise_exception to handle finding ta


From: Peter Maydell
Subject: Re: [PATCH 01/18] target/arm: Allow raise_exception to handle finding target EL
Date: Mon, 30 May 2022 13:44:47 +0100

On Mon, 23 May 2022 at 21:49, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> The work of finding the correct target EL for an exception is
> currently split between raise_exception and target_exception_el.
> Begin merging these by allowing the input to raise_exception
> to be zero and use exception_target_el for that case.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  target/arm/internals.h | 11 ++++++-----
>  target/arm/op_helper.c | 13 +++++++++----
>  2 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/target/arm/internals.h b/target/arm/internals.h
> index b654bee468..03363b0f32 100644
> --- a/target/arm/internals.h
> +++ b/target/arm/internals.h
> @@ -111,18 +111,19 @@ FIELD(DBGWCR, SSCE, 29, 1)
>  /**
>   * raise_exception: Raise the specified exception.
>   * Raise a guest exception with the specified value, syndrome register
> - * and target exception level. This should be called from helper functions,
> - * and never returns because we will longjump back up to the CPU main loop.
> + * and the current or target exception level. This should be called from
> + * helper functions, and never returns because we will longjump back up
> + * to the CPU main loop.
>   */
>  G_NORETURN void raise_exception(CPUARMState *env, uint32_t excp,
> -                                uint32_t syndrome, uint32_t target_el);
> +                                uint32_t syndrome, uint32_t 
> cur_or_target_el);

"cur_or_target_el" is odd, because it's mixing what the architecture
sets up as two distinct things: the state the exception is
"taken from", and the state the exception is "taken to". I was
hoping this was just a temporary thing for the purposes of the
refactoring and it would go away near the end of the series, but
it doesn't seem to.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]