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