Forward debug console to host #190
Merged
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
In preparation for forwarding debug console SBI calls to a VM's host, and thus requiring that the buffer be in shared memory, have the user of the SBI debug console provide the memory that will be used for buffering console output in the call to set_as_console(). Signed-off-by: Andrew Bresticker <[email protected]>
In preparation for forwarding the debug console SBI calls from the guest TVM to the host, have GuestVm put its debug console buffer in a shared memory region that it converts at boot. Signed-off-by: Andrew Bresticker <[email protected]>
Forward PutString calls to the VM's host. For the host VM, we pin the memory backing the buffer that is to be printed while we write it to the console. For Tellus, we confirm that the buffer is in shared memory before we go print it. Signed-off-by: Andrew Bresticker <[email protected]>
Like the debug console, this should get forwarded to the VM's host rather than having Salus print directly to the console. Signed-off-by: Andrew Bresticker <[email protected]>
For certain ECALLs (for now, just debug console) from guest VMs, we want to forward the call to the host and have the host provide the return value. Do this by taking the A0/A1 values from the guest GPRs in the shared memory area when running the vCPU after it exits due to a forwarded ECALL, just like we do for emulated MMIO loads. Signed-off-by: Andrew Bresticker <[email protected]>
dgreid
approved these changes
Dec 30, 2022
abrestic-rivos
had a problem deploying
to
github-pages
GitHub Actions
Failure
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.
Forward debug console ECALLs (DBCN and legacy
put_char) to a VM's host instead of handling console output directly within Salus. For guest TVMs, this means that that buffer to be printed must reside in memory shared with the host VM.put_charcalls to the host, respectively.Looking for opinions on the forwarding of ECALL return values. Currently I'm just using A0/A1 from the shared memory area, which means the host will have to know which ECALLs for which it's expected to provide a return value. Other options I considered are: setting a flag (in shared memory?) that indicates to the host that it needs to provide a return value, or having a separate
sbi_returnstruct in the shared memory area where the host puts the return value (with sentinel values to indicate whether or not the TSM is expecting to find something there).Fixes #146