feat(core/remote_io): add Remote I/O infrastructure #123
+713
−52
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
joaopeixoto13
force-pushed
the
wip/virtio
branch
from
1856a75
to
7c464ec
Compare
|
@joaopeixoto13 I'd suggest breaking this into two PRs. The first with the shmem/ipc refactoring and the second with the remote io feature. Also, please keep your history cleaner. Don't introduce commits that are refactored by later commits, specifically the change of virtio to remote io. Introduce them in their final version the first time. |
This patch relocates the initialization and shared memory access steps from the hardcoded settings in the existing IPC file to a generic shared memory file. Previously, the code assumed the existence of only one object working with the shared memory (ipc). With this update, the system is now prepared for future versions where multiple objects can be added and working with the shared memory. Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
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: joaopeixoto13 <joaopeixotooficial@gmail.com>
This commit introduces a refactor to the 'remote_io' infrastructure, enabling support for a multi-core configuration. With this enhancement, both frontend and backend components can now operate across multiple vCPUs. Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
This commit adds a new feature that allows working with virtual Remote I/O IDs in user space applications or the kernel I/O request management system. Instead of dealing with real Remote I/O IDs directly, the system now operates with relative IDs, and the mapping to actual IDs is managed internally by the Bao hypervisor. Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
joaopeixoto13
force-pushed
the
wip/virtio
branch
from
7c464ec
to
5b33dd3
Compare
For physical boards (e.g. ZCU102), when using the Remote IO there is a problem already identified when the Frontend VM's CPU goes to the idle state, as a result of the trap process and MMIO emulation. In this scenario, currently Bao Hypervisor is unable to save the state of the registers before powering off. This patch replaces the psci_power_down call by an explicit WFI (Wait For Interrupt), temporarily resolving the problem. Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
This patch resolves the translation between the virtual remote IO ID and the absolute remote IO ID utilized by the Bao Hypervisor. Specifically, the absolute remote IO ID is obtained by indexing the list of IO devices within the Backend VM using the virtual remote IO ID as index. Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
joaopeixoto13
force-pushed
the
wip/virtio
branch
from
08070a4
to
cab24aa
Compare
Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
This commit removes the register offset (reg_off) field from Bao's Remote I/O hypercall since we already negotiate the full address (addr field). Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
For some heavy workloads (e.g. iperf3) when a frontend VM is configured with more than one vCPU, two Remote I/O requests can be raised practically at the same time, causing the Dispatcher I/O system (implemented in the backend VM Linux kernel) to miss a Remote I/O interrupt. In this case, as we are unable to change the way the Linux kernel handles interrupts, the solution is to return the number of requests that are still in the pending phase at the time of the Ask hypercall, so that the Dispatcher I/O system can do the remaining `n` Ask hypercalls to process the remaining orders. Signed-off-by: joaopeixoto13 <joaopeixotooficial@gmail.com>
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 introduces the Remote I/O infrastructure capable of providing VirtIO functionalities.