Current capage design

[shapj@us.ibm.com]

I'm glad that this has resurrected itself, as it was also on my list of
things to nail down.  Charlie's summary of rationale is a good one.

First, let me clarify how the *current* design actually works, and then
I'll respond in a separate note to Charlie's comments. For the strong of
stomach, the implementation can be found at:

     http://www.eros-os.org/eros-src/sys/arch/i486/kernel/PseudoInstr.cxx

A capage holds a fixed number of capabilities. In the current
implementation, capabilities are 16 bytes and the machine page size is 4096
bytes, so a capage currently holds 256 capabilities.  In the current
specification, this number is dependent on three things:

   The architected page size
   The *unprepared* capability size

Capability size is in turn the larger of the prepared capability size and
the unprepared capability size. It proves in the current design that a
capability residing in a capage is never prepared. As long as this is the
case, the number of capabilities in a capage is not dependent on the
prepared capability size, and is therefore independent of the architecture
pointer size.

It is conceivable that it will prove desirable in the future to allow
prepared capabilities within capages. I do not now recall why I imposed the
unprepared restriction. The restriction is problematic for resume keys, and
I'm fairly confident that it can be removed with only mild thought.

Capability load/store instructions are implemented by dedicated kernel
traps that simulate kernel-implemented instructions.  This path is
significantly faster than the key invocation path, though the difference is
probably due to implementation weaknesses in the key invocation path and
can be recovered.

They do *not* cause a page fault at user level (though the segment
traversal may cause one within the kernel). They do *not* proceed via the
usual capability path, and the pages are not actually mapped by the x86
PTEs.  The current implementation operates by travering the segment tree
because the x86 mapping tables do not provide sufficient auxiliary bits to
encode the necessary read/write permissions correctly, and also because
making these pages readable to the kernel would violate some implementation
assumptions of the fast-path IPC.

Jonathan S. Shapiro, Ph. D.
Research Staff Member
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085  (Tieline: 863)
Fax: +1 914 784 6576