[okl4-developer] platform-specific work

[Nelson Tam]

Hi Charles,

The following explanation applies for the OKL4 1.5.2 release.

On 06/03/2008, at 10:25 PM, Charles.VANWITTENBERGHE at fr.thalesgroup.com  
wrote:

> I think I'm done with platform-specific macros and bootstrap, but  
> interrupts and exceptions handling stay a little bit unclear to me.
>
> May I ask a small explanation about how OKL4 deals with those stuff  
> and which work as to be done in the code?

When an interrupt occurs, the L4 kernel handles it by sending a  
synchronous IPC to a thread.  The thread that receives the interrupt  
IPC is configured using L4_AssociateInterrupt() [1].  So typically,  
you will have a high-priority thread, running in an event-handling  
loop, that is registered to handle interrupt IPCs.  How the interrupt  
should be handled is, of course, dependent on the interrupt number and  
the platform.

Internally, inside the L4 kernel, the interrupt vectors are set up  
during the architecture-specific initialisation such that they point  
to handle_interrupt(), the function that ends up sending the interrupt  
IPC [2].

When porting to a new platform, I don't think the kernel needs to be  
modified (unless, for example, the number of hardware interrupts is  
different across platforms), but you would need to consider how to  
handle the interrupt IPCs from the user level.

Feel free to ask if you need us to elaborate :)

----

In L4, each thread is associated with an exception-handler thread.   
When a thread causes an exception, the kernel sends a synchronous IPC  
to the faulter's exception-handler.  The exception IPC contains the  
faulting thread's state at the time of exception, including the  
register state.

It is up to the exception-handler to determine what to do with the  
faulting thread.  Typically, the exception-handler has enough  
privileges to do whatever it wants with the faulting thread, including  
killing it, or swapping its register state to execute an error  
handling function, etc.

Like interrupts, exception vectors are also set up during arch- 
specific init time [3].

> For example, I'd like to know where in the kernel my HAL  
> default_exception_handler has to link after having made all the  
> status saving work.


So your default_exception_handler() should do something similar to  
what mips_exception() does towards the end, which is calling  
send_exception_ipc().

Final note: you'll notice that send_exception_ipc() actually sends the  
IPC to the faulting thread's scheduler, for reasons we can't go into  
here.  Suffice to say that when you create a thread using  
L4_ThreadControl(), you should set the exception handler and scheduler  
to the same thread.

I hope this doesn't complicate matters too much ;)  It's not as  
complex as it sounds.

--
(nt)

Nelson Tam
nelson at ok-labs.com

[1] See libs/l4/include/thread.h.  See also iguana/server/src/ 
iguana_server.c:788 for an example of how this is called.

[2] See arch/mips/pistachio/src/intctrl.cc :: init_arch() and  
setup_exception_vectors().  You'll notice that IRQs 0-1 and 7 are  
considered spurious, while IRQs 2-6 will cause an interrupt IPC.

[3] Take a look at init_arch() and setup_exception_vectors() again.   
The default exception handling function in the kernel is  
mips_exception() [4], which ends up calling send_exception_ipc() [5].

[4] See arch/mips/pistachio/src/exception.cc.

[5] There are, ahem, exceptions to this rule.  Some exceptions don't  
make sense to be handled within a thread's context, for example,  
software TLB misses should just be handled by the kernel.  These  
special exceptions handlers are set up in setup_exception_vectors().