[okl4-developer] pagefault

[Frank Kaiser]

> -----Original Message-----
> From: Geoffrey Lee [mailto:glee at ok-labs.com]
> Sent: Thursday, July 24, 2008 3:43 AM
> To: Frank Kaiser
> Cc: developer at okl4.org
> Subject: Re: [okl4-developer] pagefault
> 
> On Wed, Jul 23, 2008 at 05:22:43PM +0200, Frank Kaiser wrote:
> > Hi, Geoffrey
> >
> > We have identified a reentrancy problem in our interrupt handler
code,
> > and it has something to do with the CONTINUATION scheme. The easiest
> > solution would be just not using it, but I think some of the kernel
> > functions called by the interrupt handler cannot afford receiving
NULL
> > as value of parameter 'cont'.
> > I have to find a way to concurrently maintain the interrupt
handler's
> > return address for each nested interrupt (up to 8 are theretically
> > possible).
> 
> 
> Hi Frank - thanks for keeping us posted on the latest developments.
> 
> The continuation defines the retart point if a thread gets switched
away
> to another thread so it's important to define a continuation so
> you can be restarted once the thread can run again.
> 
> >
> > Regards
> > Frank
> 
> 	-gl
Hello, Geoffrey

I cannot fully follow your explanation about the CONTINUATION function.
This is the definiton of the macro ACTIVATE_CONTINUATION() for the ARM
architecture in 'tcb.h':
#define ACTIVATE_CONTINUATION(continuation)     \
    do {                \
        __asm__ __volatile__ (
\
                "       orr     sp,     sp,     %1              \n"
\
                "       mov     pc,     %0                      \n"
\
                :
\
                : "r" ((word_t)(continuation)),
\
                  "i" (STACK_TOP)
\
                : "sp", "memory"
\
                );
\
        while(1);
\
    } while(false)
The two while loops have no effect, only the two ASM instruction count.
- The first instruction is a stack manipulation.
- The second instruction is a jump to the addres given by parameter
'continuation'.
My point is the stack manipulation. The value of the constant STACK_TOP
is defined in 'arch/arm/pistachio/include/config.h' and has the value
0x3F8 (STACK_SIZE-8). Since the stack pointer is manipulated in 4 bytes
steps, the result of the OR operation will leave the low ten bits of SP
either 0x3F8 or 0x3FC which is near the top of the current stack
provided that all stacks are adjusted to a 1k boundary. The dubious
thing is that one does not always get the same stack value once the
macro has been executed: possibly that does not matter, because both
pattern result in a stack pointer value within the defined memory range.
Effectively this macro destroys the current stack contest (be it the
kernel or a user thread) and passes control to a piece of code which is
assumed to run on the top level of a thread/kernel context (equivalent
to the starting point of the thread or kernel context). What you can do
with this macro is to execute a short circuit return to the intial state
of a thread/kernel context. Within the kernel interrupt handler it
serves as a performance optimizer: it serves as a direct return to the
interrupt exeception handler in 'traps.spp', not requiring to work back
thru the call stack. Your wording "so you can be restarted once the
thread can run again" suggest that the thread context is saved, but that
seems not to be the case.
Another point is that all stacks seem to and must have a size of 1
kBytes, and I wonder whether this is sufficient in all cases (I can
think of applications which require much more). I'd apreciate if you
could point me to some additional information about stack management in
OKL4.

Regards
Frank