PowerPC exceptions: various comments

[Thomas Doerfler]

Hi Till,

wow, that's really..... ingenious!!

I agree completely, that the opcode in question should be uniquely used 
only at that location. Writing r1 to a specific displacement relative to 
r13 in a different situation would require, that:

- Somebody writes his own assembly code
- has r13 moved to a different location (somewhat violating the EABI)
- has at least critical interrupts enabled
- and stores the stack pointer relative to r13

So the chances are really VERY low.

An additional check could be, whether the EE was cleared (in CSRR1), 
when the crtical interrupt was raised, but I think this does not really 
give extra security.

So I agree that this solution is VERY fine.


About my ideas to place a fixed exception prolog table in ROM: We will 
investigate further how such a concept might integrate best into the 
current design and discuss it here again.

wkr,
Thomas.




Till Straumann schrieb:
> Hi Thomas.
> 
> I implemented (and commited) a fix for problem #1 and invite you (and 
> others)
> to comment. The algorithm is now as follows:
> 
> A) first instruction of 'classic' asynchronous exception ('interrupt') 
> sets 'lock' variable:
> 
> async_vector_address:
>    stw r1, ppc_exc_lock_std at sdarel(r13)
>    ...
> 
>    increment _Thread_Dispatch_disable_level
>    ...
>    dispatch 'C' - handler
> 
>    decrement _Thread_Dispatch_disable_level
> 
> B) a critical interrupt handler does the following when decrementing
>   the dispatch-disable level (translated into C code); the code
>   marked /****/ has been added:
> 
>   if ( --_Thread_Dispatch_disable_level == 0 ) {
> 
>      if (    ppc_exc_lock_std == 0 /* lower-priority lock variable not 
> set */
> /*****/   &&  *CSRR0 != opcode_of( 'stw r1, 
> ppc_exc_lock_std at sdarel(r13)' ) {
>          if ( thread_dispatch_necessary )
>             _Thread_Dispatch();
>      }
>   }
> 
>   IMO this should catch the pathological case where a critical
>   interrupt happens just after a non-critical one has loaded
>   the PC with the 'async_vector_address' but before the 'stw r1, ...'
>   instruction had a chance to execute.
>   The critical handler finds 'ppc_exc_lock_std' is still zero
>   but it now also checks the opcode stored at the interrupted
>   PC address (found in the CSRR0 register). If that opcode
>   matches 'stw r1, ppc_exc_lock_std at sdarel(r13)' then the critical
>   handler 'knows' that a non-critical IRQ is already under way
>   and defers thread-dispatching. The opcode in question is
>   unique and not present anywhere else in the code; in particular,
>   it is impossible for the compiler to generate this very instruction
>   from C-code.
> 
> 
> Problem #2 is governed by the 'new-exception handling' API. (My 
> 'middleware'
> does not try to change that API.) It seems to me that the routines
> declared in 'raw_exceptions.h' need a vector table in RAM.
> 
> However, all normal prologues defined by the middleware (except for the
> 603 TGPR prologue) are only 16 bytes hence in principle you could
> have a reasonably small table in RAM (but unfortunately, the API forces
> you to have a copy attached to the configuration table).
> 
> 
> RFC
> -- Till
> 
> 
> 
> Thomas Doerfler wrote:
>> Hello Till,
>>
>> we are currently adapting RTEMS to a MPC55xx microcontroller with a 
>> e200z6 CPU core. We are pleased to see, that you have significantly 
>> cleaned up the PPC exception code and you also already have done lots 
>> of stuff to support the e500 core, which is very similar to the e200.
>>
>> All in all I agree, that your modifications simplify the use of the 
>> PPC vectoring scheme.
>>
>> But we have some topics that should be discussed.
>>
>> 1. Critical Interrupts
>> =======================
>> My colleague Sebastian has tripped over the synchronization you try to 
>> achieve between non-critical and critical interrupts. As far as I 
>> understand, you try to detect the situation, that a critical interrupt 
>> interrupts the prolog code of a non-critical interrupt. For this 
>> purpose, you write the content of r1 to the "lock_bits" flag as the 
>> first opcode in the non-critical interrupt prolog.
>>
>> Unfortunately this will not work reliable. I have discussed the issue 
>> with one of my Freescale contact persons, and he told me that entering 
>> the non-critical interrupt and executing the first opcode is NOT 
>> atomic. So there is still a chance, that
>>
>> - the CPU has saved PC/MSR into SRR0/1
>>
>> - the CPU has modified PC/MSR to execute the non-critical interrupt 
>> prolog
>>
>> - A critical interrupt is raised
>>
>> - the CPU saves PC/MSR into CSRR0/1 and enters the critical interrupt 
>> handler
>>
>> - the critical interrupt handler may issue a thread dispatch when 
>> leaving, and therefore delay the previously raised non-critical 
>> interrupt.
>>
>> As far as I can see, we should postulate, that critical interrupts are 
>> NOT allowed to dispatch tasks. Do you see hard requirements that stand 
>> against this?
>>
>> 2. Interrupt Prolog Placement in ROM
>> ====================================
>>
>> Our target will have 128KByte(!) of internal RAM. In some 
>> applications, this will be the only RAM available, and therefore I am 
>> looking for ways to place the exception prologue code in ROM/Flash 
>> (that's where the rest of the code is located anyway).
>>
>> What I have seen in the current code gives me the impression that the 
>> prologue code is more or less statically initialized. When the current 
>> CPU type has been detected, the corresponding prologue snippets are 
>> copied to the proper vector locations and it is not intended that the 
>> prologue code is replaced when e.g. a debugger agent is attached. 
>> Instead, the agent would connect to the high level handler. Did I get 
>> this right?
>>
>> So my idea would be to alternatively make the macro assembler 
>> duplicate the prologues in proper flavour, quite similar to the 
>> "xxx_vector_categories" tables in raw_exception.c. Many other changes 
>> would be required then (e.g. the relationship between the prologue 
>> address and the vector number will become different again), but it is 
>> at least worth the effort for the MPC55xx, and maybe it would even 
>> make sense for the "big" PPCs, because copying the code to the vector 
>> range is not really necessary in all situations.
>>
>> Before we got further into the details of these plans, I would like to 
>> get your opinion on the whole direction. Be assured, that we would NOT 
>> add conditional assembly and we would NOT copy/paste/modify relevant 
>> code :-)
>>
>> wkr,
>> Thomas.
>>
>>
>>
>>
> 
> 


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.