qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 16/22] target/arm: Move s1_is_El0 into S1Translate


From: Peter Maydell
Subject: Re: [PATCH 16/22] target/arm: Move s1_is_El0 into S1Translate
Date: Fri, 10 Feb 2023 13:23:25 +0000

On Tue, 24 Jan 2023 at 00:02, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Instead of passing this to get_phys_addr_lpae, stash it
> in the S1Translate structure.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  target/arm/ptw.c | 21 +++++++--------------
>  1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/target/arm/ptw.c b/target/arm/ptw.c
> index 37f5ff220c..eaa47f6b62 100644
> --- a/target/arm/ptw.c
> +++ b/target/arm/ptw.c
> @@ -22,6 +22,7 @@ typedef struct S1Translate {
>      ARMSecuritySpace in_space;
>      bool in_secure;
>      bool in_debug;
> +    bool in_s1_is_el0;
>      bool out_secure;
>      bool out_rw;
>      bool out_be;
> @@ -33,7 +34,7 @@ typedef struct S1Translate {
>
>  static bool get_phys_addr_lpae(CPUARMState *env, S1Translate *ptw,
>                                 uint64_t address,
> -                               MMUAccessType access_type, bool s1_is_el0,
> +                               MMUAccessType access_type,
>                                 GetPhysAddrResult *result, ARMMMUFaultInfo 
> *fi)
>      __attribute__((nonnull));
>
> @@ -1257,17 +1258,12 @@ static int check_s2_mmu_setup(ARMCPU *cpu, bool 
> is_aa64, uint64_t tcr,
>   * @ptw: Current and next stage parameters for the walk.
>   * @address: virtual address to get physical address for
>   * @access_type: MMU_DATA_LOAD, MMU_DATA_STORE or MMU_INST_FETCH
> - * @s1_is_el0: if @ptw->in_mmu_idx is ARMMMUIdx_Stage2
> - *             (so this is a stage 2 page table walk),
> - *             must be true if this is stage 2 of a stage 1+2
> - *             walk for an EL0 access. If @mmu_idx is anything else,
> - *             @s1_is_el0 is ignored.

This was a useful comment on a boolean whose semantics aren't
totally clear just from the variable name; can we keep it ?

Otherwise
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM



reply via email to

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