Checkpoint/restore of capabilities

[Denis Huber]

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

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?

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.


Kind regards,
Denis

On 10.09.2016 11:52, Denis Huber wrote:
> Hello Norman,
>
> thank you for your great answer. I will follow your advise and
> virtualize all necessary services that a target component uses.
>
>
> Kind regards,
> Denis
>
> On 09.09.2016 10:58, Norman Feske wrote:
>> Hi Denis,
>>
>>> The child component shall be migrated from one ECU to another. The
>>> Genode system on the other ECU may have the Rpc_objects, which the child
>>> needs (e.g. shared dataspaces), but their object identities are
>>> different (e.g. other addresses in memory) or the Rpc_objects do not
>>> exist (e.g. a session object between the child and a service).
>>
>> so the problem goes much deeper than merely requesting and populating
>> the child's capability space. You need the replicate the entire child's
>> execution environment at the destination ECU. That means for each
>> capability in possession of the child, your runtime needs to know the
>> exact meaning. E.g., if the child has a session capability to a session
>> created with certain session arguments, the same kind of session must be
>> re-created at the destination ECU. Of course, the same holds for all
>> dataspaces, threads, and other RPC objects that the child can reference
>> via the capabilities present in its capability space.
>>
>> The logical consequence is that the runtime must virtualize all services
>> used by the child. E.g. if the child creates a LOG session, the runtime
>> would create a session to a LOG service in the child's name but hand out
>> a capability locally implemented LOG-session wrapper - similar to what
>> you have already done for the RAM service. So when migrating the child,
>> you now exactly what the various capabilities in the child's capability
>> space mean and can transfer the underlying state to the destination ECU.
>>
>> In principle, this is how Noux solves the fork problem. But in the case
>> of Noux, I deliberately avoid populating the child's capability space
>> with Genode capabilities in order to alleviate the need to virtualize
>> many Genode services. Instead, I let the child use the Noux session as
>> its only interface to the outside world. At the Noux-session level, the
>> child does not talk about Genode capabilities but about file
>> descriptors, for which Noux knows the meaning. Of course there exist a
>> few capabilities in the child's capability space, in particular the
>> parent cap, the Noux-session cap, and the caps of the child's
>> environment. But these few capabilities are manually re-initialized by
>> the freshly created process after the fork.
>>
>> In your case, you want to replicate the child's capability space in a
>> way that is transparent to the child. Like Noux, you need the have a
>> complete model of the child's execution environment in your runtime.
>> Unlike Noux, however, you want to let the child interact with various
>> Genode services. Consequently, your model needs to capture the those
>> services.
>>
>>> During a restore, I will have to relink the Native_capability to the
>>> available Rpc_object or simply recreate the Rpc_object. In both cases I
>>> have to know the types of the Native_capabilities, when I snapshot them
>>> from the Cap Space of the child. Is there a way to find out the type of
>>> a Native_capability through an API function?
>>
>> As discussed above, the type alone does not suffice. Your runtime needs
>> to know the actual semantics behind each capability, e.g., not just the
>> knowledge that a certain capability is a RAM-session capability but also
>> the information how much quota the RAM session has and which dataspaces
>> belong to it. Or as another example, you don't just need to know that a
>> capability is a file-system session but also the session arguments that
>> were used when the session was created.
>>
>>> If there is no ready-to-use function/approach, can I intercept the type
>>> to which a Native_capability is reinterpreted in Rpc_entrypoint::manage
>>> as a workaround solution?
>>
>> Since your runtime needs to create a representative for each RPC object
>> the child interacts with in the form of a locally implemented RPC object
>> (managed by the runtime's entrypoint), you can in principle use the
>> 'Rpc_entrypoint::apply' method to look up the local RPC object for a
>> given capability.
>>
>> Best regards
>> Norman
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>