qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Musta
Subject: Re: [Qemu-ppc] PPC 440 unexpected value in excp_vectors after mtspr
Date: Fri, 05 Sep 2014 08:35:34 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 9/4/2014 5:26 PM, Alexander Graf wrote:
> 
> 
> On 04.09.14 20:41, Tom Musta 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):

[ ... ]

>>
>> 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.
> 
> Same here, I couldn't find any reference to that missing bit in the
> specs for 440, 465 or e500.
> 

The 440 user manual indicates that the bit is implemented (and my recollection 
from Blue Gene is consistent with this).

Likewise, the e500 UM indicates that bit 59 is implemented.  But it has its own 
init code that sets ivor_mask differently, including bit 59 (init_proc_e500() 
in translate_init.c).

Digging further, the line of code in question was introduced with this commit:

commit e1833e1f96456fd8fc17463246fe0b2050e68efb
Author: j_mayer <address@hidden>
Date:   Sat Sep 29 13:06:16 2007 +0000

    Rework PowerPC exceptions model to make it more versatile:
    * don't use exception vectors as the exception number.
      Use vectors numbers as defined in the PowerPC embedded specification 
instead
      and extend this model to cover all emulated PowerPC variants exceptions.
    * add some missing exceptions definitions, from PowerPC 2.04 specification
      and actual PowerPC implementations.
    * add code provision for hypervisor exceptions handling.
    * define exception vectors and prefix in CPUPPCState to emulate BookE 
exception
      vectors without any hacks.
    * define per CPU model valid exception vectors.
    * handle all known exceptions in user-mode only emulations.
    * fix hardware interrupts priorities in most cases.
    * change RET_EXCP macros name into GEN_EXCP as they don't return.
    * do not stop translation on most instructions that are not defined as
      context-synchronizing in PowerPC specification.
    * fix PowerPC 64 jump targets and link register update when in 32 bits mode.
    * Fix PowerPC 464 and 464F definitions.

I double-checked the 2.04 ISA and it says this (Book III-E, section 5.5):

     5. Instruction fetching and execution resumes, using
        the new MSR value, at a location specific to the
        interrupt. The location is

             IVPR0:47 || IVORi48:59 || 0b0000

So I think this is a bug, albeit a very old one.  I am going to post a patch so 
we don't have to have this discussion again 6 months from now :)

> So if it makes things work for you, please send a patch that changes the
> mask :).
> 
> 
> Alex
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]