WIP: cocall #904
Closed
WIP: cocall #904
Conversation
This file contains 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
added 30 commits
February 11, 2020 16:17
colocated process.
in conditions that are quite hard to explain.
The reason for this is to make the diffs easier to understand.
Use __has_feature(capabilities) for now. There's some argument they should go under a config option when initially merged to dev. For system calls, include stub ENOSYS implementations.
We should probably dial back the abstraction a bit here.
It confuses debugging and may be leading to failing tests .
Allow start to hold a capablity and construct one with vm_map_buildcap before passing to vm_map_insert.
Add printfs for a couple failure cases that shouldn't happen. I'm not entierly sure these shouldn't be panic calls instead.
Add the ability to run a test-specific function in a child process re-execed with execve() or coexecve(). This will permit a test to fork and (coexec with a child running the test-specific function.
Add colocation_coexec_child and colocation_exec_child which use cheribsdtest_coexec_child() and colocation_exec_child() to create a potentially colocated child. The child then uses procstat_getvmmap() to determine that it does or does not (respectively) share an address space. The colocation_exec_child test currently assumes no opportunistic colocation and may require updates if that is reenabled.
We don't support colocating static binaries (it would be possible and maybe even a good idea to support position independent static binaries, but we don't have a facility to build such things). Failures are confusing enable a uprint warning when rejecting such things, but only when not doing opportunistic colocation.
This sets up a coaccepting child and makes a cocall into it. The parent test runner and child exchange PIDs and validate that they recieve them as expected.
Previously, on riscv64 it would die with: panic: setup_scb:518: vm_map does not contain basep 0x0 (length 0x0, offset 0x35)
Conflicts resolved: - AT_CAPV collided with upstream additions. Binary flagday for all capv aware programs! - unimpl syscall list collisions resolved - files lists merged (llvm14 support) - thread borrowing ast changes moved to ast_signal handler
|
cocall gets built directly by Jenkins, we don't need this long-lived PR building it a second time. Any attempt to bring some or all of it into dev will require a clean rewritten branch anyway. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This pull request contains the cocall(2) and associated syscalls, built on top of the functionality in #902. This is not intended to be merged as-is, instead, it's intended to gather feedback about the design.
Some bits - eg the thread borrowing, and cocall_slow(2)/coaccept_slow(2) - are being actively worked on, and are expected to change quite significantly.