Enable mapping extra TCB and SC caps into PD's

[Kswin01]

Note

See the modifications to manual.md for the behaviour, or alternatively, the old version of the PR description which is roughly similar but differs in the details:

---

This PR adds functionality to map arbitrary TCB and SC caps of other PD's into another PD. This can allow a user to share a SC cap of one PD to another without having to explicitly make the destination PD the parent (and therefore have to also handle faults of the child).

Adding a cap to a PD requires adding a <cap/> node to a PD:

    <protection_domain name="parent" priority="55">
        <program_image path="parent.elf" />
        <cap type="tcb" pd="child" dest_cspace_slot="5" />
        <cap type="sc" pd="parent" dest_cspace_slot="6" />
    </protection_domain>

You must specify the type of cap (currently only implemented for TCBs and SCs but can be extended in the future). Additionally, the name of the pd that is the source of that cap. The destination cspace slot is an index into the BASE_USER_CAPS region of the cspace.

This PR is also reflected in: https://github.com/au-ts/microkit_sdf_gen/tree/cap_sharing

[Indanz]

As you can see from the comments, I don't know Rust, so take everything I say with a big grain of salt. But I'm pretty sure it doesn't need to be quite this ugly.

[midnightveil]

Remaining work on this to get this merged:

• Test example
• Documentation
• Bikeshed the appearance (thought: instead of <cap>, doing a <extra_caps> element with child (<endpoint>) or (<sc>); this would allow more fine grain attribute on the different cap types, instead of smooshing everything onto one <cap> element. (edit: <cnode element?)

Desired additions in later PRs.

• remove PD hierarchy. To do this we want to add a feature to automatically migrate one .system file to another; there should be no need for this to be manual user.
• Make it a fully functional replacement for the PD hierarchy. i.e. allow the fault endpoints to be set up arbitrarily. (it might make sense for this not to be the <extra_caps>, IDK
• Make the "user caps" its own cnode that is dynamically sized, there's no reason to limit this (see also: the untypeds PR).
• Auto-allocation of slots? (edit: maybe not?)
• perms

[midnightveil]

We've bikeshed the appearance internally, and decided that it will look like:

<protection_domain name="alpha">
   <cspace> <!-- the root cnode (currently size 512) -->
       <!-- implicitly, not mentioned in the xml: the microkit caps -->
       
       <cap_tcb slot="1" pd="beta" />
       <cap_vspace slot="2" pd="beta" />
   </cspace>
</protection_domain>

The plan is soon to change the layout of this exactly; I'm going to make the layout of where the user caps be instead an implementation details and you should use a helper function.

Survey of cap types

We have:

1. Null cap (irrelevant)
2. Untyped cap. There are no static untypeds to refer to, so this cap type does not make sense. When we do the dynamic-remaining untypeds these are dynamic, and we give them a cnode to go into. So we can ignore this. badge is meaningless
3. Endpoint: not allowed, use channels for that
4. Notification: badge useful here, though can default to the original
5. reply cap: not given
6. cnode cap: this will probably want some kind of "name" field to address the cnode, or maybe "pd" to address the cspace. badge contains the 'guard' value which we do want to control.
7. thread/tcb: 1-1 with the pd name. badge means nothing.
8. irqcontrol: badge means nothing. there is only one of these, so pd is meaningless
9. irqhandler: badge has no meaning.
10. arm smc: badge convey the smc ids that are allowed to use
11. x86 iospace: badge is like PCI id or something, IDK
12. riscv opensbi: badge conveys sbi ids that are allowed to use
13. schedcontext: only assocaited with pd, nothing
14. frame caps: no badge, associated with ?? something not a pd
15. page table: no badge, associated with ?? not a pd
16. vspace: no badge, associated with a pd
17. asidcontrol/asidpool: no badge, not associated with anything

[Indanz]

5. reply cap: not given

Actually, for timeout fault handlers it makes sense to reply on behalf of the task for recovery purposes, especially if the server is reset.

[midnightveil]

Actually, for timeout fault handlers it makes sense to reply on behalf of the task for recovery purposes, especially if the server is reset.

well, regardless, the badge means nothing. and this would be associated with a PD, at least.

stale

[midnightveil]

Commit history before I clean it up: https://github.com/au-ts/microkit/tree/archive/cap_sharing_history.