Re: [Rust-VMM] Call for Google Summer of Code 2021 project ideas

[Florescu, Andreea]

Hey Stefan,

Thanks for taking care of organizing GSoC, and for allowing rust-vmm to also participate under the QEMU umbrella!

I am a bit unsure of how can we propose projects related to rust-vmm.

We did a bit of brainstorming in our team, and we came up with 3 project ideas.

I'll just paste them below, but please let me know if we were supposed to propose them some other way.

=== Implement the Virtio Console device in Rust ===

'''Summary:''' Implement the basic emulation for the Virtio Console device in Rust

Implement the basic functionality (excluding the optional features:
VIRTIO_CONSOLE_F_SIZE, VIRTIO_CONSOLE_F_MULTIPORT, or VIRTIO_CONSOLE_F_EMERG_WRITE)
of the Virtio Console Device, using the Virtio building blocks (queue implementations,
VirtioDevice traits) defined in rust-vmm/vm-virtio. The virtio console device uses
one virtio queue for transmitting data, and one virtio queue for receiving data.
The implementation can be extended to also support a subset of the previously
mentioned optional features.

'''Links:'''
* About rust-vmm: https://github.com/rust-vmm/community
* rust-vmm/vm-virtio: https://github.com/rust-vmm/vm-virtio
* virtio-console spec: https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-2550003

'''Details:'''
* Skill level: intermediate
* Language: Rust
* Mentor: iul@amazon.com
* Suggested by: fandree@amazon.com

=== Mocking framework for Virtio Queues ===

'''Summary:''' Implement a mocking framework for virtio queues

Paravirtualized devices (such as those defined by the Virtio standard) are used
to provide high performance device emulation. Virtio drivers from a guest VM
communicate with the device model using an efficient mechanism based on queues
stored in a shared memory area that operate based on a protocol and message format
defined by the standard. Various implementations of devices and other
virtualization building blocks require mocking the contents that a driver would
place into a Virtio queue for validation, testing, and evaluation purposes.

This project aims to lay the foundations of a reusable framework for mocking the
driver side of Virtio queue operation, that can be consumed by rust-vmm crates and
other projects. At the basic level, this means providing a flexible and easy to
use interface for users to set up the underlying memory areas and populate contents
(as the driver would do) for the basic split queue format in a generic manner. This
can further be extended for the packed format and with device-specific mocking
capabilities.

'''Links:'''
* About rust-vmm: https://github.com/rust-vmm/community
* Virtio queue spec: https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-230005
Issue in rust-vmm about reusing the mocking logic: rust-vmm/vm-virtio: https://github.com/rust-vmm/vm-virtio

'''Details:'''
* Skill level: intermediate
* Language: Rust
* Mentor: aagch@amazon.com
* Suggested by: aagch@amazon.com

=== Local running rust-vmm-ci ===

'''Summary:''' Run the rust-vmm-ci locally

The rust-vmm-ci provides automation for uniformely running the tests on
all rust-vmm repositories. It is built on top of Buildkite, and only allows
running the tests in the Buildkite context. To run the same tests as in the CI
locally, users need to manually copy the Buildkite pipeline steps.

The scope of this project is to make it possible for the same tests to easily run
locally. This project makes it easier to contribute to all rust-vmm repositories.

In order for that to be possible, the following steps are required:
- the Buildlkite pipeline is autogenerated from code instead of being a static
list of tests to run. This also allows us to uniformely use the same container
version for running all the tests (instead of manually modifying each step in
the pipeline)
- the code for autogenerating the Buildkite pipeline is reused for generating
a Python script which can be run locally


'''Links:'''
* rust-vmm-ci: https://github.com/rust-vmm/rust-vmm-ci
* Buildkite pipeline that currently runs the tests: https://github.com/rust-vmm/rust-vmm-ci/blob/master/.buildkite/pipeline.yml
* About rust-vmm: https://github.com/rust-vmm/community
* Buildkite documentation: https://buildkite.com/docs/tutorials/getting-started

'''Details:'''
* Skill level: intermediate
* Language: Python
* Mentor: fandree@amazon.com
* Suggested by: fandree@amazon.com

​Thanks again!

Andreea

---

From: Stefan Hajnoczi <stefanha@gmail.com>
Sent: Monday, January 11, 2021 1:47 PM
To: qemu-devel; kvm; rust-vmm@lists.opendev.org; Alex Bennée; Alexander Graf; Alberto Garcia; David Hildenbrand; Eduardo Habkost; Igor Mammedov; John Snow; Julia Suvorova; Gerd Hoffmann; Kevin Wolf; Laurent Vivier; Marc-André Lureau; Aleksandar Markovic; Sergio Lopez; Stefano Garzarella; Paolo Bonzini; Philippe Mathieu-Daudé
Subject: [EXTERNAL] [Rust-VMM] Call for Google Summer of Code 2021 project ideas

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Dear QEMU, KVM, and rust-vmm community,
QEMU will apply for Google Summer of Code
(https://summerofcode.withgoogle.com/) again this year.  This internship
program offers paid, 10-week, remote work internships for
contributing to open source.  QEMU can act as an umbrella organization
for KVM kernel and rust-vmm projects too.

Please post project ideas on the QEMU wiki before February 14th:
https://wiki.qemu.org/Google_Summer_of_Code_2021

What's new this year:
 * The number of internship hours has been halved to 175 hours over
   10 weeks. Project ideas must be smaller to fit and students will have
   more flexibility with their working hours.
 * Eligibility has been expanded to include "licensed coding school or
   similar type of program".

Good project ideas are suitable for 175 hours (10 weeks half-day) work by a
competent programmer who is not yet familiar with the codebase.  In
addition, they are:
 * Well-defined - the scope is clear
 * Self-contained - there are few dependencies
 * Uncontroversial - they are acceptable to the community
 * Incremental - they produce deliverables along the way

Feel free to post ideas even if you are unable to mentor the project.
It doesn't hurt to share the idea!

I will review project ideas and keep you up-to-date on QEMU's
acceptance into GSoC.

For more background on QEMU internships, check out this video:
https://www.youtube.com/watch?v=xNVCX7YMUL8

Stefan

_______________________________________________
Rust-vmm mailing list
Rust-vmm@lists.opendev.org
http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm

Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.