qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH v5 01/24] target/arm: Handle cpreg registration for missing E


From: Peter Maydell
Subject: Re: [PATCH v5 01/24] target/arm: Handle cpreg registration for missing EL
Date: Fri, 6 May 2022 12:22:24 +0100

On Thu, 5 May 2022 at 20:06, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> More gracefully handle cpregs when EL2 and/or EL3 are missing.
> If the reg is entirely inaccessible, do not register it at all.
> If the reg is for EL2, and EL3 is present but EL2 is not,
> either discard, squash to res0, const, or keep unchanged.
>
> Per rule RJFFP, mark the 4 aarch32 hypervisor access registers
> with ARM_CP_EL3_NO_EL2_KEEP, and mark all of the EL2 address
> translation and tlb invalidation "regs" ARM_CP_EL3_NO_EL2_UNDEF.
> Mark the 2 virtualization processor id regs ARM_CP_EL3_NO_EL2_C_NZ.
>
> This will simplify cpreg registration for conditional arm features.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


> +    /*
> +     * Eliminate registers that are not present because the EL is missing.
> +     * Doing this here makes it easier to put all registers for a given
> +     * feature into the same ARMCPRegInfo array and define them all at once.
> +     */
> +    make_const = false;
> +    if (arm_feature(env, ARM_FEATURE_EL3)) {
> +        /*
> +         * An EL2 register without EL2 but with EL3 is (usually) RES0.
> +         * See rule RJFFP in section D1.1.3 of DDI0487H.a.
> +         */
> +        int min_el = ctz32(r->access) / 2;
> +        if (min_el == 2 && !arm_feature(env, ARM_FEATURE_EL2)) {
> +            if (r->type & ARM_CP_EL3_NO_EL2_UNDEF) {
> +                return;
> +            }
> +            make_const = !(r->type & ARM_CP_EL3_NO_EL2_KEEP);
> +        }
> +    } else {
> +        CPAccessRights max_el = (arm_feature(env, ARM_FEATURE_EL2)
> +                                 ? PL2_RW : PL1_RW);
> +        if ((r->access & max_el) == 0) {
> +            return;
> +        }

I did wonder if we had any cases where an EL1-accessible register
is marked with CP_ALIAS and we are relying on an EL3 register
(not-guest-accessible but still kept in the hashtable CPReg)
to do the migration and reset for it.  But I had a quick look
through and I don't think we do. (We definitely do have cases
where we have an AArch32 CP_ALIAS register that relies on the
AArch64 cpreginfo being in the hash table even when the CPU
doesn't implement AArch64.)

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

thanks
-- PMM



reply via email to

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