Re: [Qemu-ppc] PPC 440 unexpected value in excp_vectors after mtspr

[Pierre Mallard]

Hi Tom,

Thanks for pointing out ivor_mask.

Since I solved this exception (13) which was due to missing memory region I dont have the use case anymore, and many more thing to fix so I might not be able to test your proposition, I surely will keep it in mind if I find the problem again !

I switched to qemu master branch so maybe I can repost the patch I proposed on hregs for the store_msr thing but I'm still not very skilly with git and patch posting, I will give it a try when I found some time.

Thx for your help

Pierre

On Thu, Sep 4, 2014 at 8:41 PM, Tom Musta <address@hidden> wrote:

On 9/3/2014 6:58 PM, Pierre Mallard wrote:
> Hi guys,
>
> Again a newbee question for exception vectors :
>
> qemu-2.1.0, ppc440, machine virtex_ml507 (slightly modifyed to boot with bios only)
>
> Xilkernel set the exception vector [13] to be 0xd0 by calling :
> mtspr 413 r0, with r0 set to 0xd0
>
> After execution of this instruction, value of env->excp_vector[13] is 0xC0
>
> Unfortunately, code running after gen_mtspr is still very obscure to me, and I can't figure out why env->excp_vector[13] is not set to 0xD0.
>
> Thanks for any help
> Pierre

Pierre:

Here is what I *think* is happening ....

There is a mask (ivor_mask) that controls which bits of the IVORs are actually implemented (this may vary from implementation to implementation).  The "generic" Book E code does this (target-ppc/translate_init.c):

  2769
  2770  static void init_excp_BookE (CPUPPCState *env)
  2771  {
  2772  #if !defined(CONFIG_USER_ONLY)
  2773      env->excp_vectors[POWERPC_EXCP_CRITICAL] = 0x00000000;
  2774      env->excp_vectors[POWERPC_EXCP_MCHECK]   = 0x00000000;
...
  2788      env->excp_vectors[POWERPC_EXCP_DEBUG]    = 0x00000000;
  2789      env->ivor_mask = 0x0000FFE0UL;  /* TAKE NOTE OF THIS LINE */
  2790      env->ivpr_mask = 0xFFFF0000UL;
  2791      /* Hardware reset vector */
  2792      env->hreset_vector = 0xFFFFFFFCUL;
  2793  #endif
  2794  }
  2795

There is another piece of code that masks the GPR bits before placing them into the IVOR (lines 566-568):

   546
   547  static void spr_write_excp_vector (void *opaque, int sprn, int gprn)
   548  {
   549      DisasContext *ctx = opaque;
   550      int sprn_offs;
  ...
   565      TCGv t0 = tcg_temp_new();
   566      tcg_gen_ld_tl(t0, cpu_env, offsetof(CPUPPCState, ivor_mask));
   567      tcg_gen_and_tl(t0, t0, cpu_gpr[gprn]);
   568      tcg_gen_st_tl(t0, cpu_env, offsetof(CPUPPCState, excp_vectors[sprn_offs]));
   569      gen_store_spr(sprn, t0);
   570      tcg_temp_free(t0);
   571  }

Notice that the mask definition excludes the 5th least significant bit ... 0xD0 & 0xFFE0 = 0xC0.

FWIW, I cannot explain why the default IVOR mask is NOT 0xFFF0.  But certainly you can try changing it to see what happens.