Hello Stefan, thank you for the descriptive explanation :) I found out, that it does not suffice to map the (kernel) Capability from the target application to the Checkpoint/Restore application, because the Checkpoint/Restore application knows only already existing (Genode) Capabilities (kcap and key value) through the interception of Rpc_objects (e.g. own dataspace, rm_session, etc.) the target application uses.
Mapping a Capability gives me a new (kernel) Capability which points to the same object identity, but has a new kcap (= Capability space slot) value. Through intercepting all services the target application uses, the Checkpoint/Restore application knows (probably) all necessary Capabilities which are created through issuing the parent. But what about Capabilities which are created through a local service of the target application? The target application could create its own service with a root and session Rpc_object and manage requests through an Entrypoint. Although the Entrypoint creates new Capabilities through the PD session which the Checkpoint/Restore intercepts (PD::alloc_rpc_cap). The Checkpoint/Restore application cannot associate the created Capability to a concrete Rpc_object which is created by the target application itself. To solve this problem I did not find any solutions which is transparent to the target application nor is possible without modifying the kernel. A non-transparent, but user-level solution would be to let the Checkpoint/Restore application implement the service of the target application. But this will impose rewriting existing Genode components, which I would avoid. Perhaps someone in the Genode community has an idea, how I can get access to the target application's Rpc_objects created by its own service. Kind regards, Denis On 22.09.2016 10:16, Stefan Kalkowski wrote: > Hello Denis, > > On 09/21/2016 05:42 PM, Denis Huber wrote: >> Hello again, >> >> I have two small problems where I need some guidance from you :) >> >> 1. I am trying to understand the mechanism of l4_task_map [1]. Are the >> following thoughts correct? >> >> * The destination and source task cap (first 2 args of l4_task_map) can >> be retrieved through Pd_session::native_pd() and Foc_native_pd::task_cap(). >> * Send flexpage (arg #3) describes a memory area which contains the >> selector number (= address) of the source task's capability. >> * The send base (arg #4) is an integer which contains the address of the >> capability of the the destination task and also an operation code number >> for e.g. mapping or granting the capability. >> >> [1] >> https://l4re.org/doc/group__l4__task__api.html#ga0a883fb598c3320922f0560263da35e6 >> > > That is correct. > >> To iterate through all possible capabilities I need to know where the >> capability space starts (first valid selector number) and where it ends. >> Where can I find these information? I.e. which source files are relevant? > > THe capability space of each component is split between an area > controlled by core, and one controlled by the component itself. > Everything underneath Fiasco::USER_BASE_CAP (in file: > repos/base-foc/include/foc/native_capability.h:63) is used by core, and > has the following layout: the first nine slots are reserved to not > interfere with fixed capabilities of Fiasco.OC/L4Re. The only > capabilities of this fixed area that we use are the task capability > (slot 1) and the parent capability (slot 8). > The rest of the core area is divided into thread-local capabilities. > Every thread has three dedicated capabilities: a capability to its own > IPC gate (so to say its identity), a capability to its pager object, and > a capability to an IRQ object (some kind of kernel semaphore), that is > used for blocking in the case of lock-contention. You can find the > layout information again in the file: > repos/base-foc/include/foc/native_capability.h. > > Everything starting from slot 200 is controlled by the component itself. > Each component has a capability allocator, and some kind of registry > containing all currently allocated capabilities that is called "cap map": > > repos/base-foc/src/include/base/internal/cap_* > repos/base-foc/src/lib/base/cap_* > > Currently, the per-component capability allocator is (compile-time) > restricted to a number of up to 4K capabilities. The special component > core can allocate more capabilities, because it always owns every > capability in the system. > > The capability space controlled by the component thereby ranges from > 200-4296, but it is filled sparsely. When not knowing the "cap map" of a > component, you can however check the validity of a single capability > with `l4_task_cap_valid`, have a look here: > > > https://l4re.org/doc/group__l4__task__api.html#ga829a1b5cb4d5dba33ffee57534a505af > >> >> 2. I also wanted to look up the mechanism of Noux where it >> re-initializes the parent cap, the noux session cap, and the caps of a >> child's environment after a fork. But I cannot find the corresponding files. >> > > AFAIK, in Noux the parent capability in the .data section of the program > gets overwritten: > > repos/ports/src/noux/child.h:458 > repos/ports/src/noux/ram_session_component.h:80 > > After that parts of the main thread initialization of the target needs > to be re-done, otherwise e.g., the serialized form of the parent > capability in the data section would have no effect. But I'm not well up > with respect to Noux initialization. After some grep, I found this being > the first routine executed by the forked process: > > repos/ports/src/lib/libc_noux/plugin.cc:526 > > It shows up, how parent capability gets set, and the environment gets > re-loaded. > > Best regards > Stefan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
