Scheduler events for (hierarchical) tcaps

[phanikishoreg]

---

Gabe's idea:

We don't currently have a great mechanism to support hierarchical tcaps as the parent can't determine the time consumption in the child without introspecting, and even with that, the child can trivially break the accounting by transferring to another tcap.

Proposal: We add a scheduler event for time consumption. Parents receive events (just like thread events) on tcap time consumption. Parents can set the child up to send the event to the parent. Children can create more tcaps and manage them, but the events will be recursively passed down to the parent (much like thread events).

We already essentially have the mechanism for this, so I don't see it increasing code complexity that much. It is only necessary when timers fire or when tcaps are changed (I think), so not on each dispatch. The main downside is that it will likely increase interrupt and timer latency.

---

This is good idea imo:

1. It enables the "ancestors" to properly track the time consumed as the events are delivered recursively up the hierarchy.
2. It also coalesces events from multiple grand descendants into a single child event by the design of scheduler events, thereby reducing "tcap" event processing overheads in ancestors.

We have to be cautious in not limiting this mechanism to hierarchical and be able to generalize this mechanism in the case of sibling tcap delegations. How do we ensure that?
I think in addition to the above, for tcap delegations to sibling (more generally "non-hierarchical") tcaps should involve tcap scheduler events.
Perhaps,

1. "expended/consumed" sort of event to the parent of the source tcap.
2. "replenished" sort of event to the parent of the destination tcap.
   These events are only meaningful if they are "non-hierarchical" otherwise are just redundant.
   This also means extra overheads in "event processing" at the user-level, more overheads in the "delegation" path.