suggestions on handling additional exception levels on ppc32

suggestions on handling additional exception levels on ppc32

[Kumar Gala]

I'm looking at fixing an issue parts that have multiple exception  
levels (e300, 40x, booke).

One of the issues is the transfer_to_handler patch in entry_32.S  
doesn't use the proper save/restore registers to transfer to C code.

The following bit of code is what I'm having issues with:

         .globl transfer_to_handler_cont
transfer_to_handler_cont:
3:
         mflr    r9
         lwz     r11,0(r9)               /* virtual address of handler  
*/
         lwz     r9,4(r9)                /* where to go when done */
         mtspr   SPRN_SRR0,r11
         mtspr   SPRN_SRR1,r10
         mtlr    r9
         SYNC
         RFI                             /* jump to handler, enable  
MMU */

A few possibilities:
* introduce an additional function pointer as part of  
EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,  
dbg, mcheck)
* use the traps field low order bits to determine normal, crit, dbg,  
mcheck at run time.
* duplicate the code paths for each exception level

suggestions?

- k

Re: suggestions on handling additional exception levels on ppc32

[Scott Wood]

On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
> A few possibilities:
> * introduce an additional function pointer as part of  
> EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,  
> dbg, mcheck)
> * use the traps field low order bits to determine normal, crit, dbg,  
> mcheck at run time.
> * duplicate the code paths for each exception level
> 
> suggestions?

You could temporarily disable all asynchronous exceptions, and use the
registers of the highest-priority exception type.

-Scott

Re: suggestions on handling additional exception levels on ppc32

[Kumar Gala]

On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
> On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
>> A few possibilities:
>> * introduce an additional function pointer as part of
>> EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
>> dbg, mcheck)
>> * use the traps field low order bits to determine normal, crit, dbg,
>> mcheck at run time.
>> * duplicate the code paths for each exception level
>>
>> suggestions?
>
> You could temporarily disable all asynchronous exceptions, and use the
> registers of the highest-priority exception type.

That doesn't work.  We have NMIs or will have them in the future.

- k

Re: suggestions on handling additional exception levels on ppc32

[Scott Wood]

On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote:
> 
> On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
> >On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
> >>A few possibilities:
> >>* introduce an additional function pointer as part of
> >>EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
> >>dbg, mcheck)
> >>* use the traps field low order bits to determine normal, crit, dbg,
> >>mcheck at run time.
> >>* duplicate the code paths for each exception level
> >>
> >>suggestions?
> >
> >You could temporarily disable all asynchronous exceptions, and use the
> >registers of the highest-priority exception type.
> 
> That doesn't work.  We have NMIs or will have them in the future.

Truly non-maskable?  Ick.  You could have a separate code path just for
the exception type that NMIs use, I guess, if there's a clear
highest-priority among the remaining interrupt types.  What sort of
exceptions are they?

-Scott

Re: suggestions on handling additional exception levels on ppc32

[Kumar Gala]

On Apr 28, 2008, at 12:04 PM, Scott Wood wrote:
> On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote:
>>
>> On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
>>> On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
>>>> A few possibilities:
>>>> * introduce an additional function pointer as part of
>>>> EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
>>>> dbg, mcheck)
>>>> * use the traps field low order bits to determine normal, crit,  
>>>> dbg,
>>>> mcheck at run time.
>>>> * duplicate the code paths for each exception level
>>>>
>>>> suggestions?
>>>
>>> You could temporarily disable all asynchronous exceptions, and use  
>>> the
>>> registers of the highest-priority exception type.
>>
>> That doesn't work.  We have NMIs or will have them in the future.
>
> Truly non-maskable?  Ick.  You could have a separate code path just  
> for
> the exception type that NMIs use, I guess, if there's a clear
> highest-priority among the remaining interrupt types.  What sort of
> exceptions are they?

The NMIs are machine check only so a separate path for them isn't a  
terrible idea.

However, disabling all other interrupts seems worse than adding a  
function pointer.

- k