Draft: Memory Cap Sharing#10
Draft
cazb2 wants to merge 4 commits into
Draft
Conversation
This commit determines the size of the root cnode based upon the largest slot number that is specified in the sdf. Signed-off-by: Callum <c.berry@student.unsw.edu.au>
This commit unifies the way VM rights are encoded in the sdf. Previously normal map perms were represented as a raw u8 while the iomap perms were represented as a proper type. Preserves existing behaviour. Signed-off-by: Callum <c.berry@student.unsw.edu.au>
This is required to map frames at runtime.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sharing this as one possible design for the memory cap sharing discussions. Emphasising that it is only a sample approach that is almost certainly not the best. However there are so many possible approaches to implementing this functionality it seems like implementing different approaches and comparing each of them is one way to reach a good final design.
This approach allows the sharing of frame capabilities. This can be used to implement designs such as gdb, dynamic dma protection (the ability to make memory temporarily reachable via dma) and have pre allocated page table regions of memory where frames can be mapped at runtime once the physical addresses are known which is useful in x86 contexts (will require access to device untyped).
In terms of what it offers: support for accessing frames of any memory region, accessing iospace caps required for mapping and unmapping frames in an IO address space, accessing frames of any PDs stack along with the base virtual address (the size can be discovered from the sdf), accessing the frame for the ipc buffer of any PD, accessing the frames of a PDs elf along with the virtual address each frame is mapped at.
It also supports a new page table / io page table concept which will allocate the page tables but not the frames for a given virtual address region. This cleanly supports the actual mapping and unmapping of frames in an address space since currently the only way to ensure that the upper levels of page table are present is either through mapping a memory region and then overmapping it, or relying on the fact that by mapping in one 4KiB we know there will be room for 511 4KiB pages consecutive to it.