Open a capability receive window according to the number of the capabilities
expected as out parameter per RPC function.
Typically the number of capabilities expected during the reply of a RPC/IPC
call is 0 to 1. Before this patch ever a capability receive window of 4 has
been opened.
On Nova the capability selectors of receive windows must be naturally aligned
to the size/order of the expected capabilities. This leads until now to the
issue that the left over 3 capabilities couldn't be reused for new IPCs since
they are not naturally aligned to 4.
Issue #905
If we ran out of capabilities indexes, the bit allocator throws an exception.
If this happens the code seems to hang and nothing happens.
Instead one could catch the exception and print some diagnostic message.
This would be nice, but don't work. Printing some diagnostic message itself
tries to do potentially IPC and will allocate new capability indexes at
least for the receive window.
So, catch the exception and let the thread die, so at least the instruction
pointer is left as trace to identify the reason of the trouble.
Fixes#625
Extend tracking of delegated and of translated items. The additional
information is used to solely free up unused/unwanted mapped capabilities and
to avoid unnecessary revokes on capability indexes where nothing have been
received.
Fixes#430
Extend Native_capability type to hold a specific selector index where the to
be received cap during a IPC should be mapped to. This feature is required to
place created caps by the cap_session at specific indexes. This feature is
used by Vancouver to setup the virtualization exception portals (created by
the cap_session) at the intended indexes.
It now can hold a right bit used during IPC to demote rights of the to be
transfered capability.
The local_name field in the native_capability type is not needed anymore
in NOVA. Simplify the class, remove it from constructors and adapt all
invocations in base-nova.
Unfortunately local_name in struct Raw is still used in generic base code
(process.cc, reload_parent_cap.cc), however has no effect in base-nova.
MsgBuf has to keep the number of received capabilities in order
to free/know correctly unused and unwanted capabilities. Explicitly
call rcv_msg->post_ipc to store this information in a MsgBuf.
Don't reset rcv_msg in ipc.cc, since this is used during
un-marshalling of caps in ipc.h afterwards. The MsgBuf is reseted when its
de-constructor is called.
Kernel patch:
Introduce a transfer item type to express that a cap should be translated
and if this fails to map it instead.
It would be possible without this combined transfer item type however
with additional overhead. In this case Genode/NOVA would
have to map and translate all caps used as parameter in IPC. It would look
like this:
* If the map and translation succeed, the cap at the new cap index
would have to be revoked. Then the translated cap index can be used.
* If the map succeeds and the translation fails then the mapped cap index
can be used.
* It would become complicated when multiple caps are mapped and translated
and only some of the translation succeed. In such cases Genode would have
to figure out the right relation of translated/mapped and not
translated/mapped caps. It would require to make some assumption about the
order how translated/mapped caps are reported at the UTCB by the kernel.
All the points above lead to the decision to create a separate transfer item
type for that.
Genode:
Most the times the translation succeeds, mapping of caps happens either
seldom. This takes now a bit the pressure of not enough aligned receive
cap windows as described in issue #247.
The patch mainly adds adjustments to handle the
translated and mapped caps correctly especially during freeing of the
receive window (don't free translated cap indexes).
Fixes#268
