Call for Google Summer of Code 2021 project ideas

Call for Google Summer of Code 2021 project ideas

[Stefan Hajnoczi]

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

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

[Sergio Lopez]

[-- Attachment #1: Type: text/plain, Size: 7770 bytes --]

On Fri, Feb 12, 2021 at 01:22:43PM +0000, Florescu, Andreea wrote:
> 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.

FWIW, libkrun already has support for virtio-console with the basic
functionality and VIRTIO_CONSOLE_F_SIZE, and this code could be easily
borrowed for implementing it in some rust-vmm crate:

https://github.com/containers/libkrun/blob/main/src/devices/src/virtio/console

Sergio.

> '''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<mailto: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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Stefan Hajnoczi]

Thanks, I have published the rust-vmm project ideas on the wiki:
https://wiki.qemu.org/Google_Summer_of_Code_2021

Please see Sergio's reply about virtio-consoile is libkrun. Maybe it
affects the project idea?

Stefan

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

[Andreea Florescu]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]



On 2/17/21 1:20 PM, Stefan Hajnoczi wrote:
> 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.
>
>
>
> Thanks, I have published the rust-vmm project ideas on the wiki:
> https://wiki.qemu.org/Google_Summer_of_Code_2021
Thanks, Stefan!
>
> Please see Sergio's reply about virtio-consoile is libkrun. Maybe it
> affects the project idea?
I synced offline with Sergio. It seems I've misread his comment.
The code is already available in libkrun, and to port it to rust-vmm
will likely take just a couple of days. We explored the option of also
requesting to implement VIRTIO_CONSOLE_F_MULTIPORT to make it an
appropriate GSoC project, but we decided this is not a good idea since
it doesn't look like that feature is useful for the projects consuming
rust-vmm. It also adds complexity, and we would need to maintain that as
well.

Since it would still be nice to have virtio-console in rust-vmm, I'll
just open an issue in vm-virtio and label it with "help wanted" so
people can pick it up.
Can we remove the virtio-console project from the list of GSoC ideas?

Also, iul@amazon.com will like to help with mentoring the GSoC projects.
Can he be added as a co-mentor of: "Mocking framework for Virtio Queues"?

Sorry for the ping-pong, and thanks again for everything!

Andreea




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.

[-- Attachment #2: 0x9B51563C1FA36782.asc --]
[-- Type: application/pgp-keys, Size: 2501 bytes --]

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

[Stefan Hajnoczi]

On Thu, Feb 18, 2021 at 11:50 AM Andreea Florescu <fandree@amazon.com> wrote:
> On 2/17/21 1:20 PM, Stefan Hajnoczi wrote:
> > 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.
> >
> >
> >
> > Thanks, I have published the rust-vmm project ideas on the wiki:
> > https://wiki.qemu.org/Google_Summer_of_Code_2021
> Thanks, Stefan!
> >
> > Please see Sergio's reply about virtio-consoile is libkrun. Maybe it
> > affects the project idea?
> I synced offline with Sergio. It seems I've misread his comment.
> The code is already available in libkrun, and to port it to rust-vmm
> will likely take just a couple of days. We explored the option of also
> requesting to implement VIRTIO_CONSOLE_F_MULTIPORT to make it an
> appropriate GSoC project, but we decided this is not a good idea since
> it doesn't look like that feature is useful for the projects consuming
> rust-vmm. It also adds complexity, and we would need to maintain that as
> well.
>
> Since it would still be nice to have virtio-console in rust-vmm, I'll
> just open an issue in vm-virtio and label it with "help wanted" so
> people can pick it up.
> Can we remove the virtio-console project from the list of GSoC ideas?

Done.

> Also, iul@amazon.com will like to help with mentoring the GSoC projects.
> Can he be added as a co-mentor of: "Mocking framework for Virtio Queues"?

Done.

Thanks for getting the rust-vmm mentors together! I'm looking forward
to more Rust virtualization projects :).

Stefan