Checkpoint/restore of capabilities

[Denis Huber]

Hello Norman,

your approach sounds really good and promising. But I have a problem 
when storing the Capabilities from the Cap Space of the child:

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).

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?

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?


Kind regards,
Denis

On 31.08.2016 18:43, Norman Feske wrote:
> Hello Denis,
>
>> After a restore of a component the capability space shall be the "same"
>> as before the checkpoint:
>> 1) The capabilities after the restore shall point to corresponding
>> object identities.
>> 2) Also the capabilities after the restore shall be on the same slot
>> (have the same address) in the capability space as before the checkpoint.
>>
>> The capability space resides in the kernel and Genode does not offer an
>> API to manipulate it. Is there a way to accomplish my goal with Genode's
>> API anyway?
>
> there is no ready-to-use solution via the Genode API because the way
> capabilities are handled vastly differs between the various kernels.
> Manipulating the capability space of a remote component wouldn't even be
> possible on some kernels. However, since you are using a specific kernel
> (Fiasco.OC) that provides an asynchronous map operation, the problem can
> be tackled in a kernel-specific way.
>
> I would propose to extend the existing 'Foc_native_pd' RPC interface [1]
> with RPC functions for requesting and installing capabilities from/into
> the capability space of the PD.
>
> [1]
> https://github.com/genodelabs/genode/tree/master/repos/base-foc/include/foc_native_pd
>
> The function for requesting a capability would have an iterator-like
> interface that allows the client to iterate over the PD-local selector
> numbers and sequentially obtain the underlying capabilities as
> Genode::Native_capability objects (which can be delegated via RPC). Each
> call would return a Genode::Native_capability and a selector number of
> the capability to request with the next RPC call. In a first version,
> you may simply iterate over all numbers up to the maximum selector
> number, returning invalid capabilities for unused selectors. The
> iterator-like interface would then be a performance optimization.
>
> The function for installing a capability would take a
> Genode::Native_capability and the destination selector number as
> arguments. The implementation of the 'Foc_native_pd' interface resides
> in core, which has access to all capabilities. The implementation would
> directly issue Fiasco.OC system calls (most likely 'l4_task_map') to
> install the given capability into the targeted PD.
>
> Does this sound like a reasonable plan?
>
> Cheers
> Norman
>