Re: [Qemu-ppc] [PATCH 2/6] PPC: e500mc: add missing IVORs to bitmap

[Alexander Graf]

On 20.01.2012, at 20:16, Scott Wood wrote:

> On 01/19/2012 09:17 PM, Alexander Graf wrote:
>> E500mc supports IVORs 36-41. Add them to the support mask.
>> 
>> Signed-off-by: Alexander Graf <address@hidden>
>> ---
>> target-ppc/translate_init.c |    6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>> 
>> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
>> index 83348b5..7d1c6a3 100644
>> --- a/target-ppc/translate_init.c
>> +++ b/target-ppc/translate_init.c
>> @@ -4433,6 +4433,7 @@ enum fsl_e500_version {
>> static void init_proc_e500 (CPUPPCState *env, int version)
>> {
>>     uint32_t tlbncfg[2];
>> +    uint64_t ivor_mask = 0x0000000F0000FFFFULL;
>> #if !defined(CONFIG_USER_ONLY)
>>     int i;
>> #endif
>> @@ -4444,7 +4445,10 @@ static void init_proc_e500 (CPUPPCState *env, int 
>> version)
>>      *     complain when accessing them.
>>      * gen_spr_BookE(env, 0x0000000F0000FD7FULL);
>>      */
>> -    gen_spr_BookE(env, 0x0000000F0000FFFFULL);
>> +    if (version == fsl_e500mc) {
>> +        ivor_mask |= 0x3F000000000ULL;
>> +    }
>> +    gen_spr_BookE(env, ivor_mask);
>>     /* Processor identification */
>>     spr_register(env, SPR_BOOKE_PIR, "PIR",
>>                  SPR_NOACCESS, SPR_NOACCESS,
> 
> What happens when we add e5500 and future chips?  We should probably
> move variant-specific data into a table instead of ad-hocking it.

Yup, but I think it makes sense to cross that bridge when we do add e5500 
support, since then we'll actually know how to construct the tables. Today 
things aren't quite clear to me how much of this code we should reuse.

And in fact, a lot of the translate_init.c code is pretty redundant, so maybe 
the actual cleanup should rather be to commonize all of that. Maybe qdev'ify 
the CPUs with supported IVORs becoming simply a qdev property.

> Also, e500mc doesn't just add new IVORs, it drops the SPE IVORs.

Oops. Will fix :)


Alex