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: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 10/14] target-arm: Move feature register setup to per-CPU init fns
Date: Mon, 30 Apr 2012 18:48:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

Am 30.04.2012 18:21, schrieb Paul Brook:
>> 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.

You had asked about duplication between ARMCPUClass and ARMCPU, and
there were answers.

Peter has now avoided adding fields to ARMCPUClass in favor of adding
some fields to ARMCPU and multiple initfn functions that spare some
ARMCPUClass -> ARMCPU copying through imperative hardcoding. In
particular that was your request wrt non-declarative feature flags.

There is also a follow-up series by Peter which reworks cp15 as a list
of structs, so touching all cp15 code for cpu-> rather than env-> access
did not seem like a good idea to me.

> Overall I'm not convinced that the new open-coded initialization is better 
> then the tables it replaces.

What I like better after this series is that it's in CPU-specific code
rather than in common code trying to cater to all CPU models based on
CPUID, which includes revision and variant numbers that we would like to
expose as user-tunable QOM properties rather than as different CPU types
where possible.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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