Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(core/remio): add Remote I/O infrastructure #176

Merged
merged 7 commits into from
Nov 5, 2024

Conversation

joaopeixoto13
Copy link
Member

@joaopeixoto13 joaopeixoto13 commented Sep 19, 2024

This PR introduces the foundational support for VirtIO by implementing a mechanism to forward VirtIO requests bidirectionally between the guest VM (or frontend VM) and its associated backend VM.

Validation

  • Platforms
    • Armv8-A AArch64
      • Xilinx Zynq UltraScale+ MPSoC ZCU102/4
      • NVIDIA Jetson TX2
      • QEMU virt
    • RISC-V RV64
      • QEMU virt
  • System configuration
    • Multiple VirtIO frontend drivers on multiple guest VMs, each running on multiple vCPUs
    • Multiple VirtIO backend devices on multiple backend VMs, each running on multiple vCPUs
  • Backend devices

Copy link
Member

@DavidMCerdeira DavidMCerdeira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generic comment: the namespace for this module can be shortened. I suggest rmio, remio, rm_io, rem_io

some of the comments may be a bit subjective. @josecm feel free to wage in

src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/inc/remote_io.h Outdated Show resolved Hide resolved
src/core/inc/remote_io.h Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
@joaopeixoto13
Copy link
Member Author

This new version includes a refactor of the code following @DavidMCerdeira's suggestions.
The key changes are as follows:

  • Introduced helper functions as part of a new API, such as remote_io_create_request, remote_io_get_request, remote_io_push_request_event, remote_io_pop_request_event, etc.
  • Decoupled the large remote_io_hypercall function into smaller, modular functions, each corresponding to a specific hypercall event.
  • Added the REMOTE_IO_DEV_TYPE enum for better type safety and code clarity.
  • Introduced a new type, remote_io_id_t, to manage the Remote I/O ID more effectively.

This refactoring improves the structure and maintainability of the code.

@joaopeixoto13
Copy link
Member Author

Generic comment: the namespace for this module can be shortened. I suggest rmio, remio, rm_io, rem_io

some of the comments may be a bit subjective. @josecm feel free to wage in

@josecm What are your thoughts on this? From @DavidMCerdeira's list of suggestions, remio seems like the most appropriate name. However, I'm unsure if remote_io is still considered too lengthy. For this reason, I've retained the current name in the latest version.

src/core/inc/remote_io.h Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
src/core/remote_io.c Outdated Show resolved Hide resolved
@josecm
Copy link
Member

josecm commented Sep 20, 2024

Generic comment: the namespace for this module can be shortened. I suggest rmio, remio, rm_io, rem_io
some of the comments may be a bit subjective. @josecm feel free to wage in

@josecm What are your thoughts on this? From @DavidMCerdeira's list of suggestions, remio seems like the most appropriate name. However, I'm unsure if remote_io is still considered too lengthy. For this reason, I've retained the current name in the latest version.

My suggestion would be either remio or simply rio.

@joaopeixoto13 joaopeixoto13 changed the title feat(core/remote_io): add Remote I/O infrastructure feat(core/remio): add Remote I/O infrastructure Sep 20, 2024
@joaopeixoto13
Copy link
Member Author

Generic comment: the namespace for this module can be shortened. I suggest rmio, remio, rm_io, rem_io
some of the comments may be a bit subjective. @josecm feel free to wage in

@josecm What are your thoughts on this? From @DavidMCerdeira's list of suggestions, remio seems like the most appropriate name. However, I'm unsure if remote_io is still considered too lengthy. For this reason, I've retained the current name in the latest version.

My suggestion would be either remio or simply rio.

Update: 01c2cbe

@DavidMCerdeira
Copy link
Member

Generic comment: the namespace for this module can be shortened. I suggest rmio, remio, rm_io, rem_io
some of the comments may be a bit subjective. @josecm feel free to wage in

@josecm What are your thoughts on this? From @DavidMCerdeira's list of suggestions, remio seems like the most appropriate name. However, I'm unsure if remote_io is still considered too lengthy. For this reason, I've retained the current name in the latest version.

My suggestion would be either remio or simply rio.

Update: 01c2cbe

The namespace change should be reflected in the function, variable names, enums, etc

@joaopeixoto13
Copy link
Member Author

Generic comment: the namespace for this module can be shortened. I suggest rmio, remio, rm_io, rem_io
some of the comments may be a bit subjective. @josecm feel free to wage in

@josecm What are your thoughts on this? From @DavidMCerdeira's list of suggestions, remio seems like the most appropriate name. However, I'm unsure if remote_io is still considered too lengthy. For this reason, I've retained the current name in the latest version.

My suggestion would be either remio or simply rio.

Update: 01c2cbe

The namespace change should be reflected in the function, variable names, enums, etc

Done 00b5acd

src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/vm.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/vm.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
Copy link
Member

@DavidMCerdeira DavidMCerdeira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd still like to test this before approving, but for now it looks good! 👍
You can squash the commits into a single one now

@joaopeixoto13
Copy link
Member Author

I'd still like to test this before approving, but for now it looks good! 👍 You can squash the commits into a single one now

Thanks, @DavidMCerdeira ! Also, please take a look at this commit, where I temporarily resolved the issue by replacing the psci_power_down call with a WFI instruction. However, I believe we need to find a more appropriate long-term solution. I haven't reviewed the current guest reboot PR yet, but it may offer some insight or help in addressing this issue.

@DavidMCerdeira
Copy link
Member

I'd still like to test this before approving, but for now it looks good! 👍 You can squash the commits into a single one now

Thanks, @DavidMCerdeira ! Also, please take a look at this commit, where I temporarily resolved the issue by replacing the psci_power_down call with a WFI instruction. However, I believe we need to find a more appropriate long-term solution. I haven't reviewed the current guest reboot PR yet, but it may offer some insight or help in addressing this issue.

I think for now it is fine. Actually we are aware of at least two platforms that require this behavior to work with bao currently. We should eventually allow platforms to have specific code to handle this sort of platform specific quirks

@joaopeixoto13 joaopeixoto13 force-pushed the feat/remote_io branch 2 times, most recently from 9c31e3e to 7c277bf Compare September 27, 2024 12:17
Copy link
Member

@josecm josecm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite the very (!) good work, I think we still need a bit of work on this PR. This is my first pass on it. I think we will need one or two more.

src/arch/armv8/armv8-a/cpu.c Outdated Show resolved Hide resolved
src/arch/riscv/sbi.c Outdated Show resolved Hide resolved
src/core/inc/remio.h Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/arch/riscv/sbi.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
@joaopeixoto13 joaopeixoto13 force-pushed the feat/remote_io branch 2 times, most recently from 29988f8 to 26a8a46 Compare November 1, 2024 11:42
DavidMCerdeira
DavidMCerdeira previously approved these changes Nov 1, 2024
Copy link
Member

@DavidMCerdeira DavidMCerdeira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only nitpicks
Otherwise looks good to me!

src/core/remio.c Outdated Show resolved Hide resolved
src/core/inc/config_defs.h Show resolved Hide resolved
@josecm
Copy link
Member

josecm commented Nov 2, 2024

@joaopeixoto13 rebase on main and resolve conflicts please

@joaopeixoto13
Copy link
Member Author

joaopeixoto13 commented Nov 2, 2024

@joaopeixoto13 rebase on main and resolve conflicts please

Done. If everything looks good, I can proceed to merge all the fix commits into the main parent commit that introduced the feature.

@josecm
Copy link
Member

josecm commented Nov 2, 2024

Done. If everything looks good, I can proceed to merge all the fix commits into the main parent commit that introduced the feature.

Please go ahead with that.

@joaopeixoto13
Copy link
Member Author

joaopeixoto13 commented Nov 2, 2024

Done. If everything looks good, I can proceed to merge all the fix commits into the main parent commit that introduced the feature.

Please go ahead with that.

Done ✅

DavidMCerdeira
DavidMCerdeira previously approved these changes Nov 2, 2024
src/core/inc/hypercall.h Outdated Show resolved Hide resolved
src/core/inc/hypercall.h Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
src/core/remio.c Outdated Show resolved Hide resolved
This commit renames the first argument of the hypercall to make
the code independent of the specific hypercall type.

Signed-off-by: João Peixoto <[email protected]>
This commit introduces a separation of input and output conventions for
hypercalls, addressing architecture-specific differences between ARM
and RISC-V. On ARM, the x0 register is used to pass both the extid,
fid, and the return value, while additional parameters (hypercalls arguments)
are passed via registers x1 to xn. On RISC-V, while the return value is
passed in a0, the extid and fid are handled by the a7 and a6 registers,
respectively. This means that the hypercall input arguments on RISC-V
should be passed through registers a0 to a5, while output hypercall
arguments are passed via a2 and onward (because all registers except
a0 and a1 must be preserved across an SBI call by the callee).
To accommodate these differences and provide a uniform interface,
two macros were introduced to abstract the handling of input and output
hypercall arguments across architectures.

Signed-off-by: João Peixoto <[email protected]>
This commit introduces two methods for setting and retrieving hypercall
arguments, allowing each hypercall implementation to flexibly manage its
specific arguments as needed.

Signed-off-by: João Peixoto <[email protected]>
Refactored the vCPU program counter incrementation by introducing
the architecture-agnostic method vcpu_writepc, aligning the
implementation with the approach used in the ARM architecture.

Signed-off-by: João Peixoto <[email protected]>
Implemented support for abort and exception handlers to suspend the
current vCPU based on the vCPU active flag.

Signed-off-by: João Peixoto <[email protected]>
This commit introduces two new methods to the objpool API.
The first method, objpool_alloc_with_id, enables the allocation of an
object within a pool and returns the index where the object was allocated.
The second method, objpool_get_by_id, allows retrieving a previously
allocated object using the index of the pool where it was initially allocated.

Signed-off-by: João Peixoto <[email protected]>
This commit introduces the foundational support for VirtIO by implementing
a mechanism to forward VirtIO requests bidirectionally between the
guest VM (or frontend VM) and its associated backend VM.

Signed-off-by: João Peixoto <[email protected]>
@josecm josecm merged commit 8f219e9 into bao-project:main Nov 5, 2024
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants