Skip to content

Instantly share code, notes, and snippets.

@techiepriyansh

techiepriyansh/gsoc23_qemu_contributions.md

Created August 25, 2023 23:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save techiepriyansh/d11a56152abb496f009c0b3b374a91fd to your computer and use it in GitHub Desktop.
Save techiepriyansh/d11a56152abb496f009c0b3b374a91fd to your computer and use it in GitHub Desktop.
Download ZIP
GSoC'23 @ QEMU Final Report
Raw
gsoc23_qemu_contributions.md

GSoC'23

GSoC'23 Project Report

Project Description

The vhost-user-vsock Rust application emulates a virtio-vsock device in an external process and provides the hybrid VSOCK interface over AF_UNIX introduced by Firecracker. The goal of my project was to extend this application to support sibling VM communication.

My Contributions

1. Multiple isolated guests

Previously, if one wanted to use the device with multiple guests, they'd have to separately spawn the vhost-user-vsock application for each guest. So, I added support for handling multiple guests in a single process instance. There was no communication between the VMs yet, just multiple VMs being handled by the same process in separate threads.

  • PR(s):

2. Sibling VM communication

Once we had the process handling multiple guests in separate threads, all that was needed for sibling communication was to essentially route packets destined for a sibling VM to the corresponding sibling thread. I did an implementation in #370 which seemed to work when tested with nc-vsock (patched to set .svm_flags = VMADDR_FLAG_TO_HOST to enable sibling communication). But it would later turn out, as I would detail in this issue, that my implementation had the concurrency issues of deadlock and starvation. These issues were discovered while I was trying to get iperf-vsock to work with the implementation. I fixed the issues in #385 but still couldn't get iperf-vsock to work. I've listed some of the possible reasons for why this might be the case in this comment. It still needs to be resolved in the future.

3. Connection to sibling VM in iperf-vsock

To make it easier for testing the sibling VM communication implementation in vhost-user-vsock, I added support for connecting to a sibling VM in iperf-vsock.

  • PR(s):
    • #2 (merged)

4. VM groups in sibling communication

Users might find it useful to impose restrictions over which VMs are allowed communicate with each other. So, we introduced the concept of groups. A list of group names can be assigned to each device. Two VMs are allowed to communicate with each other only if the devices handling them have at least one group in common.

  • PR(s):

5. Adding new VMs at runtime

The implementation for this is currently under progress. In the general case, we also want to support removing the existing VMs at runtime, but this is not possible with the current implementation of VhostUserDaemon in the vhost-user-backend crate.

  • PR(s):

Future Work

  • Getting iperf-vsock to work with the implementation
  • Completing the support for adding new VMs at runtime
  • Improvements in vhost-user-backend to
    • support custom handlers for faster communication between vring workers for packet routing (avoiding eventfd)
    • allow stopping the VhostUserDaemon externally (needed to support removing VMs at runtime)
  • Extending tools like socat, ncat and uperf with the sibling flag to enable sibling communication

Acknowledgement

Big thanks to my amazing mentors, Stefano and German, for their incredible help and guidance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment