Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch

[Philippe Gerum <rpm@xenomai.org>]

Benjamin ZORES wrote:
> Philippe Gerum a écrit :
>>> FYI, I'm running on PowerPC 603e core with Linux 2.6.23, Adeos 2.0-09
>>> (latest) and Xenomai 2.3.4 (latest).
>>>     
> read Xenomai 2.4.4 here, of course ...
>>
>> See arch/powerpc/switch_32.S, rthal_switch_threads(), for the part
>> that does the
>> actual stack switching.
>>
>> Note that this code is obfuscated by the fact that we have to handle
>> so-called
>> "hybrid" switching, between Xenomai kernel threads (which do not rely
>> on a
>> task_struct), and Linux tasks (Xenomai userland, Linux kthreads, or
>> regular
>> userland Linux). Fortunately, what is saved on the stack in any case
>> is easy to
>> find out.
>>   
> Ok, I've dig a bit more at sources and found out something strange.
> 
> In xenomai arch/powerpc/xenomai/switch_32.S in rthal_thread_switch() we
> have:
> 
> ********
> #ifdef CONFIG_SMP
>    sync
> #endif /* CONFIG_SMP */
> 
>    lwz    r1,KSP(r4)    /* Load new stack pointer */
> 
>    mr    r3,r2
>    lwz    r0,PGDIR(r4)
>        cmpwi   r0, 0
>        beq-    same_current
> 
>    tophys(r0,r4)
>    CLR_TOP32(r0)
>    mtspr    SPRN_SPRG3,r0    /* Update current THREAD phys addr */
>    addi    r2,r4,-THREAD    /* Update current */
> 
> same_current:
> **********
> 
> While, in arch/powerpc/kernel/entry_32.S in _switch() we have:
> 
> **********
> #ifdef CONFIG_SMP
>    /* We need a sync somewhere here to make sure that if the
>     * previous task gets rescheduled on another CPU, it sees all
>     * stores it has performed on this one.
>     */
>    sync
> #endif /* CONFIG_SMP */
> 
>    tophys(r0,r4)
>    CLR_TOP32(r0)
>    mtspr    SPRN_SPRG3,r0    /* Update current THREAD phys addr */
>    lwz    r1,KSP(r4)    /* Load new stack pointer */
> 
>    /* save the old current 'last' for return value */
>    mr    r3,r2
>    addi    r2,r4,-THREAD    /* Update current */
> ************
> 
> As we can see, the code differs from kernel, as
> 
>    tophys(r0,r4)
>    CLR_TOP32(r0)
>    mtspr    SPRN_SPRG3,r0    /* Update current THREAD phys addr */
> 
> is done _before_ loading new stack pointer in kernel and _after_ doing
> so in xenomai.
> 
> Is there a good reason for that or is this unintended ??
> 

It's just code placement to avoid additional branches depending on whether we
want to update SPRG3 upon switch or not (when switching to a Xenomai kernel
thread, we don't). I see no dependency from that code on the stack pointer and
conversely. Do you see any?

-- 
Philippe.