qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 10/14] target-arm: Move feature register setup t


From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH 10/14] target-arm: Move feature register setup to per-CPU init fns
Date: Mon, 30 Apr 2012 17:21:08 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; )

> Move feature register value setup to per-CPU init functions.

> +    env->cp15.c0_c1[0] = cpu->id_pfr0;
> +    env->cp15.c0_c1[1] = cpu->id_pfr1;
> +    env->cp15.c0_c1[2] = cpu->id_dfr0;
> +    env->cp15.c0_c1[3] = cpu->id_afr0;
> +    env->cp15.c0_c1[4] = cpu->id_mmfr0;
> +    env->cp15.c0_c1[5] = cpu->id_mmfr1;
> +    env->cp15.c0_c1[6] = cpu->id_mmfr2;
> +    env->cp15.c0_c1[7] = cpu->id_mmfr3;
> +    env->cp15.c0_c2[0] = cpu->id_isar0;
> +    env->cp15.c0_c2[1] = cpu->id_isar1;
> +    env->cp15.c0_c2[2] = cpu->id_isar2;
> +    env->cp15.c0_c2[3] = cpu->id_isar3;
> +    env->cp15.c0_c2[4] = cpu->id_isar4;
> +    env->cp15.c0_c2[5] = cpu->id_isar5;

Why are we copying these values? All these registers are readonly, so the 
duplication seems wrong.  Shouldn't we should be using cpu->whatever 
everywhere?

I feel like I've asked this before, but don't remember seeing an answer.


Also, I'd prefer that id_isr5 were explicitly initialized, rather than relying 
on it being implicitly zero.  Bugs in an earlier patch series show how easy it 
is to accidentally miss a register.   IMO it's worth distinguishing a defined 
register that happens to be zero from a register this core doesn't have.  
Overall I'm not convinced that the new open-coded initialization is better 
then the tables it replaces.

Paul




reply via email to

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