Re: [Qemu-ppc] PPC 440 : Endless loop executing "mtmsr r3" with r3 set to 0x10

[Tom Musta]

On 9/3/2014 8:05 AM, Pierre Mallard wrote:
> Hi,
> 
> I'm using qemu-2.1.0 on a ppc440 target trying to run xilkernel v5.01.a on it.
> This is definitely a newbee question but I'm a bit confused on what could be 
> causing this behavior :
> 
> Interrupt function set in xilkernel such as critical_irq, kernel_irq and 
> non_critical_irq, have this piece of code as function header :
> 
> mtsprg  0,r3
> ori         r3,16,r3
> mtmsr   r3
> 
> From what I understand it raises level of instruction and data to pass in 
> system mode (r3 is 0x10).

The code sequence sets MSR[DS] = 1.  On the 440, this means that must be TLBs 
established with TS=1 in order to support data access.  If no such TLB exists, 
the expected behavior would be a Data TLB Error interrupt (IVOR13).
> 
> The problem is that at each time the last instruction is reached (mtmsr r3), 
> pc jump automatically to IVOR12 which appears to be the Watch Dog Interrupt 
> if I understand clearly.

When you say "automatically", do you also mean "immediately?"  I.e., is the 
instruction following the msr ever executed?  If not, and if that instruction 
is not a load/store, then this sounds like a QEMU bug.
> 
> Since IVOR12 calls critical_irq, which in turn execute the piece of code 
> shown above, the system enters a endless loop instead of executing interrupt 
> handler instruction :
> 
> kernel_irq => ... mtmsr r3 => IVOR12 => ... b critical_irq => 
> critical_irq => ... mtmsr r3 => IVOR12 => ... b critical_irq
> ...
> 
> Can anyone give me a clue on what is going on here and what do I do wrong ?
> 

Reading the code for mtmsr (target-ppc/excp_helper.c), I see this:

void helper_store_msr(CPUPPCState *env, target_ulong val)
{
    CPUState *cs;

    val = hreg_store_msr(env, val, 0);
    if (val != 0) {
        cs = CPU(ppc_env_get_cpu(env));
        cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
        helper_raise_exception(env, val); // <<<<<<<<<<<<<<<<<<<<
    }
}

The "val" argument is the contents of the GPR being written into the MSR and 
thus is the value 0x10 in this specific case.  The highlighted line looks 
strange to me -- the helper_raise_exception() routine typically takes an 
exception mnemonic as an
argument ... not an arbitary 64 bit value.  In fact, I'm not sure that I know 
what specifically the line of code is trying to do.


> Thanks a lot for your advice,
> Pierre
> 
>