Re: [Qemu-devel] [PATCH 5/9] unicore32-softmmu: initialize ucv2 cpu

["Andreas Färber" <afaerber@suse.de>]

Am 28.05.2012 11:43, schrieb guanxuetao@mprc.pku.edu.cn:
>> Am 25.05.2012 13:29, schrieb Guan Xuetao:
>>> Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
>>> ---
>>>  target-unicore32/cpu.c |   17 +++++++++++++----
>>>  target-unicore32/cpu.h |    2 +-
>>>  2 files changed, 14 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
>>> index de63f58..62c0a22 100644
>>> --- a/target-unicore32/cpu.c
>>> +++ b/target-unicore32/cpu.c
>>> @@ -32,13 +32,16 @@ static void unicore_ii_cpu_initfn(Object *obj)
>>>      UniCore32CPU *cpu = UNICORE32_CPU(obj);
>>>      CPUUniCore32State *env = &cpu->env;
>>>
>>> -    env->cp0.c0_cpuid = 0x40010863;
>>> +    env->cp0.c0_cpuid = UC32_CPUID_UCV2;
>>
>> Please don't revert this change. I'll send you the patch to drop the
>> CPUID #defines instead.
> 
> But, the kernel need this CPUID to check whether it is a unicore32
> processor, and if check fail, the kernel will halt.

I'm not discussing about a guest kernel but about your source change
above: The UC32_CPUID_UC32 #define should go away, i.e. please ack
(today, if we want it in 1.1) and prepend my patch, and if the value is
wrong here it should be changed *here* and not in UC32_CPUID_UCV2.

If you're introducing new uses of UC32_CPUID_UCV2 elsewhere (e.g., for
register behavior) then that is a design fault and needs to be fixed.
Compare the copro series for target-arm, which gets rid of the
CPUID-based switches there.

Andreas

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