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:
- 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_...
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