[2/6] PPC: e500mc: add missing IVORs to bitmap

E500mc supports IVORs 36-41. Add them to the support mask.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 target-ppc/translate_init.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

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 <agraf@suse.de>
> ---
>  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.

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

-Scott

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 <agraf@suse.de>
>> ---
>> 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