About the exception ipc reply

[Guanghui, Cheng]

On Wednesday 14 October 2009 06:52:10 you wrote:
> On Tue Oct 13, 2009 at 13:01:46 +0800, Guanghui, Cheng wrote:
> > On Monday 12 October 2009 02:03:41 Adam Lackorzynski wrote:
> > > On Sun Oct 11, 2009 at 22:17:49 +0800, Guanghui, Cheng wrote:
> > > > 	From the l4-x2 manual it is said the reply from the exception
> > > > handler contains a label, an instruction pointer where the faulting
> > > > thread is resumed. I want to know whether it is implemented in the
> > > > Fiasco. I try to do this. Modify the utcb before send ipc resume the
> > > > exception thread but it seems no any effect about the instruction
> > > > pointer and stack pointer of resumed exception thread.
> > >
> > > My guess would be that you did not set the number of words to send in
> > > the reply. Set L4_UTCB_EXCEPTION_REGS_SIZE in the msgtag-words field of
> > > the reply.
> >
> > Hello Adam:
> > 	Now i use L4_UTCB_EXCEPTION_REGS_SIZE and i could fix the thread with
> > esp and eip by exception handler UTCB. And the thread could start with
> > new instruction pointer and new stack pointer.  But it still has some
> > problem when the thread quit from new function. So i want to know how an
> > thread is resumed by exception reply. I mean which part of code in kernel
> > could finish the thread wakeup. I read the receive.c but i don't find it.
>
> The function copy_utcb_to_ts copies the state from the utcb of the
> exception handler over the state of the thread. The thread then resumes
> with this new state. I think what you have to do is to e.g. prepare the
> stack of the thread in a way that when the new function's ret is
> called it resumes at the position it was intercepted. Is this possible?
Hello, Adam:
	Now the demo could work according to your design. And this demo is so simple 
only to emulate the situation we talked about before. I introduced a little 
about this demo:
 3 threads: timer_thread, exception_thread, main_thread
main_thread emulates the behaviour of system which is a endless loop to 
output. the function body is thread_func1.
timer_thread emulates the behaviour of timer thread which could trigger the 
exception periodically.
exception_thread emulates the behaviour of handling interrupt. The function 
body is exception_handler.

	When the timer_thread modify the status of main_thread with flag 
L4_THREAD_EX_REGS_RAISE_EXCEPTION. The main thread will be suspend and the 
exception_thread could get the exception ipc from main_thread. 
Exception_thread will modify the ESP and EIP in the utcb and then reply to 
main thread. The main thread will resume to the function about handling 
interrupt. When the handling interrupt function is over. The main thread could 
go back  to the status before the exception happens.
	The output:
count 49                            
...                           
count 58                            
id: 8:1, 12 0xeacff011 15 0x100711c 
 do irq 0                           
...                   
do irq 9                            
l4_sleep(): IPC error 00            
count 59                            
...
count 67
id: 8:1, 12 0xeacff011 15 0x100711c
	The output between "count ..." is execution of main thread. The output 
between "do_irq ..." is execution of exception thread which emulates the 
interrupt handling.

	BUT. I have a problem about my code when i fixing the stack of main thread. 
The correct code which could work well is like this:
utcb = l4_utcb_get();
eip = utcb->exc.eip;
esp = utcb->exc.esp;
utcb->values[12] = (l4_umword_t)(do_irq);
esp_loc = 1024 - (esp - (l4_umword_t)stack)/4;
stack[esp_loc - 1] = eip;
l4_msgtag ...
l4_ipc_send_tag
	In the code above i only reset the next stack with return address (old eip). 
But it seems i can't reset the new stack pointer like 
utcb->values[15] = esp - 4
	In my opinion it should do  but if i did it can't work. It seems some tricky 
here. Can you tell me why it is like this?
	Additinally, i tried this way about handling interrupt  with interrupt number  
like this:
	void do_irq(int irq)
	it can't work either.

	Thanks.
								Cheng Guanghui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20091015/eb565ff3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 2665 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20091015/eb565ff3/attachment-0001.c>