Call for GSoC internship project ideas

Call for GSoC internship project ideas

[Stefan Hajnoczi]

Dear QEMU and KVM communities,
QEMU will apply for the Google Summer of Code internship
program again this year. Regular contributors can submit project
ideas that they'd like to mentor by replying to this email by
February 7th.

About Google Summer of Code
-----------------------------------------
GSoC (https://summerofcode.withgoogle.com/) offers paid open
source remote work internships to eligible people wishing to participate
in open source development. QEMU has been doing internship for
many years. Our mentors have enjoyed helping talented interns make
their first open source contributions and some former interns continue
to participate today.

Who can mentor
----------------------
Regular contributors to QEMU and KVM can participate as mentors.
Mentorship involves about 5 hours of time commitment per week to
communicate with the intern, review their patches, etc. Time is also
required during the intern selection phase to communicate with
applicants. Being a mentor is an opportunity to help someone get
started in open source development, will give you experience with
managing a project in a low-stakes environment, and a chance to
explore interesting technical ideas that you may not have time to
develop yourself.

How to propose your idea
------------------------------
Reply to this email with the following project idea template filled in:

=== TITLE ===

'''Summary:''' Short description of the project

Detailed description of the project that explains the general idea,
including a list of high-level tasks that will be completed by the
project, and provides enough background for someone unfamiliar with
the code base to research the idea. Typically 2 or 3 paragraphs.

'''Links:'''
* Links to mailing lists threads, git repos, or web sites

'''Details:'''
* Skill level: beginner or intermediate or advanced
* Language: C/Python/Rust/etc

More information
----------------------
You can find out about the process we follow here:
Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf

The QEMU wiki page for GSoC 2024 is now available:
https://wiki.qemu.org/Google_Summer_of_Code_2025

What about Outreachy?
-------------------------------
We have struggled to find sponsors for the Outreachy internship
program (https://www.outreachy.org/) in recent years. If you or your
organization would like to sponsor an Outreachy internship, please get
in touch.

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Stefano Garzarella]

+Cc rust-vmm ML, since in past years we have used QEMU as an umbrella
project for rust-vmm ideas for GSoC.

Thanks,
Stefano

On Tue, 28 Jan 2025 at 17:17, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> February 7th.
>
> About Google Summer of Code
> -----------------------------------------
> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> source remote work internships to eligible people wishing to participate
> in open source development. QEMU has been doing internship for
> many years. Our mentors have enjoyed helping talented interns make
> their first open source contributions and some former interns continue
> to participate today.
>
> Who can mentor
> ----------------------
> Regular contributors to QEMU and KVM can participate as mentors.
> Mentorship involves about 5 hours of time commitment per week to
> communicate with the intern, review their patches, etc. Time is also
> required during the intern selection phase to communicate with
> applicants. Being a mentor is an opportunity to help someone get
> started in open source development, will give you experience with
> managing a project in a low-stakes environment, and a chance to
> explore interesting technical ideas that you may not have time to
> develop yourself.
>
> How to propose your idea
> ------------------------------
> Reply to this email with the following project idea template filled in:
>
> === TITLE ===
>
> '''Summary:''' Short description of the project
>
> Detailed description of the project that explains the general idea,
> including a list of high-level tasks that will be completed by the
> project, and provides enough background for someone unfamiliar with
> the code base to research the idea. Typically 2 or 3 paragraphs.
>
> '''Links:'''
> * Links to mailing lists threads, git repos, or web sites
>
> '''Details:'''
> * Skill level: beginner or intermediate or advanced
> * Language: C/Python/Rust/etc
>
> More information
> ----------------------
> You can find out about the process we follow here:
> Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
> Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
>
> The QEMU wiki page for GSoC 2024 is now available:
> https://wiki.qemu.org/Google_Summer_of_Code_2025
>
> What about Outreachy?
> -------------------------------
> We have struggled to find sponsors for the Outreachy internship
> program (https://www.outreachy.org/) in recent years. If you or your
> organization would like to sponsor an Outreachy internship, please get
> in touch.
>
> Thanks,
> Stefan
>

RE: Call for GSoC internship project ideas

[Jamin Lin]

+ Troy

************* Email Confidentiality Notice ********************
免責聲明:
本信件(或其附件)可能包含機密資訊，並受法律保護。如 台端非指定之收件者，請以電子郵件通知本電子郵件之發送者, 並請立即刪除本電子郵件及其附件和銷毀所有複印件。謝謝您的合作!

DISCLAIMER:
This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you. 

> -----Original Message-----
> From: Stefano Garzarella <sgarzare@redhat.com>
> Sent: Thursday, January 30, 2025 1:44 AM
> To: Rust-VMM Mailing List <rust-vmm@lists.opendev.org>
> Cc: Stefan Hajnoczi <stefanha@gmail.com>; qemu-devel
> <qemu-devel@nongnu.org>; kvm <kvm@vger.kernel.org>; Richard Henderson
> <richard.henderson@linaro.org>; Philippe Mathieu-Daudé
> <philmd@linaro.org>; Peter Maydell <peter.maydell@linaro.org>; Paolo
> Bonzini <pbonzini@redhat.com>; Thomas Huth <thuth@redhat.com>; Daniel P.
> Berrange <berrange@redhat.com>; Pierrick Bouvier
> <pierrick.bouvier@linaro.org>; Alex Bennee <alex.bennee@linaro.org>;
> Akihiko Odaki <akihiko.odaki@gmail.com>; Zhao Liu <zhao1.liu@intel.com>;
> Bibo Mao <maobibo@loongson.cn>; Jamin Lin <jamin_lin@aspeedtech.com>;
> Cédric Le Goater <clg@redhat.com>; Fabiano Rosas <farosas@suse.de>;
> Palmer Dabbelt <palmer@dabbelt.com>; Eugenio Pérez
> <eperezma@redhat.com>; Hanna Reitz <hreitz@redhat.com>
> Subject: Re: Call for GSoC internship project ideas
> 
> +Cc rust-vmm ML, since in past years we have used QEMU as an umbrella
> project for rust-vmm ideas for GSoC.
> 
> Thanks,
> Stefano
> 
> On Tue, 28 Jan 2025 at 17:17, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship program again
> > this year. Regular contributors can submit project ideas that they'd
> > like to mentor by replying to this email by February 7th.
> >
> > About Google Summer of Code
> > -----------------------------------------
> > GSoC (https://summerofcode.withgoogle.com/) offers paid open source
> > remote work internships to eligible people wishing to participate in
> > open source development. QEMU has been doing internship for many
> > years. Our mentors have enjoyed helping talented interns make their
> > first open source contributions and some former interns continue to
> > participate today.
> >
> > Who can mentor
> > ----------------------
> > Regular contributors to QEMU and KVM can participate as mentors.
> > Mentorship involves about 5 hours of time commitment per week to
> > communicate with the intern, review their patches, etc. Time is also
> > required during the intern selection phase to communicate with
> > applicants. Being a mentor is an opportunity to help someone get
> > started in open source development, will give you experience with
> > managing a project in a low-stakes environment, and a chance to
> > explore interesting technical ideas that you may not have time to
> > develop yourself.
> >
> > How to propose your idea
> > ------------------------------
> > Reply to this email with the following project idea template filled in:
> >
> > === TITLE ===
> >
> > '''Summary:''' Short description of the project
> >
> > Detailed description of the project that explains the general idea,
> > including a list of high-level tasks that will be completed by the
> > project, and provides enough background for someone unfamiliar with
> > the code base to research the idea. Typically 2 or 3 paragraphs.
> >
> > '''Links:'''
> > * Links to mailing lists threads, git repos, or web sites
> >
> > '''Details:'''
> > * Skill level: beginner or intermediate or advanced
> > * Language: C/Python/Rust/etc
> >
> > More information
> > ----------------------
> > You can find out about the process we follow here:
> > Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
> > Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> >
> > The QEMU wiki page for GSoC 2024 is now available:
> > https://wiki.qemu.org/Google_Summer_of_Code_2025
> >
> > What about Outreachy?
> > -------------------------------
> > We have struggled to find sponsors for the Outreachy internship
> > program (https://www.outreachy.org/) in recent years. If you or your
> > organization would like to sponsor an Outreachy internship, please get
> > in touch.
> >
> > Thanks,
> > Stefan
> >

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

On Tue, Jan 28, 2025 at 11:16:43AM -0500, Stefan Hajnoczi wrote:
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> February 7th.
> 
> About Google Summer of Code
> -----------------------------------------
> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> source remote work internships to eligible people wishing to participate
> in open source development. QEMU has been doing internship for
> many years. Our mentors have enjoyed helping talented interns make
> their first open source contributions and some former interns continue
> to participate today.
> 
> Who can mentor
> ----------------------
> Regular contributors to QEMU and KVM can participate as mentors.
> Mentorship involves about 5 hours of time commitment per week to
> communicate with the intern, review their patches, etc. Time is also
> required during the intern selection phase to communicate with
> applicants. Being a mentor is an opportunity to help someone get
> started in open source development, will give you experience with
> managing a project in a low-stakes environment, and a chance to
> explore interesting technical ideas that you may not have time to
> develop yourself.
> 
> How to propose your idea
> ------------------------------
> Reply to this email with the following project idea template filled in:
> 
> === TITLE ===
> 
> '''Summary:''' Short description of the project
> 
> Detailed description of the project that explains the general idea,
> including a list of high-level tasks that will be completed by the
> project, and provides enough background for someone unfamiliar with
> the code base to research the idea. Typically 2 or 3 paragraphs.
> 
> '''Links:'''
> * Links to mailing lists threads, git repos, or web sites
> 
> '''Details:'''
> * Skill level: beginner or intermediate or advanced
> * Language: C/Python/Rust/etc
> 
> More information
> ----------------------
> You can find out about the process we follow here:
> Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
> Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> 
> The QEMU wiki page for GSoC 2024 is now available:
> https://wiki.qemu.org/Google_Summer_of_Code_2025
> 
> What about Outreachy?
> -------------------------------
> We have struggled to find sponsors for the Outreachy internship
> program (https://www.outreachy.org/) in recent years. If you or your
> organization would like to sponsor an Outreachy internship, please get
> in touch.
> 
> Thanks,
> Stefan

=== Adding Kani proofs for Virtqueues in Rust-vmm ===

'''Summary:''' Verify conformance of the virtqueue implementation in
rust-vmm to the VirtIO specification.

In the rust-vmm project, devices rely on the virtqueue implementation
provided by the `vm-virtio` crate. This implementation is based on the
VirtIO specification, which defines the behavior and requirements for
virtqueues. To ensure that the implementation meets these
specifications, we have been relying on unit tests that check the output
of the code given specific inputs.

However, writing unit tests can be incomplete, as it's challenging to
cover all possible scenarios and edge cases. During this internship, we
propose a more comprehensive approach: using Kani proofs to verify that
the virtqueue implementation conforms to the VirtIO specification.

Kani allows us to write exhaustive checks for all possible values, going
beyond what unit tests can achieve. By writing Kani proofs, we can
confirm that our implementation meets the requirements of the VirtIO
specification. If a proof passes, it provides strong evidence that the
virtqueue implementation is correct and conformant.

During the internship, we propose the following tasks:
- Get familiar with Kani proofs written for Firecraker
- Finish current PR that adds a proof for the notification suppression
  mechanism (see [2])
- Port add_used() proof (see [5])
- Port verify_prepare_kick() proof (see [6])

'''Links:'''
  * [1] Kani source code - https://github.com/model-checking/kani/
  * [2] Notification suppression mechanism PR -
    https://github.com/rust-vmm/vm-virtio/pull/324
  * [3] LPC Talk about how we may check conformance in the VirtIO
    specification - https://www.youtube.com/watch?v=w7BAR228344
  * [4] FOSDEM'25 talk current effort to use Kani -
    https://fosdem.org/2025/schedule/event/fosdem-2025-5930-hunting-virtio-specification-violations/
  * [5] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L1006
  * [6] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L966
 
'''Details:'''
  * Skill level: intermediate
  * Language: Rust 

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Thu, Feb 6, 2025 at 4:34 AM Matias Ezequiel Vara Larsen
<mvaralar@redhat.com> wrote:
> === Adding Kani proofs for Virtqueues in Rust-vmm ===
>
> '''Summary:''' Verify conformance of the virtqueue implementation in
> rust-vmm to the VirtIO specification.
>
> In the rust-vmm project, devices rely on the virtqueue implementation
> provided by the `vm-virtio` crate. This implementation is based on the
> VirtIO specification, which defines the behavior and requirements for
> virtqueues. To ensure that the implementation meets these
> specifications, we have been relying on unit tests that check the output
> of the code given specific inputs.
>
> However, writing unit tests can be incomplete, as it's challenging to
> cover all possible scenarios and edge cases. During this internship, we
> propose a more comprehensive approach: using Kani proofs to verify that
> the virtqueue implementation conforms to the VirtIO specification.
>
> Kani allows us to write exhaustive checks for all possible values, going
> beyond what unit tests can achieve. By writing Kani proofs, we can
> confirm that our implementation meets the requirements of the VirtIO
> specification. If a proof passes, it provides strong evidence that the
> virtqueue implementation is correct and conformant.
>
> During the internship, we propose the following tasks:
> - Get familiar with Kani proofs written for Firecraker
> - Finish current PR that adds a proof for the notification suppression
>   mechanism (see [2])
> - Port add_used() proof (see [5])
> - Port verify_prepare_kick() proof (see [6])

add_used(), verify_prepare_kick(), and notification suppression are
explicitly named. Firecracker's queue.rs has proofs for a number of
other proofs as well. Would it be possible to work on them if there is
time remaining, or is there a reason why only the proofs you mentioned
can be ported?

I'm asking because a 12-week internship is likely to leave enough time
to tackle more than 3 proofs.

Stefan

>
> '''Links:'''
>   * [1] Kani source code - https://github.com/model-checking/kani/
>   * [2] Notification suppression mechanism PR -
>     https://github.com/rust-vmm/vm-virtio/pull/324
>   * [3] LPC Talk about how we may check conformance in the VirtIO
>     specification - https://www.youtube.com/watch?v=w7BAR228344
>   * [4] FOSDEM'25 talk current effort to use Kani -
>     https://fosdem.org/2025/schedule/event/fosdem-2025-5930-hunting-virtio-specification-violations/
>   * [5] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L1006
>   * [6] https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add07807f75d923cc3d3cd210/src/vmm/src/devices/virtio/queue.rs#L966
>
> '''Details:'''
>   * Skill level: intermediate
>   * Language: Rust
>

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

I have added your project idea to the wiki. Please make further
changes directly on the wiki.

https://wiki.qemu.org/Google_Summer_of_Code_2025#Adding_Kani_proofs_for_Virtqueues_in_Rust-vmm

Thanks,
Stefan

Re: Call for GSoC internship project ideas

[Hanna Czenczek]

On 28.01.25 17:16, Stefan Hajnoczi wrote:
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code internship
> program again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email by
> February 7th.
>
> About Google Summer of Code
> -----------------------------------------
> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> source remote work internships to eligible people wishing to participate
> in open source development. QEMU has been doing internship for
> many years. Our mentors have enjoyed helping talented interns make
> their first open source contributions and some former interns continue
> to participate today.
>
> Who can mentor
> ----------------------
> Regular contributors to QEMU and KVM can participate as mentors.
> Mentorship involves about 5 hours of time commitment per week to
> communicate with the intern, review their patches, etc. Time is also
> required during the intern selection phase to communicate with
> applicants. Being a mentor is an opportunity to help someone get
> started in open source development, will give you experience with
> managing a project in a low-stakes environment, and a chance to
> explore interesting technical ideas that you may not have time to
> develop yourself.
>
> How to propose your idea
> ------------------------------
> Reply to this email with the following project idea template filled in:
>
> === TITLE ===
>
> '''Summary:''' Short description of the project
>
> Detailed description of the project that explains the general idea,
> including a list of high-level tasks that will be completed by the
> project, and provides enough background for someone unfamiliar with
> the code base to research the idea. Typically 2 or 3 paragraphs.
>
> '''Links:'''
> * Links to mailing lists threads, git repos, or web sites
>
> '''Details:'''
> * Skill level: beginner or intermediate or advanced
> * Language: C/Python/Rust/etc

=== Asynchronous request handling for virtiofsd ===

'''Summary:''' Make virtiofsd’s request handling asynchronous, allowing 
single-threaded parallel request processing.

virtiofsd is a virtio-fs device implementation, i.e. grants VM guests 
access to host directories. In its current state, it processes guest 
requests one by one, which means operations of long duration will block 
processing of others that could be processed more quickly.

With asynchronous request processing, longer-lasting operations could 
continue in the background while other requests with lower latency are 
fetched and processed in parallel. This should improve performance 
especially for mixed workloads, i.e. one guest process executing 
longer-lasting filesystem operations, while another runs random small 
read requests on a single file.

Your task is to:
* Get familiar with a Linux AIO interface, preferably io_uring
* Have virtiofsd make use of that interface for its operations
* Make the virtiofsd request loop process requests asynchronously, so 
requests can be fetched and processed while others are continuing in the 
background
* Evaluate the resulting performance with different workloads

'''Links:'''
* virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
* virtiofsd’s filesystem operations: 
https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
* virtiofsd’s request processing loop: 
https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244

'''Details:'''
* Skill level: intermediate
* Language: Rust
* Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione 
(gmaglione@redhat.com)

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@redhat.com> wrote:
>
> On 28.01.25 17:16, Stefan Hajnoczi wrote:
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship
> > program again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email by
> > February 7th.
> >
> > About Google Summer of Code
> > -----------------------------------------
> > GSoC (https://summerofcode.withgoogle.com/) offers paid open
> > source remote work internships to eligible people wishing to participate
> > in open source development. QEMU has been doing internship for
> > many years. Our mentors have enjoyed helping talented interns make
> > their first open source contributions and some former interns continue
> > to participate today.
> >
> > Who can mentor
> > ----------------------
> > Regular contributors to QEMU and KVM can participate as mentors.
> > Mentorship involves about 5 hours of time commitment per week to
> > communicate with the intern, review their patches, etc. Time is also
> > required during the intern selection phase to communicate with
> > applicants. Being a mentor is an opportunity to help someone get
> > started in open source development, will give you experience with
> > managing a project in a low-stakes environment, and a chance to
> > explore interesting technical ideas that you may not have time to
> > develop yourself.
> >
> > How to propose your idea
> > ------------------------------
> > Reply to this email with the following project idea template filled in:
> >
> > === TITLE ===
> >
> > '''Summary:''' Short description of the project
> >
> > Detailed description of the project that explains the general idea,
> > including a list of high-level tasks that will be completed by the
> > project, and provides enough background for someone unfamiliar with
> > the code base to research the idea. Typically 2 or 3 paragraphs.
> >
> > '''Links:'''
> > * Links to mailing lists threads, git repos, or web sites
> >
> > '''Details:'''
> > * Skill level: beginner or intermediate or advanced
> > * Language: C/Python/Rust/etc
>
> === Asynchronous request handling for virtiofsd ===
>
> '''Summary:''' Make virtiofsd’s request handling asynchronous, allowing
> single-threaded parallel request processing.
>
> virtiofsd is a virtio-fs device implementation, i.e. grants VM guests
> access to host directories. In its current state, it processes guest
> requests one by one, which means operations of long duration will block
> processing of others that could be processed more quickly.
>
> With asynchronous request processing, longer-lasting operations could
> continue in the background while other requests with lower latency are
> fetched and processed in parallel. This should improve performance
> especially for mixed workloads, i.e. one guest process executing
> longer-lasting filesystem operations, while another runs random small
> read requests on a single file.
>
> Your task is to:
> * Get familiar with a Linux AIO interface, preferably io_uring
> * Have virtiofsd make use of that interface for its operations
> * Make the virtiofsd request loop process requests asynchronously, so
> requests can be fetched and processed while others are continuing in the
> background
> * Evaluate the resulting performance with different workloads
>
> '''Links:'''
> * virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
> * virtiofsd’s filesystem operations:
> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
> * virtiofsd’s request processing loop:
> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244
>
> '''Details:'''
> * Skill level: intermediate
> * Language: Rust
> * Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione
> (gmaglione@redhat.com)

Thanks, I have added your project idea to the list:
https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd

Do you want to give any guidance on which crate to use for
asynchronous I/O? Do you want async Rust (e.g. tokio) or not?

Stefan

Re: Call for GSoC internship project ideas

[Hanna Czenczek]

On 07.02.25 14:41, Stefan Hajnoczi wrote:
> On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@redhat.com> wrote:
>> On 28.01.25 17:16, Stefan Hajnoczi wrote:
>>> Dear QEMU and KVM communities,
>>> QEMU will apply for the Google Summer of Code internship
>>> program again this year. Regular contributors can submit project
>>> ideas that they'd like to mentor by replying to this email by
>>> February 7th.
>>>
>>> About Google Summer of Code
>>> -----------------------------------------
>>> GSoC (https://summerofcode.withgoogle.com/) offers paid open
>>> source remote work internships to eligible people wishing to participate
>>> in open source development. QEMU has been doing internship for
>>> many years. Our mentors have enjoyed helping talented interns make
>>> their first open source contributions and some former interns continue
>>> to participate today.
>>>
>>> Who can mentor
>>> ----------------------
>>> Regular contributors to QEMU and KVM can participate as mentors.
>>> Mentorship involves about 5 hours of time commitment per week to
>>> communicate with the intern, review their patches, etc. Time is also
>>> required during the intern selection phase to communicate with
>>> applicants. Being a mentor is an opportunity to help someone get
>>> started in open source development, will give you experience with
>>> managing a project in a low-stakes environment, and a chance to
>>> explore interesting technical ideas that you may not have time to
>>> develop yourself.
>>>
>>> How to propose your idea
>>> ------------------------------
>>> Reply to this email with the following project idea template filled in:
>>>
>>> === TITLE ===
>>>
>>> '''Summary:''' Short description of the project
>>>
>>> Detailed description of the project that explains the general idea,
>>> including a list of high-level tasks that will be completed by the
>>> project, and provides enough background for someone unfamiliar with
>>> the code base to research the idea. Typically 2 or 3 paragraphs.
>>>
>>> '''Links:'''
>>> * Links to mailing lists threads, git repos, or web sites
>>>
>>> '''Details:'''
>>> * Skill level: beginner or intermediate or advanced
>>> * Language: C/Python/Rust/etc
>> === Asynchronous request handling for virtiofsd ===
>>
>> '''Summary:''' Make virtiofsd’s request handling asynchronous, allowing
>> single-threaded parallel request processing.
>>
>> virtiofsd is a virtio-fs device implementation, i.e. grants VM guests
>> access to host directories. In its current state, it processes guest
>> requests one by one, which means operations of long duration will block
>> processing of others that could be processed more quickly.
>>
>> With asynchronous request processing, longer-lasting operations could
>> continue in the background while other requests with lower latency are
>> fetched and processed in parallel. This should improve performance
>> especially for mixed workloads, i.e. one guest process executing
>> longer-lasting filesystem operations, while another runs random small
>> read requests on a single file.
>>
>> Your task is to:
>> * Get familiar with a Linux AIO interface, preferably io_uring
>> * Have virtiofsd make use of that interface for its operations
>> * Make the virtiofsd request loop process requests asynchronously, so
>> requests can be fetched and processed while others are continuing in the
>> background
>> * Evaluate the resulting performance with different workloads
>>
>> '''Links:'''
>> * virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
>> * virtiofsd’s filesystem operations:
>> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
>> * virtiofsd’s request processing loop:
>> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244
>>
>> '''Details:'''
>> * Skill level: intermediate
>> * Language: Rust
>> * Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione
>> (gmaglione@redhat.com)
> Thanks, I have added your project idea to the list:
> https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd

Thanks!

> Do you want to give any guidance on which crate to use for
> asynchronous I/O? Do you want async Rust (e.g. tokio) or not?

That would depend entirely on the student.  I’m open for async Rust 
(tokio or even homegrown), but they could also decide they’d rather do 
it in some different manner (e.g. with callbacks that would return 
descriptors to the guest).  I’ll add that info, if that’s OK.

Hanna

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Fri, Feb 7, 2025 at 8:48 AM Hanna Czenczek <hreitz@redhat.com> wrote:
>
> On 07.02.25 14:41, Stefan Hajnoczi wrote:
> > On Fri, Feb 7, 2025 at 7:35 AM Hanna Czenczek <hreitz@redhat.com> wrote:
> >> On 28.01.25 17:16, Stefan Hajnoczi wrote:
> >>> Dear QEMU and KVM communities,
> >>> QEMU will apply for the Google Summer of Code internship
> >>> program again this year. Regular contributors can submit project
> >>> ideas that they'd like to mentor by replying to this email by
> >>> February 7th.
> >>>
> >>> About Google Summer of Code
> >>> -----------------------------------------
> >>> GSoC (https://summerofcode.withgoogle.com/) offers paid open
> >>> source remote work internships to eligible people wishing to participate
> >>> in open source development. QEMU has been doing internship for
> >>> many years. Our mentors have enjoyed helping talented interns make
> >>> their first open source contributions and some former interns continue
> >>> to participate today.
> >>>
> >>> Who can mentor
> >>> ----------------------
> >>> Regular contributors to QEMU and KVM can participate as mentors.
> >>> Mentorship involves about 5 hours of time commitment per week to
> >>> communicate with the intern, review their patches, etc. Time is also
> >>> required during the intern selection phase to communicate with
> >>> applicants. Being a mentor is an opportunity to help someone get
> >>> started in open source development, will give you experience with
> >>> managing a project in a low-stakes environment, and a chance to
> >>> explore interesting technical ideas that you may not have time to
> >>> develop yourself.
> >>>
> >>> How to propose your idea
> >>> ------------------------------
> >>> Reply to this email with the following project idea template filled in:
> >>>
> >>> === TITLE ===
> >>>
> >>> '''Summary:''' Short description of the project
> >>>
> >>> Detailed description of the project that explains the general idea,
> >>> including a list of high-level tasks that will be completed by the
> >>> project, and provides enough background for someone unfamiliar with
> >>> the code base to research the idea. Typically 2 or 3 paragraphs.
> >>>
> >>> '''Links:'''
> >>> * Links to mailing lists threads, git repos, or web sites
> >>>
> >>> '''Details:'''
> >>> * Skill level: beginner or intermediate or advanced
> >>> * Language: C/Python/Rust/etc
> >> === Asynchronous request handling for virtiofsd ===
> >>
> >> '''Summary:''' Make virtiofsd’s request handling asynchronous, allowing
> >> single-threaded parallel request processing.
> >>
> >> virtiofsd is a virtio-fs device implementation, i.e. grants VM guests
> >> access to host directories. In its current state, it processes guest
> >> requests one by one, which means operations of long duration will block
> >> processing of others that could be processed more quickly.
> >>
> >> With asynchronous request processing, longer-lasting operations could
> >> continue in the background while other requests with lower latency are
> >> fetched and processed in parallel. This should improve performance
> >> especially for mixed workloads, i.e. one guest process executing
> >> longer-lasting filesystem operations, while another runs random small
> >> read requests on a single file.
> >>
> >> Your task is to:
> >> * Get familiar with a Linux AIO interface, preferably io_uring
> >> * Have virtiofsd make use of that interface for its operations
> >> * Make the virtiofsd request loop process requests asynchronously, so
> >> requests can be fetched and processed while others are continuing in the
> >> background
> >> * Evaluate the resulting performance with different workloads
> >>
> >> '''Links:'''
> >> * virtiofsd repository: https://gitlab.com/virtio-fs/virtiofsd
> >> * virtiofsd’s filesystem operations:
> >> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/passthrough/mod.rs#L1490
> >> * virtiofsd’s request processing loop:
> >> https://gitlab.com/virtio-fs/virtiofsd/-/blob/main/src/vhost_user.rs#L244
> >>
> >> '''Details:'''
> >> * Skill level: intermediate
> >> * Language: Rust
> >> * Mentors: Hanna Czenczek (hreitz@redhat.com), German Maglione
> >> (gmaglione@redhat.com)
> > Thanks, I have added your project idea to the list:
> > https://wiki.qemu.org/Google_Summer_of_Code_2025#Asynchronous_request_handling_for_virtiofsd
>
> Thanks!
>
> > Do you want to give any guidance on which crate to use for
> > asynchronous I/O? Do you want async Rust (e.g. tokio) or not?
>
> That would depend entirely on the student.  I’m open for async Rust
> (tokio or even homegrown), but they could also decide they’d rather do
> it in some different manner (e.g. with callbacks that would return
> descriptors to the guest).  I’ll add that info, if that’s OK.

Sounds good.

Stefan

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

On Thu, Feb 06, 2025 at 10:02:43AM -0500, Stefan Hajnoczi wrote:
> On Thu, Feb 6, 2025 at 4:34 AM Matias Ezequiel Vara Larsen
> <mvaralar@redhat.com> wrote:
> > === Adding Kani proofs for Virtqueues in Rust-vmm ===
> >
> > '''Summary:''' Verify conformance of the virtqueue implementation in
> > rust-vmm to the VirtIO specification.
> >
> > In the rust-vmm project, devices rely on the virtqueue implementation
> > provided by the `vm-virtio` crate. This implementation is based on the
> > VirtIO specification, which defines the behavior and requirements for
> > virtqueues. To ensure that the implementation meets these
> > specifications, we have been relying on unit tests that check the output
> > of the code given specific inputs.
> >
> > However, writing unit tests can be incomplete, as it's challenging to
> > cover all possible scenarios and edge cases. During this internship, we
> > propose a more comprehensive approach: using Kani proofs to verify that
> > the virtqueue implementation conforms to the VirtIO specification.
> >
> > Kani allows us to write exhaustive checks for all possible values, going
> > beyond what unit tests can achieve. By writing Kani proofs, we can
> > confirm that our implementation meets the requirements of the VirtIO
> > specification. If a proof passes, it provides strong evidence that the
> > virtqueue implementation is correct and conformant.
> >
> > During the internship, we propose the following tasks:
> > - Get familiar with Kani proofs written for Firecraker
> > - Finish current PR that adds a proof for the notification suppression
> >   mechanism (see [2])
> > - Port add_used() proof (see [5])
> > - Port verify_prepare_kick() proof (see [6])
> 
> add_used(), verify_prepare_kick(), and notification suppression are
> explicitly named. Firecracker's queue.rs has proofs for a number of
> other proofs as well. Would it be possible to work on them if there is
> time remaining, or is there a reason why only the proofs you mentioned
> can be ported?
> 

I though that those three proofs were the more interesting. I think we
can cover all the proofs in queue.rs during the internship.

Matias

Re: Call for GSoC internship project ideas

[Matias Ezequiel Vara Larsen]

On Thu, Feb 06, 2025 at 10:10:54AM -0500, Stefan Hajnoczi wrote:
> I have added your project idea to the wiki. Please make further
> changes directly on the wiki.
> 
> https://wiki.qemu.org/Google_Summer_of_Code_2025#Adding_Kani_proofs_for_Virtqueues_in_Rust-vmm
> 
> Thanks,
> Stefan
> 

Thanks,

Matias.

Re: Call for GSoC internship project ideas

[Helge Deller]

Hi Stefan,

On 1/28/25 17:16, Stefan Hajnoczi wrote:
> How to propose your idea
> ------------------------------
> Reply to this email with the following project idea template filled in:

Would something like this be acceptable?


=== Develop a driver to emulate an existing network-, scsi- or graphic-card in software ===

'''Summary:''' Develop a driver for Qemu to emulate an old network-, SCSI- or graphic card in software

Qemu allows to emulate a lot of physical machines. Beside widely used
x86 machines as used with KVM, this includes historic machines
based on PowerPC, Alpha or HP PA-RISC CPUs too.
To allow to emulate additional specific historic machine models,
drivers to emulate specific hardware like network-, SCSI- or graphic
cards need to be developed.
This project is about to develop such a driver for the historic
HP PA-RISC architecture, e.g. for the "LASI" network card, or
a driver to emulate a "classic" first-generation NCR 710 SCSI controller.

'''Links:'''
* https://parisc.docs.kernel.org/en/latest/technical_documentation.html
* existing Linux kernel drivers

'''Details:'''
* Skill level: advanced
* Language: C

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Fri, Feb 7, 2025 at 9:39 AM Helge Deller <deller@gmx.de> wrote:
>
> Hi Stefan,
>
> On 1/28/25 17:16, Stefan Hajnoczi wrote:
> > How to propose your idea
> > ------------------------------
> > Reply to this email with the following project idea template filled in:
>
> Would something like this be acceptable?

Yes, it would be great to have an emulation project idea like this!

Please choose exactly which device you'd like them to implement.
Interns may not be knowledgeable in the field yet and you actually
help by setting limitations.

Link to the specific device's datasheet, existing open source driver
example, internal QEMU APIs needed to implement this type of device,
etc so that it's easy for an applicant to investigate the idea and
decide whether or not to apply.

Stefan

>
> === Develop a driver to emulate an existing network-, scsi- or graphic-card in software ===
>
> '''Summary:''' Develop a driver for Qemu to emulate an old network-, SCSI- or graphic card in software
>
> Qemu allows to emulate a lot of physical machines. Beside widely used
> x86 machines as used with KVM, this includes historic machines
> based on PowerPC, Alpha or HP PA-RISC CPUs too.
> To allow to emulate additional specific historic machine models,
> drivers to emulate specific hardware like network-, SCSI- or graphic
> cards need to be developed.
> This project is about to develop such a driver for the historic
> HP PA-RISC architecture, e.g. for the "LASI" network card, or
> a driver to emulate a "classic" first-generation NCR 710 SCSI controller.
>
> '''Links:'''
> * https://parisc.docs.kernel.org/en/latest/technical_documentation.html
> * existing Linux kernel drivers
>
> '''Details:'''
> * Skill level: advanced
> * Language: C

Re: Call for GSoC internship project ideas

[Helge Deller]

On 2/7/25 15:47, Stefan Hajnoczi wrote:
> On Fri, Feb 7, 2025 at 9:39 AM Helge Deller <deller@gmx.de> wrote:
>>
>> Hi Stefan,
>>
>> On 1/28/25 17:16, Stefan Hajnoczi wrote:
>>> How to propose your idea
>>> ------------------------------
>>> Reply to this email with the following project idea template filled in:
>>
>> Would something like this be acceptable?
>
> Yes, it would be great to have an emulation project idea like this!
>
> Please choose exactly which device you'd like them to implement.
> Interns may not be knowledgeable in the field yet and you actually
> help by setting limitations.
>
> Link to the specific device's datasheet, existing open source driver
> example, internal QEMU APIs needed to implement this type of device,
> etc so that it's easy for an applicant to investigate the idea and
> decide whether or not to apply.

Ok, here is an updated text:

=== Develop a driver to emulate an existing network-, scsi- or graphic-card in software ===

'''Summary:''' Develop a driver for Qemu to emulate an old network-, SCSI- or graphic card in software

Qemu allows to emulate a lot of physical machines. Beside widely used
x86 machines as used with KVM, this includes historic machines
based on PowerPC, Alpha or HP PA-RISC CPUs too.
To allow to emulate additional specific historic machine models,
drivers to emulate specific hardware like network-, SCSI- or graphic
cards need to be developed.
This project is about to develop such a driver for the historic
HP PA-RISC architecture. Based on the knowledge and interest of the
applicant, here are two non-exclusive options:
a) driver for the "LASI" network card. This is basically an Intel 82596
network chip, which was integrated into another ASIC in the HP 700 series.
That chip was used in SUN machines as well, and the full Linux driver
for the various machines can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/i825xx
A driver for Qemu exists, but it's not fully functional yet:
https://gitlab.com/qemu-project/qemu/-/blob/master/hw/net/lasi_i82596.c
https://gitlab.com/qemu-project/qemu/-/blob/master/hw/net/i82596.c
Datasheets for this chip exists too.
This project is about debugging and analyzing existing code, including
development of missing code.

b) a driver to emulate a "classic" first-generation NCR 710 SCSI controller.
Really old machines used a NCR 710 SCSI controller, for which currently
no qemu driver exists.
Qemu has a LSI53C895A driver, which partly even allows to
emulate a LSI53C810 too, but those chips are "too new" and as such
are not accepted and supported on old operating systems (e.g. HP-UX9).
The WinUAE project seem to have modified the existing qemu driver
to emulate a NCR710 to support the Amiga:
https://github.com/tonioni/WinUAE/blob/master/qemuvga/lsi53c710.cpp
The goal of this project should be to develop a nice & clean NCR710
driver which is acceptable to include in qemu source code repository.

'''Links:'''
* https://parisc.docs.kernel.org/en/latest/technical_documentation.html
* existing Linux kernel drivers

'''Details:'''
* Skill level: advanced
* Language: C

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Fri, Feb 7, 2025 at 10:34 AM Helge Deller <deller@gmx.de> wrote:
>
> On 2/7/25 15:47, Stefan Hajnoczi wrote:
> > On Fri, Feb 7, 2025 at 9:39 AM Helge Deller <deller@gmx.de> wrote:
> >>
> >> Hi Stefan,
> >>
> >> On 1/28/25 17:16, Stefan Hajnoczi wrote:
> >>> How to propose your idea
> >>> ------------------------------
> >>> Reply to this email with the following project idea template filled in:
> >>
> >> Would something like this be acceptable?
> >
> > Yes, it would be great to have an emulation project idea like this!
> >
> > Please choose exactly which device you'd like them to implement.
> > Interns may not be knowledgeable in the field yet and you actually
> > help by setting limitations.
> >
> > Link to the specific device's datasheet, existing open source driver
> > example, internal QEMU APIs needed to implement this type of device,
> > etc so that it's easy for an applicant to investigate the idea and
> > decide whether or not to apply.
>
> Ok, here is an updated text:

Thanks, I have added it to the project ideas list with some edits:
https://wiki.qemu.org/Google_Summer_of_Code_2025#Implement_LASI_network_card_and/or_NCR_710_SCSI_controller_device_models

Feel free to update the project description on the wiki!

Stefan

Re: Call for GSoC internship project ideas

[Stefano Garzarella]

Hi Stefan,
Sorry for the delay, I attach a proposal!

On Wed, 29 Jan 2025 at 18:44, Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> +Cc rust-vmm ML, since in past years we have used QEMU as an umbrella
> project for rust-vmm ideas for GSoC.
>
> Thanks,
> Stefano
>
> On Tue, 28 Jan 2025 at 17:17, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code internship
> > program again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email by
> > February 7th.
> >
> > About Google Summer of Code
> > -----------------------------------------
> > GSoC (https://summerofcode.withgoogle.com/) offers paid open
> > source remote work internships to eligible people wishing to participate
> > in open source development. QEMU has been doing internship for
> > many years. Our mentors have enjoyed helping talented interns make
> > their first open source contributions and some former interns continue
> > to participate today.
> >
> > Who can mentor
> > ----------------------
> > Regular contributors to QEMU and KVM can participate as mentors.
> > Mentorship involves about 5 hours of time commitment per week to
> > communicate with the intern, review their patches, etc. Time is also
> > required during the intern selection phase to communicate with
> > applicants. Being a mentor is an opportunity to help someone get
> > started in open source development, will give you experience with
> > managing a project in a low-stakes environment, and a chance to
> > explore interesting technical ideas that you may not have time to
> > develop yourself.
> >
> > How to propose your idea
> > ------------------------------
> > Reply to this email with the following project idea template filled in:


=== vhost-user devices in Rust on macOS and *BSD ===

'''Summary:''' Extend rust-vmm crates to support vhost-user devices 
running on POSIX system like macOS and *BSD

VIRTIO devices can be emulated in an external process to QEMU thanks to 
the vhost-user protocol, which allows QEMU to offload the entire 
emulation to a daemon. This is done through an AF_UNIX socket used as a 
control path between the frontend (i.e. QEMU) and the backend (i.e. the 
vhost-user daemon). QEMU will share guest memory with the daemon, 
provide all the information for data path setup, and notification 
mechanisms.

Moving the emulation of VIRTIO devices to a separate process from QEMU 
offers significant advantages, primarily in terms of safety, if a device 
crashes, we can restart it without affecting QEMU. Additionally, this 
approach simplifies updating device implementations, allows development 
in other languages (such as Rust as we do in the rust-vmm community), 
and enhances isolation through seccomp, cgroups, and similar mechanisms.

The rust-vmm community already provides several crates (e.g. vhost, 
vhost-user-backend, etc.) to implement a vhost-user backend in an 
external daemon. For example, these crates are used by virtiofsd 
(virtio-fs vhost-user device) but also by all vhost-user devices 
maintained by the rust-vmm community in the rust-vmm/vhost-device 
workspace. These crates work great on Linux, but unfortunately they use 
some Linux-specific system calls such as epoll(7) and eventfd(2) that 
make them impossible to use on other POSIX systems.

The goal of this project is to make sure that we can use rust-vmm's 
vhost and vhost-user-backend crates on other POSIX systems besides 
Linux. If time permits, we could also fix up simple devices such as 
vhost-device-console or vhost-device-vsock to run on any POSIX systems.

'''Tasks:'''
* Becoming familiar with QEMU and vhost-user devices
* Run QEMU with a vhost-user device on macOS or FreeBSD/OpenBSD as 
covered in the FOSDEM 2025 talk
* Analyze rust-vmm crates (vmm-sys-util, vhost, vhost-user-backend) to 
understand which components are Linux-specific
* Replace epoll(7) with alternatives such as 
https://github.com/smol-rs/polling
* Automatic fallback to pipe()/pipe2() if eventfd(2) is not available as 
QEMU already does
* Handle any other cases discovered during the analysis
* Adapt a simple device such as vhost-device-console or 
vhost-device-vsock to test that everything works on macOS or 
FreeBSD/OpenBSD

'''Links:'''
* FOSDEM 2025 talk: [https://fosdem.org/2025/schedule/event/fosdem-2025-5100-can-qemu-and-vhost-user-devices-be-used-on-macos-and-bsd-/ Can QEMU and vhost-user devices be used on macOS and *BSD?]
* [https://qemu-project.gitlab.io/qemu/interop/vhost-user.html vhost-user spacification]
* [https://patchew.org/QEMU/20240618100043.144657-1-sgarzare@redhat.com/ QEMU series to support vhost-user on any POSIX]
* [https://gitlab.com/sgarzarella/qemu/-/tree/macos-vhost-user sgarzare's tree where to find some missing QEMU patches]
* [https://github.com/rust-vmm/vhost rust-vmm vhost & vhost-user-backend crates]
* [https://github.com/rust-vmm/vmm-sys-util rust-vmm vmm-sys-util crate]
* [https://github.com/rust-vmm/vhost-device rust-vmm vhost-device workspace]
* [https://gitlab.com/virtio-fs/virtiofsd virtio-fs vhost-user device]
* [https://github.com/rust-vmm/vhost/issues/110 Mac build support #110 - rust-vmm/vhost]
* [https://gitlab.com/virtio-fs/virtiofsd/-/issues/169 Add macOS support #169 - virtio-fs/virtiofsd]

'''Details:'''
* Project size: 350 hours
* Skill level: intermediate
* Language: Rust
* Mentors: Stefano Garzarella <sgarzare@redhat.com>, German Maglione 
<gmaglione@redhat.com>


Thanks,
Stefano

Re: Call for GSoC internship project ideas

[Stefan Hajnoczi]

On Mon, Feb 10, 2025 at 9:55 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
> === vhost-user devices in Rust on macOS and *BSD ===
>
> '''Summary:''' Extend rust-vmm crates to support vhost-user devices
> running on POSIX system like macOS and *BSD

Thanks, I have added it to the wiki:
https://wiki.qemu.org/Google_Summer_of_Code_2025#vhost-user_devices_in_Rust_on_macOS_and_*BSD

Stefan