Re: [Qemu-devel] Minimal ARM LPAE support

[Peter Maydell]

On 13 March 2012 11:19, Alexey Starikovskiy <address@hidden> wrote:
> Minimal ARM LPAE support. Sufficient to boot Linux kernel on vexpress-a15

This is missing chunks of what LPAE ought to mean, which is dubious,
and it doesn't state clearly what it is missing, which is definitely
a problem.

> +void HELPER(set_cp15_64)(CPUState *env, uint32_t insn, uint64_t val)
> +{
> +    int crm = insn & 0xf;
> +    int opc1 = (insn >> 4) & 0xf;
> +    if (crm == 2) {
> +        switch (opc1) {
> +        case 0:
> +            env->cp15.c2_base0 = val;
> +            tlb_flush(env, 0); // might change ASID
> +            return;
> +        case 1:
> +            env->cp15.c2_base1 = val;
> +            tlb_flush(env, 0); // might change ASID
> +            return;
> +        default:;
> +        }
> +    } else if (crm == 7) {
> +        if (opc1 == 0) {
> +            env->cp15.c7_par = val;
> +            return;
> +        }
> +    }
> +    cpu_abort(env, "Unimplemented cp15 register 64bit write (c%d[%d])\n",
> crm, opc1);
> +}

This is aiming 64 bit cp15 handling for the same swamp in which
32 bit cp15 is currently stuck. At a bare minimum, this must do
complete decoding of all the crn/crm/opc fields, and must restrict
register implementations to only CPUs where they exist (ie check
ARM_FEATURE_LPAE).

> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -2559,17 +2559,9 @@ static int disas_cp15_insn(CPUState *env,
> DisasContext *s, uint32_t insn)
>
>     /* M profile cores use memory mapped registers instead of cp15.  */
>     if (arm_feature(env, ARM_FEATURE_M))
> -    return 1;
> +        return 1;
>
> -    if ((insn & (1 << 25)) == 0) {
> -        if (insn & (1 << 20)) {
> -            /* mrrc */
> -            return 1;
> -        }
> -        /* mcrr.  Used for block cache operations, so implement as no-op.
>  */

This change seems to drop the MCRR block cache op handling and I don't
see anything elsewhere which implements it. This will presumably break
some CPU/guest combination.

More general question -- should we move target_phys_addr_t to a 64
bit type?

-- PMM