[seL4] Capability unwrapping

Gernot Heiser gernot at nicta.com.au
Thu Feb 12 22:39:48 EST 2015

Thanks for the explanation.

Yes, the receive window is very V2-ish, and has distasteful side effects. The receiver clearly needs more control. Which means that things get ore complicated when more caps are supported.

I’d like to understand the specific use cases better. I accept that one cap isn’t enough, there are likely unsolvable races, which require >1 caps to be transferred atomically. My intuition is that 3 should enough to solve all fundamental problems, and anything beyond that boils down to efficiency arguments/trade-offs.


> On 12 Feb 2015, at 22:19 , Norman Feske <norman.feske at genode-labs.com> wrote:
> 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.
> Cheers
> Norman
> --
> 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
> _______________________________________________
> Devel mailing list
> Devel at sel4.systems
> https://sel4.systems/lists/listinfo/devel


The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.

More information about the Devel mailing list