[okl4-developer] clarifying L4-IPC

[Abi Nourai]

Hi Jorge,

Much of what you have is on point.  Some of it is not 100% true.  Let  
me give you a run through of IPC in my own words, and then you can ask  
me to clarify/expand on certain things.


Each L4 thread is associated with a bunch of virtual message registers  
(vmrs).  L4 IPC from thread A to B basically transfers data contained  
in A's vmrs to B's vmrc.

L4 IPC is synchronous, so before the transfer occurs, thread B needs  
to be blocked and waiting for thread A to send it a message.  If  
thread B is not blocked, then thread A, upon calling L4_IPC() will be  
placed on thread B's send queue and block until B becomes ready to  
receive the transfer.  These checks entail checking a bunch of kernel- 
maintained state, like thread state (to see if B is waiting for IPC),  
IPC partner (to check that thread B is waiting specifically for thread  
A or anythread and not specifically thread C).

Conceptually there is a copy of data from A's vmrs to B's vmrs.  Note  
I said conceptually.  vmrs being virtual are in practice mapped either  
to memory locations (called message registers and found in the  
thread's UTCB) or general purpose registers.  We try to map as many to  
general purpose registers as we can, whilst leaving enough registers  
available to actually execute the IPC transfer in assembly.  The rest  
get mapped to the UTCB mrs.

The transfer is fast because:
* In the common case where thread B is blocked and ready to received  
IPC from A, then IPC is not much more than updating some thread state  
and doing a contect switch to thread B.  In this case the vmrs that  
are mapped to gprs can be left in place.  I.e. A performs IPC() with  
data in gprs, kernel switches to thread B leaving data in gprs.  No  
copy needed ! The vmrs that are mapped to utcb memory locations (mrs)  
do need to be explicitly copied.  But because the IPC is synchronous,  
the copy is a direct copy from A to B.  The kernel does not need to  
buffer the data whatsoever.
* It's a small amount of code, so fits nicely into instruction/data  
caches and the TLB.  There may be a TLB miss, but the IPC code should  
touch very few pages, this should be rare (when IPC is frequent, as it  
typically is in a microkernel system).

Regards
Abi


On 03/03/2008, at 5:34 PM, Jorge Torres wrote:

> Hi okl4.org,
>
> I want to explain to a friend of mine how L4 IPC works, and why is  
> it efficient,  since my understanding of it, is way empirical, It is  
> probably better to clarify with you guys first, so here it goes how  
> I briefly understand a general among L4 (blocking) IPC operations:
>
> Lets say I have two threads Ta and Tb. where Ta is to send an IPC  
> message to Tb, prior to that Tb has to be on "waiting state", the  
> state value is stored by the u-kernel on thread's corresponding  
> virtual registers at its corresponding address space user thread  
> control block (UTCB). Having done so, Ta loads the message in its  
> TCB message registers, and it performs the "send"  syscall,  
> microkernel checks if sender has permission to communicate with the  
> recipient, if true, The virtual registers real-addresses are mapped  
> into Tb's message virtual register's virtual addresses, (is the  
> senders TID stored on the recipient's TCB? or where?), Tb state is  
> changed, and is sent to the first place on the scheduling queue. It  
> is very fast because: message is never copied (since its based on  
> mapping the same message onto the respective virtual addresses) and  
> since operation is granular, a TLB miss wont happen.
>
> Well that's somehow what I get, so please tell me how far is it from  
> being the truth.
>
> Cheers,
>
> Jorge
>
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer