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

[Tom Musta]

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.