[seL4] Capability unwrapping

Norman Feske norman.feske at genode-labs.com
Thu Feb 12 22:19:46 EST 2015

Hi Gerwin,

> we’ll have an internal discussion whether we can allow more cap
> transfers in one IPC. I don’t remember any fundamental limitation
> there, but we’ll need to dig into it a bit.

great that you are considering this change!

> As Tom pointed out, there will have to be some limit on the number
> of caps transferred, just to get a bounded and not too large WCET,
> but that limit can probably be quite a bit larger than 1.
> How many would your application need at most, and more generally
> speaking, what would you think is a good limit?

I reviewed all of Genode's RPC interfaces. The maximum number of
Genode-capability arguments per RPC call is 2. If I represent each
Genode capability by a triple of seL4 endpoint capabilities, the kernel
would need to support the delegation of up to 6 seL4 caps.

Regarding the interface, let me share my experience with other kernels.
The receiver needs a way to declare the designated names for the
received capabilities. Other kernels (such as NOVA and Fiasco.OC) allow
the receiver to specify a single naturally-aligned "receive window"
within the receiver's capability space. All delegated capabilities will
end up within the window. In my experience, this approach is far from
perfect. Since the receive window must be void of any existing
capability (i.e., NOVA does not allow "overmap"), the receiver has to
allocate a completely free window dimensioned (and aligned) with the
maximum number of capabilities to expect, e.g., 4. If a capability comes
in, it will populate the first slot of the receive window but the other
3 slots will remain empty. Because the window is polluted with a cap
now, the receiver needs to allocate an entirely new window for the next
IPC. Consequently, this approach tends to populate the receiver's
capability space quite sparsely and wastes capability slots.

>From my perspective, it would be much better if the receiver was able to
specify a 'ReceivePath' for each individual capability. The receiver
could thereby allocate each index individually instead of allocating a
window of consecutive indices.

Thanks again for discussing my request within your group. I look forward
to the outcome of it.


Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the Devel mailing list