Portals
- Portals (allow ad-hoc optimized IPC paths).
The portal specification includes:
- amount of state to save/restore.
- level of trust between invoking and invoked domain (e.g. for stack sharing).
- parameter manipulations:
- none
- a constant
- a function of nucleus-visible state
- a piece of code that was registered by a trusted server (e.g. dynamic sharing of memory windows)
- identity and entry point of invoked domain.
[es99.pdf]
To transfer control to B, A’s thread executes a trap instruction, which transfers control to the nucleus. The nucleus determines which portal A wishes to invoke, looks up the address of the associated portal code, and transfers control to the portal code. The portal code is responsible for saving registers, copying arguments, changing stacks, and mapping pages shared between the domains. The portal code then transfers control to component B.
As part of a portal traversal, the portal code can manipulate the page tables of the invoking and/or invoked protection domains. This most commonly occurs when a thread wishes to map, for the duration of the portal invocation, a region of memory belonging to the invoking protection domain into the virtual address space of the invoked protection domain; this gives the thread a window into the address space of the invoking protection domain while running in the invoked protection domain. When the thread returns, the window is closed. <-- ''this is due to observation that IPC usually contains either small paramaters that fit into registers or big parameters that can easier be mapped as whole page or several pages of memory.''
Such a memory window can be used to save the cost of copying data between protection domains. Variations include windows that remain open (to share pages between protection domains), windows that transfer pages from the invoking domain to the invoked domain (to implement tear-away write) and windows that transfer pages from the invoked domain to the invoker (to implement tear-away read).
Note that although the portal code may modify VM data structures, only the VM manager and the portal manager (generates optimized portal code, the only component permitted to manipulate portal tables) share the knowledge about these data structures. The nucleus itself is oblivious to those data structures.
Portal code may never block and may not contain loops. This is essential to ensure that the portal can be traversed in a small, finite amount of time. If the portal has to block (e.g. the invoked domain’s stacks queue is empty), then the portal code transfers control to the scheduler, inside which the calling thread is waiting for the resource.
Portal code is generated at runtime by portal manager, using code templates provided by various managers involved in portal invocation and client-server interface specification (level of trust, processing of arguments and return values).
cache flushing. We can reduce this time by employing various techniques used for run-time code generation, e.g., the techniques used by VCODE [Engler96].
[Engler96] D. Engler, “VCODE: A Retargetable, Extensible, Very Fast Dynamic Code Generation System”, Proc. Conference on Programming Language Design and Implementation (PLDI’96), pp. 160-170 (1996). [vcode-pldi.ps]
GNU lightning, a code generation system based on VCODE and similar in structure and operation.
libjit
