[coyotos-dev] Issue with capitem_t -- forthcoming change to spec

[Jonathan S. Shapiro]

After some discussion, we decided today to make a specification change
to the invocation interface.

Various items in the invocation interface involve pointers, either
directly (the string pointers) or indirectly (the capitem_t items). I
had hoped to avoid having these parts of the interface be word-size
dependent.

Today, reviewing the IPC implementation issues, we came to the
conclusion that this simply won't work very well. Using 64-bit values on
a 32-bit platform imposes a severe cost on the IPC path to support a
case that nothing is likely to ever use. Certainly the use case is rare
enough that requiring extra user-mode burden is not a serious impediment
for those rare applications that do.

Based on this, we are going to revise the specification to say that all
pointers and capitem_t items in the invocation interface are of native
word size. This means that an IPC operation can neither source nor
target addresses that the hardware load/store instructions could not
target.

The use case for larger spaces on 32-bit platforms mostly has to do with
managing large stores and windows onto those stores. To support this, we
will *retain* 64-bit capitem_t's on both 32-bit and 64-bit platforms in
the GPT interface, where invocations of the GPT capability will take the
64-bit items on both platform classes.

IPC words will remain 64 bits on all platforms, because cross-class
invocations between 32-bit and 64-bit clients becomes rather tricky if
direct data words at the transport layer do not have a single size. The
payload mapping may differ between 64-bit and 32-bit hosts, but the
underlying unit of data transfer must preserve the ability to transfer
the message without loss of information.


shap