Back to UTCB IPC

[Marc CHALAND-2]

Hi,

I am back with my problem with UTCB IPC. To sum up the context :
I use pure l4env applications. Here is the scenario between my server
and my client :
1. client makes an UTCB IPC to manager. Manager does an
l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
worker thread id to client.
2. client allocates memory and associated flexpage and sends it to server.
3. UTCB IPC is sent to worker with 3 parameters :
  - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
  - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
arg3=0x7069776c
It seems that 0xbff00200 is not mapped on the same memory on client
and server side. As there is no problem for first IPC (utcb->values is
also 0xbff00200), is there any potential problem with flexpage ?

As utcb->values is still the same, what happens if several threads try
to make UTCB IPC ?

Another question : when I link my application with liblogserver.a, I
have strange logs :
.rm.sem.mainMain function returned.
It seems that .rm .sem and .main are added by l4env, but I didn't find where.

Regards
Marc

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Ronald Aigner]

Hi Marc,

Marc CHALAND wrote on 03/06/2008 10:28 AM this:

> Hi,
>
> I am back with my problem with UTCB IPC. To sum up the context :
> I use pure l4env applications. Here is the scenario between my server
> and my client :
> 1. client makes an UTCB IPC to manager. Manager does an
> l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
> worker thread id to client.
> 2. client allocates memory and associated flexpage and sends it to server.
> 3. UTCB IPC is sent to worker with 3 parameters :
>   - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
>   - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
> arg3=0x7069776c

This should not happend, because sending a flexpage with UTCB is
currently not supported by Fiasco. Can you post the signature of this
method, so I can debug the code generation?

> It seems that 0xbff00200 is not mapped on the same memory on client
> and server side.
Right, because UTCBs are unique for each thread, each thread has its own
UTCB at a different virtual address. However, the same local threads in
different address spaces--for instance, thread 8.2 and 9.2-- *may* have
their UTCB mapped to the same virtual address.

> As there is no problem for first IPC (utcb->values is
> also 0xbff00200), is there any potential problem with flexpage ?
UTCB values stays the same. It depends on the generated stub whether
UTCB IPC is actually used or not. Sending a flexpage, usually
disqualifies the usage of UTCB IPC.

BTW: Using the same CORBA_Environment for different threads will have
the effect that a wrong UTCB is used. The generated stub will access the
UTCB stored in the environment. The actual IPC will use the UTCB of the
thread sending the IPC. It is therefore important to initialize the
environment in the thread that is using it.

>
> As utcb->values is still the same, what happens if several threads try
> to make UTCB IPC ?
A UTCB is unique for each L4 thread, i.e., each thread has it's own UTCB.

>
> Another question : when I link my application with liblogserver.a, I
> have strange logs :
> .rm.sem.mainMain function returned.
> It seems that .rm .sem and .main are added by l4env, but I didn't find where.
If you are linking with liblogserver.a you should have a log server running.

These suffixes are registered at names (and the kernel debugger) to ease
debugging.
rm: l4/pkg/l4env/lib/src/startup.c: 316
main: l4/pkg/l4env/lib/src/startup.c: 322
sem: l4/pkg/semaphore/lib/src/semaphore.c: 501

Regards, Ron.

--
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Marc CHALAND-2]

>From Ronald Aigner :
> > 1. client makes an UTCB IPC to manager. Manager does an
> > l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
> > worker thread id to client.
> > 2. client allocates memory and associated flexpage and sends it to server.
> > 3. UTCB IPC is sent to worker with 3 parameters :
> >   - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
> >   - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
> > arg3=0x7069776c
> This should not happend, because sending a flexpage with UTCB is
> currently not supported by Fiasco. Can you post the signature of this
> method, so I can debug the code generation?

Yes, step 2 is not a UTCB IPC. However 1 and 3 are UTCB IPC.
What do you mean signature ? The full idl file and generated ones ?

> > As there is no problem for first IPC (utcb->values is
> > also 0xbff00200), is there any potential problem with flexpage ?
> UTCB values stays the same. It depends on the generated stub whether
> UTCB IPC is actually used or not. Sending a flexpage, usually
> disqualifies the usage of UTCB IPC.

Do you mean, once a flexpage is sent no UTCB IPC should be sent after ?

> BTW: Using the same CORBA_Environment for different threads will have
> the effect that a wrong UTCB is used. The generated stub will access the
> UTCB stored in the environment. The actual IPC will use the UTCB of the
> thread sending the IPC. It is therefore important to initialize the
> environment in the thread that is using it.

On client side, there is only one thread. One different
CORBA_Environment is used for each call. On server side, One
CORBA_Server_Environment different is used for manager and worker.

> > As utcb->values is still the same, what happens if several threads try
> > to make UTCB IPC ?
> A UTCB is unique for each L4 thread, i.e., each thread has it's own UTCB.

So why is it the same value (0xbff00200) for manager and worker ?

> > It seems that .rm .sem and .main are added by l4env, but I didn't find where.
> If you are linking with liblogserver.a you should have a log server running.

Yes

> These suffixes are registered at names (and the kernel debugger) to ease
> debugging.
> rm: l4/pkg/l4env/lib/src/startup.c: 316
> main: l4/pkg/l4env/lib/src/startup.c: 322

These lines doesn't match my startup.c. I use r315 of public repository.

I updated last version of uclibc. It seems that bcmp, bcopy and bzero
disapeared, isn't it ?
I cannot link my applications :
/home/chaland/l4/build-tudos-ia32/lib/x86_586/libuc_c.a(tzset.o): In
function `tzset':
/home/chaland/l4/build-tudos-ia32/pkg/uclibc/lib/uclibc/ARCH-all/libc/misc/time/time.c:1876:
undefined reference to `time'
Any idea to solve this ?

Regards
Marc

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Ronald Aigner]

Marc CHALAND wrote on 03/06/2008 12:37 PM this:

>>From Ronald Aigner :
>>> 1. client makes an UTCB IPC to manager. Manager does an
>>> l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
>>> worker thread id to client.
>>> 2. client allocates memory and associated flexpage and sends it to server.
>>> 3. UTCB IPC is sent to worker with 3 parameters :
>>>   - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
>>>   - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
>>> arg3=0x7069776c
>> This should not happend, because sending a flexpage with UTCB is
>> currently not supported by Fiasco. Can you post the signature of this
>> method, so I can debug the code generation?
>
> Yes, step 2 is not a UTCB IPC. However 1 and 3 are UTCB IPC.
> What do you mean signature ? The full idl file and generated ones ?

If it's the same as the one you send already, no need to.

>>> As there is no problem for first IPC (utcb->values is
>>> also 0xbff00200), is there any potential problem with flexpage ?
>> UTCB values stays the same. It depends on the generated stub whether
>> UTCB IPC is actually used or not. Sending a flexpage, usually
>> disqualifies the usage of UTCB IPC.
>
> Do you mean, once a flexpage is sent no UTCB IPC should be sent after ?
No, what I meant was that for the IPC involving the flexpage no UTCB IPC
can be used. Any IPC before or after, which qualifies for UTCB IPC will
use UTCB IPC.

>
>> BTW: Using the same CORBA_Environment for different threads will have
>> the effect that a wrong UTCB is used. The generated stub will access the
>> UTCB stored in the environment. The actual IPC will use the UTCB of the
>> thread sending the IPC. It is therefore important to initialize the
>> environment in the thread that is using it.
>
> On client side, there is only one thread. One different
> CORBA_Environment is used for each call. On server side, One
> CORBA_Server_Environment different is used for manager and worker.
>
>>> As utcb->values is still the same, what happens if several threads try
>>> to make UTCB IPC ?
>> A UTCB is unique for each L4 thread, i.e., each thread has it's own UTCB.
>
> So why is it the same value (0xbff00200) for manager and worker ?

Strange. How exactly do you set up the worker? Can you send that peace
of code? Do you initialize (using dice_server_default_environment) the
CORBA_Server_Environment for the worker after the worker thread is started?

Regards, Ron.

--
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Marc CHALAND-2]

>From Ronald Aigner :
> Strange. How exactly do you set up the worker? Can you send that peace
> of code? Do you initialize (using dice_server_default_environment) the
> CORBA_Server_Environment for the worker after the worker thread is started?

That's it. In fact, server environment was not inited into worker
thread but manager thread. That explains why it didn't work. Now it
works. Thank you for your great help.

Regards
Marc

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Adam Lackorzynski]

On Thu Mar 06, 2008 at 12:37:37 +0100, Marc CHALAND wrote:
> > These suffixes are registered at names (and the kernel debugger) to ease
> > debugging.
> > rm: l4/pkg/l4env/lib/src/startup.c: 316
> > main: l4/pkg/l4env/lib/src/startup.c: 322
>
> These lines doesn't match my startup.c. I use r315 of public repository.

I think Ron meant line 319 and 338.
 
> I updated last version of uclibc. It seems that bcmp, bcopy and bzero
> disapeared, isn't it ?

Yep, considered obsolete, so I just let it be this way. Replace with
memcpy, memmove, memset (note the reversed arguement for memmove..).

> I cannot link my applications :
> /home/chaland/l4/build-tudos-ia32/lib/x86_586/libuc_c.a(tzset.o): In
> function `tzset':
> /home/chaland/l4/build-tudos-ia32/pkg/uclibc/lib/uclibc/ARCH-all/libc/misc/time/time.c:1876:
> undefined reference to `time'
> Any idea to solve this ?

Add -lrtc -lc_be_time to libs.



Adam
--
Adam                 adam@...
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Marc CHALAND-2]

>From Adam :
>
> > I updated last version of uclibc. It seems that bcmp, bcopy and bzero
> > disapeared, isn't it ?
> Yep, considered obsolete, so I just let it be this way. Replace with
> memcpy, memmove, memset (note the reversed arguement for memmove..).

That was just to confirm that change is voluntary :). Is there
something like newsletter which explains big changes into public
repository ? An entry into wiki or svn logs ?

> Add -lrtc -lc_be_time to libs.

It works. I had to add -luc_c -lrtc -lc_be_time.
Thank you for your help.

Regards
Marc

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Adam Lackorzynski]

On Fri Mar 07, 2008 at 11:07:35 +0100, Marc CHALAND wrote:

> >From Adam :
> >
> > > I updated last version of uclibc. It seems that bcmp, bcopy and bzero
> > > disapeared, isn't it ?
> > Yep, considered obsolete, so I just let it be this way. Replace with
> > memcpy, memmove, memset (note the reversed arguement for memmove..).
>
> That was just to confirm that change is voluntary :). Is there
> something like newsletter which explains big changes into public
> repository ? An entry into wiki or svn logs ?

We could do the wiki thing, we just have to remember :)
 



Adam
--
Adam                 adam@...
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Guanghui, Cheng]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello:
I pushed this old mail to top and i want to know something about UTCB IPC.
> > UTCB values stays the same. It depends on the generated stub whether
> > UTCB IPC is actually used or not. Sending a flexpage, usually
> > disqualifies the usage of UTCB IPC.
>
> Do you mean, once a flexpage is sent no UTCB IPC should be sent after ?
I am interested in the question above because in the Thread::transfer_msg function as this:
1343 sender_regs->copy_msg (dst_regs);
1344
1345 copy_utcb_to (tag, receiver);
It seems every time the utcb ipc will follow the register ipc. Is it right?
Cheng Guanghui

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Adam Lackorzynski]

On Sat Oct 10, 2009 at 10:51:02 +0800, Guanghui, Cheng wrote:

> Hello:
> I pushed this old mail to top and i want to know something about UTCB IPC.
> > > UTCB values stays the same. It depends on the generated stub whether
> > > UTCB IPC is actually used or not. Sending a flexpage, usually
> > > disqualifies the usage of UTCB IPC.
> >
> > Do you mean, once a flexpage is sent no UTCB IPC should be sent after ?
> I am interested in the question above because in the Thread::transfer_msg
> function as this:
> 1343   sender_regs->copy_msg (dst_regs);
> 1344
> 1345   copy_utcb_to (tag, receiver);
> It seems every time the utcb ipc will follow the register ipc. Is it right?

Yes, actually there's no difference.



Adam
--
Adam                 adam@...
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers