From kennelson11 at gmail.com  Thu Feb  3 18:38:37 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Thu, 3 Feb 2022 10:38:37 -0800
Subject: [Rust-VMM] PTG April 2022 Team Signup
Message-ID: <CAJ6yrQhsPVQLESeRTU9H8LyH0UOsRhuetOiSg2Dm-EB7=5jn9A@mail.gmail.com>

Hello!

Last week, we announced the next virtual PTG will be held virtually from
Monday, April 4th to Friday, April 8th, 2022. We will have the same
schedule set up available as last time with three windows of time spread
across the day to cover all timezones with breaks in between.

To signup your team, you must complete BOTH the survey[1] AND reserve time
in the ethercalc[2] by end of day March 11th.

We ask that the PTL/SIG Chair/Team lead sign up for time to have their
discussions with 3 rules/guidelines:

1. Cross project discussions (like SIGs or support project teams) should be
scheduled towards the start of the week so that any discussions that might
shape those of other teams happen first.
2. No team should sign up for more than 4 hours per UTC day to help keep
participants actively engaged.
3. No team should sign up for more than 16 hours across all time slots to
avoid burning out our contributors and to enable participation in multiple
teams discussions.

Again, you need to fill out BOTH the ethercalc AND the survey to complete
your team's sign up. If you have any issues with signing up your team, due
to conflict or otherwise,  please let me know! While we are trying to
empower you to make your own decisions as to when you meet and for how long
(after all, you know your needs and teams timezones better than we do), we
are here to help!

Once your team is signed up, please register[3]! And remind your team to
register! Registration is free, but it's important that you sign up to let
us know you'll be attending because that's how you'll receive event
details, passwords, and other relevant information about the PTG.

Continue to visit openinfra.dev/ptg for updates.

-Kendall Nelson (diablo_rojo)

[1] Team Survey:
https://openinfrafoundation.formstack.com/forms/april2022_vptg_survey
[2] Ethercalc Signup: https://ethercalc.openstack.org/7yxdas7suqnd
[3] PTG Registration: https://openinfra-ptg.eventbrite.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20220203/4333729c/attachment.htm>

From stefanha at gmail.com  Mon Feb 14 13:58:57 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Mon, 14 Feb 2022 13:58:57 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <244647ca-a247-cfc1-d0df-b8c74d434a77@amazon.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <244647ca-a247-cfc1-d0df-b8c74d434a77@amazon.com>
Message-ID: <CAJSP0QVqvvN=sbm=XMT8mxHQNcSfNfTrnWJXXf-QgXwxAfzdcA@mail.gmail.com>

On Wed, 9 Feb 2022 at 14:50, Alexander Graf <graf at amazon.com> wrote:
> On 28.01.22 16:47, Stefan Hajnoczi wrote:
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> >
> > Good project ideas are suitable for remote 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 have one that I'd absolutely *love* to see but not gotten around
> implementing myself yet :)
>
>
> Summary:
>
> Implement -M nitro-enclave in QEMU
>
> Nitro Enclaves are the first widely adopted implementation of hypervisor
> assisted compute isolation. Similar to technologies like SGX, it allows
> to spawn a separate context that is inaccessible by the parent Operating
> System. This is implemented by "giving up" resources of the parent VM
> (CPU cores, memory) to the hypervisor which then spawns a second vmm to
> execute a completely separate virtual machine. That new VM only has a
> vsock communication channel to the parent and has a built-in lightweight
> TPM.
>
> One big challenge with Nitro Enclaves is that due to its roots in
> security, there are very few debugging / introspection capabilities.
> That makes OS bringup, debugging and bootstrapping very difficult.
> Having a local dev&test environment that looks like an Enclave, but is
> 100% controlled by the developer and introspectable would make life a
> lot easier for everyone working on them. It also may pave the way to see
> Nitro Enclaves adopted in VM environments outside of EC2.
>
> This project will consist of adding a new machine model to QEMU that
> mimics a Nitro Enclave environment, including the lightweight TPM, the
> vsock communication channel and building firmware which loads the
> special "EIF" file format which contains kernel, initramfs and metadata
> from a -kernel image.
>
> Links:
>
> https://aws.amazon.com/ec2/nitro/nitro-enclaves/
> https://lore.kernel.org/lkml/20200921121732.44291-10-andraprs at amazon.com/T/
>
> Details:
>
> Skill level: intermediate - advanced (some understanding of QEMU machine
> modeling would be good)
> Language: C
> Mentor: Maybe me (Alexander Graf), depends on timelines and holiday
> season. Let's find an intern first - I promise to find a mentor then :)
> Suggested by: Alexander Graf
>
>
> Note: I don't know enough about rust-vmm's debugging capabilities. If it
> has gdbstub and a local UART that's easily usable, the project might be
> perfectly viable under its umbrella as well - written in Rust then of
> course.

It would be great to have an open source Enclave environment for
development and testing in QEMU.

Could you add a little more detail about the tasks involved. Something
along the lines of:
- Implement a device model for the TPM device (link to spec or driver
code below)
- Implement vsock device (or is this virtio-mmio vsock?)
- Add a test for the TPM device
- Add an acceptance test that boots a minimal EIF payload

This will give candidates more keywords and links to research this project.

Thanks,
Stefan


From stefanha at gmail.com  Mon Feb 14 14:02:06 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Mon, 14 Feb 2022 14:02:06 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
Message-ID: <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>

On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang at redhat.com> wrote:
>
> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
> >
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> >
> > Good project ideas are suitable for remote 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!
>
> Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
> (vhost/virtio drivers) would be an interesting idea.
>
> It satisfies all the points above since it's supported by virtio spec.
>
> (Unfortunately, I won't have time in the mentoring)

Thanks for this idea. As a stretch goal we could add implementing the
packed virtqueue layout in Linux vhost, QEMU's libvhost-user, and/or
QEMU's virtio qtest code.

Stefano: Thank you for volunteering to mentor the project. Please
write a project description (see template below) and I will add this
idea:

=== TITLE ===

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

 Detailed description of the project.

 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites

 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

Stefan


From stefanha at gmail.com  Mon Feb 14 14:11:02 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Mon, 14 Feb 2022 14:11:02 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <87zgmtd0ov.fsf@linaro.org>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <87zgmtd0ov.fsf@linaro.org>
Message-ID: <CAJSP0QULu-2pppavMHnUn2=Lo8j3b3wteXUiQfkiF49OjHjGMQ@mail.gmail.com>

On Mon, 14 Feb 2022 at 13:42, Alex Benn?e <alex.bennee at linaro.org> wrote:
>
>
> Stefan Hajnoczi <stefanha at gmail.com> writes:
>
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> >
> > Good project ideas are suitable for remote 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.
> >
> > Internship program details:
> > - Paid, remote work open source internships
> > - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> > hrs/week for 12 weeks
> > - Mentored by volunteers from QEMU, KVM, and rust-vmm
> > - Mentors typically spend at least 5 hours per week during the coding period
> >
> > Changes since last year: GSoC now has 175 or 350 hour project sizes
> > instead of 12 week full-time projects. GSoC will accept applicants who
> > are not students, before it was limited to students.
>
> I'm certainly up for mentoring new devices for vhost-device (rust-vmm
> vhost-user backends). Since we've become a code owner we're trying to
> clear the backlog (virto-vsock and virtio-block) but there are plenty of
> others that could be done. Of particular interest to me are:
>
>   - virtio-rpmb (we have a working C implementation I wrote)

Yes, it would be good to have an implementation. I mentioned this
device in my FOSDEM 22 talk about what's coming in VIRTIO 1.2:
https://vmsplice.net/~stefan/stefanha-fosdem-2022.pdf

>   - virtio-snd (in flight virtio spec)

There are QEMU patches in development by Shreyansh Chouhan although
that doesn't rule out a rust-vmm crate.

>   - virtio-video (again we have a working C version against v3)

Want to pick one device and write a project description for it?

> With my other hat on there are numerous TCG plugin projects that could
> be done. Adding basic plugins is fairly straight forward but it would be
> interesting to look at what is required to do a more involved plugin
> like panda-re's taint analysis (following ptrs as they move through the
> system). This will likely need some additional features exposed from the
> plugin interface to achieve.
>
> With that in mind there is also the idea of a central registry for
> register values which is a prerequisite for expanding access to TCG
> plugins but could also bring various quality of life improvements to
> other areas. I've written that up on a page:
>
>   https://wiki.qemu.org/Internships/ProjectIdeas/CentralRegisterRegistry

Thanks for posting that! Can you add links to the -d cpu, gdbstub, and
hmp/qmp register code? The idea is a little fuzzy in my mind, maybe
you could include a sketch of the API to give readers an idea of what
the project should deliver?

Stefan


From afrosi at redhat.com  Thu Feb 17 07:08:26 2022
From: afrosi at redhat.com (Alice Frosi)
Date: Thu, 17 Feb 2022 07:08:26 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
Message-ID: <CABBoX7PcqRFHDm0LCwWOwmYmOwH2x70pM-3OyxfDXD1sE_fHrw@mail.gmail.com>

On Fri, Jan 28, 2022 at 6:04 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
>
> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
>
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
>
> Please reply to this email by February 21st with your project ideas.
>
> Good project ideas are suitable for remote 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'd like to propose this idea:

Title: Create encrypted storage using VM-based container runtimes

Cryptsetup requires root privileges in order to be able to encrypt
storage with luks. However, privileged containers are generally
discouraged for security reasons. A possible solution to avoid extra
privileges is using VM-based container runtimes (e.g crun with libkrun
or kata-containers) and running inside the Virtual Machine the tools
for the storage encryption.

This internship focus on a PoC for integrating and extending crun with
libkrun in order to be able to create encrypted storage. The initial
step will focus on creating encrypted images to demonstrate the
feasibility and the necessary changes in the stack. If the timeframe
allows it, an interesting follow-up of the first step is the
encryption of persistent storage using block-based PVCs.

Language: C, rust, golang
Skills: containers and virtualization would be a big plus
I won't put a level but the intern needs to be willing to dig into
different source codes like crun (written in C), libkrun (written in
Rust) and possibly podman or other kubernetes/containers projects
(written in go)
Mentor: Alice Frosi, Co-mentor: Sergio Lopez Pascual

Let me know if the idea sounds feasible to you!

Many thanks,

Alice



From alxndr at bu.edu  Fri Feb 18 21:05:06 2022
From: alxndr at bu.edu (Alexander Bulekov)
Date: Fri, 18 Feb 2022 21:05:06 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
Message-ID: <20220218210323.hw2kkid25l7jczjo@mozz.bu.edu>

On 220128 1547, Stefan Hajnoczi wrote:
> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
> 
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
> 
> Please reply to this email by February 21st with your project ideas.
> 
> Good project ideas are suitable for remote 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!

Here are two fuzzing-related ideas:

Summary: Implement rapid guest-initiated snapshot/restore functionality (for
Fuzzing).

Description:
Many recent fuzzing projects rely on snapshot/restore functionality
[1,2,3,4,5]. For example tests/fuzzers that target large targets, such as OS
kernels and browsers benefit from full-VM snapshots, where solutions such as
manual state-cleanup and fork-servers are insufficient. 
Many of the existing solutions are based on QEMU, however there is currently no
upstream-solution. Furthermore, hypervisors, such as Xen have already
incorporated support for snapshot-fuzzing.
In this project, you will implement a virtual-device for snapshot fuzzing,
following a spec agreed-upon by the community.  The device will implement
standard fuzzing APIs that allow fuzzing using engines, such as libFuzzer and
AFL++. The simple APIs exposed by the device will allow fuzzer developers to
build custom harnesses in the VM to request snapshots, memory/device/register
restores, request new inputs, and report coverage.

[1] https://arxiv.org/pdf/2111.03013.pdf
[2] https://blog.mozilla.org/attack-and-defense/2021/01/27/effectively-fuzzing-the-ipc-layer-in-firefox/
[3] https://www.usenix.org/system/files/sec20-song.pdf
[4] https://github.com/intel/kernel-fuzzer-for-xen-project
[5] https://github.com/quarkslab/rewind

Skill level: Intermediate with interest and experience in fuzzing.
Language/Skills: C
Topic/Skill Areas: Fuzzing, OS/Systems/Drivers

Summary: Implement a coverage-guided fuzzer for QEMU images

Description:
QEMU has a qcow2 fuzzer (see tests/image-fuzzer). However, this fuzzer is not
coverage-guided, and is limited to qcow2 images. Furthermore, it does not run
on OSS-Fuzz. In some contexts, qemu-img is expected to handle untrusted disk
images. As such, it is important to effectively fuzz this code.
Your task will be to create a coverage-guided fuzzer for image formats
supported by QEMU. Beyond basic image-parsing code, the fuzzer should be able
to find bugs in image-conversion code.  Combined with a corpus of QEMU images,
the fuzzer harness will need less information about image layout.

Skill level: Intermediate
Language/Skills: C
Topic/Skill Areas: Fuzzing, libFuzzer/AFL

Thanks
-Alex


From graf at amazon.com  Wed Feb  9 14:50:09 2022
From: graf at amazon.com (Alexander Graf)
Date: Wed, 09 Feb 2022 14:50:09 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
Message-ID: <244647ca-a247-cfc1-d0df-b8c74d434a77@amazon.com>


On 28.01.22 16:47, Stefan Hajnoczi wrote:
> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
>
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
>
> Please reply to this email by February 21st with your project ideas.
>
> Good project ideas are suitable for remote 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 have one that I'd absolutely *love* to see but not gotten around 
implementing myself yet :)


Summary:

Implement -M nitro-enclave in QEMU

Nitro Enclaves are the first widely adopted implementation of hypervisor 
assisted compute isolation. Similar to technologies like SGX, it allows 
to spawn a separate context that is inaccessible by the parent Operating 
System. This is implemented by "giving up" resources of the parent VM 
(CPU cores, memory) to the hypervisor which then spawns a second vmm to 
execute a completely separate virtual machine. That new VM only has a 
vsock communication channel to the parent and has a built-in lightweight 
TPM.

One big challenge with Nitro Enclaves is that due to its roots in 
security, there are very few debugging / introspection capabilities. 
That makes OS bringup, debugging and bootstrapping very difficult. 
Having a local dev&test environment that looks like an Enclave, but is 
100% controlled by the developer and introspectable would make life a 
lot easier for everyone working on them. It also may pave the way to see 
Nitro Enclaves adopted in VM environments outside of EC2.

This project will consist of adding a new machine model to QEMU that 
mimics a Nitro Enclave environment, including the lightweight TPM, the 
vsock communication channel and building firmware which loads the 
special "EIF" file format which contains kernel, initramfs and metadata 
from a -kernel image.

Links:

https://aws.amazon.com/ec2/nitro/nitro-enclaves/
https://lore.kernel.org/lkml/20200921121732.44291-10-andraprs at amazon.com/T/

Details:

Skill level: intermediate - advanced (some understanding of QEMU machine 
modeling would be good)
Language: C
Mentor: Maybe me (Alexander Graf), depends on timelines and holiday 
season. Let's find an intern first - I promise to find a mentor then :)
Suggested by: Alexander Graf


Note: I don't know enough about rust-vmm's debugging capabilities. If it 
has gdbstub and a local UART that's easily usable, the project might be 
perfectly viable under its umbrella as well - written in Rust then of 
course.

Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From jasowang at redhat.com  Mon Feb 14 07:11:42 2022
From: jasowang at redhat.com (Jason Wang)
Date: Mon, 14 Feb 2022 07:11:42 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
Message-ID: <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>

On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
>
> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
>
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
>
> Please reply to this email by February 21st with your project ideas.
>
> Good project ideas are suitable for remote 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!

Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
(vhost/virtio drivers) would be an interesting idea.

It satisfies all the points above since it's supported by virtio spec.

(Unfortunately, I won't have time in the mentoring)

Thanks

>
> I will review project ideas and keep you up-to-date on QEMU's
> acceptance into GSoC.
>
> Internship program details:
> - Paid, remote work open source internships
> - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> hrs/week for 12 weeks
> - Mentored by volunteers from QEMU, KVM, and rust-vmm
> - Mentors typically spend at least 5 hours per week during the coding period
>
> Changes since last year: GSoC now has 175 or 350 hour project sizes
> instead of 12 week full-time projects. GSoC will accept applicants who
> are not students, before it was limited to students.
>
> For more background on QEMU internships, check out this video:
> https://www.youtube.com/watch?v=xNVCX7YMUL8
>
> Please let me know if you have any questions!
>
> Stefan
>



From sgarzare at redhat.com  Mon Feb 14 11:48:38 2022
From: sgarzare at redhat.com (Stefano Garzarella)
Date: Mon, 14 Feb 2022 11:48:38 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
Message-ID: <20220214114825.pi44m7mqyqvvtt52@step1g3>

On Mon, Feb 14, 2022 at 03:11:20PM +0800, Jason Wang wrote:
>On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
>>
>> Dear QEMU, KVM, and rust-vmm communities,
>> QEMU will apply for Google Summer of Code 2022
>> (https://summerofcode.withgoogle.com/) and has been accepted into
>> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
>> submit internship project ideas for QEMU, KVM, and rust-vmm!
>>
>> If you have experience contributing to QEMU, KVM, or rust-vmm you can
>> be a mentor. It's a great way to give back and you get to work with
>> people who are just starting out in open source.
>>
>> Please reply to this email by February 21st with your project ideas.
>>
>> Good project ideas are suitable for remote 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!
>
>Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
>(vhost/virtio drivers) would be an interesting idea.
>
>It satisfies all the points above since it's supported by virtio spec.

Yep, I agree!

>
>(Unfortunately, I won't have time in the mentoring)

I can offer my time to mentor this idea.

Thanks,
Stefano



From alex.bennee at linaro.org  Mon Feb 14 13:42:29 2022
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Mon, 14 Feb 2022 13:42:29 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
Message-ID: <87zgmtd0ov.fsf@linaro.org>


Stefan Hajnoczi <stefanha at gmail.com> writes:

> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
>
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
>
> Please reply to this email by February 21st with your project ideas.
>
> Good project ideas are suitable for remote 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.
>
> Internship program details:
> - Paid, remote work open source internships
> - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> hrs/week for 12 weeks
> - Mentored by volunteers from QEMU, KVM, and rust-vmm
> - Mentors typically spend at least 5 hours per week during the coding period
>
> Changes since last year: GSoC now has 175 or 350 hour project sizes
> instead of 12 week full-time projects. GSoC will accept applicants who
> are not students, before it was limited to students.

I'm certainly up for mentoring new devices for vhost-device (rust-vmm
vhost-user backends). Since we've become a code owner we're trying to
clear the backlog (virto-vsock and virtio-block) but there are plenty of
others that could be done. Of particular interest to me are:

  - virtio-rpmb (we have a working C implementation I wrote)
  - virtio-snd (in flight virtio spec)
  - virtio-video (again we have a working C version against v3)
  
With my other hat on there are numerous TCG plugin projects that could
be done. Adding basic plugins is fairly straight forward but it would be
interesting to look at what is required to do a more involved plugin
like panda-re's taint analysis (following ptrs as they move through the
system). This will likely need some additional features exposed from the
plugin interface to achieve.

With that in mind there is also the idea of a central registry for
register values which is a prerequisite for expanding access to TCG
plugins but could also bring various quality of life improvements to
other areas. I've written that up on a page:

  https://wiki.qemu.org/Internships/ProjectIdeas/CentralRegisterRegistry

-- 
Alex Benn?e


From jasowang at redhat.com  Tue Feb 15 07:48:53 2022
From: jasowang at redhat.com (Jason Wang)
Date: Tue, 15 Feb 2022 07:48:53 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <20220214114825.pi44m7mqyqvvtt52@step1g3>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
 <20220214114825.pi44m7mqyqvvtt52@step1g3>
Message-ID: <CACGkMEsqTRP18Sp5zAy9tUOcsMNx+MwrkeqnMXg=2sS58MrsUQ@mail.gmail.com>

On Mon, Feb 14, 2022 at 7:48 PM Stefano Garzarella <sgarzare at redhat.com> wrote:
>
> On Mon, Feb 14, 2022 at 03:11:20PM +0800, Jason Wang wrote:
> >On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
> >>
> >> Dear QEMU, KVM, and rust-vmm communities,
> >> QEMU will apply for Google Summer of Code 2022
> >> (https://summerofcode.withgoogle.com/) and has been accepted into
> >> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> >> submit internship project ideas for QEMU, KVM, and rust-vmm!
> >>
> >> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> >> be a mentor. It's a great way to give back and you get to work with
> >> people who are just starting out in open source.
> >>
> >> Please reply to this email by February 21st with your project ideas.
> >>
> >> Good project ideas are suitable for remote 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!
> >
> >Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
> >(vhost/virtio drivers) would be an interesting idea.
> >
> >It satisfies all the points above since it's supported by virtio spec.
>
> Yep, I agree!
>
> >
> >(Unfortunately, I won't have time in the mentoring)
>
> I can offer my time to mentor this idea.

Great, thanks a lot.

>
> Thanks,
> Stefano
>



From jasowang at redhat.com  Tue Feb 15 07:49:57 2022
From: jasowang at redhat.com (Jason Wang)
Date: Tue, 15 Feb 2022 07:49:57 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
 <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
Message-ID: <CACGkMEvt66SwZxWhZ72Bv_CL_tykwpL7njZwoddTdVQF7yDfqQ@mail.gmail.com>

On Mon, Feb 14, 2022 at 10:02 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
>
> On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang at redhat.com> wrote:
> >
> > On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
> > >
> > > Dear QEMU, KVM, and rust-vmm communities,
> > > QEMU will apply for Google Summer of Code 2022
> > > (https://summerofcode.withgoogle.com/) and has been accepted into
> > > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > > submit internship project ideas for QEMU, KVM, and rust-vmm!
> > >
> > > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > > be a mentor. It's a great way to give back and you get to work with
> > > people who are just starting out in open source.
> > >
> > > Please reply to this email by February 21st with your project ideas.
> > >
> > > Good project ideas are suitable for remote 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!
> >
> > Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
> > (vhost/virtio drivers) would be an interesting idea.
> >
> > It satisfies all the points above since it's supported by virtio spec.
> >
> > (Unfortunately, I won't have time in the mentoring)
>
> Thanks for this idea. As a stretch goal we could add implementing the
> packed virtqueue layout in Linux vhost, QEMU's libvhost-user, and/or
> QEMU's virtio qtest code.

Yes, for vhost, last time I remember Michael may want to do that.

Adding Michael for more comments.

Thanks

>
> Stefano: Thank you for volunteering to mentor the project. Please
> write a project description (see template below) and I will add this
> idea:
>
> === TITLE ===
>
>  '''Summary:''' Short description of the project
>
>  Detailed description of the project.
>
>  '''Links:'''
>  * Wiki links to relevant material
>  * External links to mailing lists or web sites
>
>  '''Details:'''
>  * Skill level: beginner or intermediate or advanced
>  * Language: C
>  * Mentor: Email address and IRC nick
>  * Suggested by: Person who suggested the idea
>
> Stefan
>



From sgarzare at redhat.com  Thu Feb 17 14:12:43 2022
From: sgarzare at redhat.com (Stefano Garzarella)
Date: Thu, 17 Feb 2022 14:12:43 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
 <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
Message-ID: <20220217141227.sk7hfng7raq6xvuh@sgarzare-redhat>

On Mon, Feb 14, 2022 at 02:01:52PM +0000, Stefan Hajnoczi wrote:
>On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang at redhat.com> wrote:
>>
>> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
>> >
>> > Dear QEMU, KVM, and rust-vmm communities,
>> > QEMU will apply for Google Summer of Code 2022
>> > (https://summerofcode.withgoogle.com/) and has been accepted into
>> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
>> > submit internship project ideas for QEMU, KVM, and rust-vmm!
>> >
>> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
>> > be a mentor. It's a great way to give back and you get to work with
>> > people who are just starting out in open source.
>> >
>> > Please reply to this email by February 21st with your project ideas.
>> >
>> > Good project ideas are suitable for remote 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!
>>
>> Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
>> (vhost/virtio drivers) would be an interesting idea.
>>
>> It satisfies all the points above since it's supported by virtio spec.
>>
>> (Unfortunately, I won't have time in the mentoring)
>
>Thanks for this idea. As a stretch goal we could add implementing the
>packed virtqueue layout in Linux vhost, QEMU's libvhost-user, and/or
>QEMU's virtio qtest code.
>
>Stefano: Thank you for volunteering to mentor the project. Please
>write a project description (see template below) and I will add this
>idea:
>

I wrote a description of the project below. Let me know if there is 
anything to change.

Thanks,
Stefano



=== VIRTIO_F_IN_ORDER support for virtio devices ===

'''Summary:''' Implement VIRTIO_F_IN_ORDER feature for QEMU and Linux
(vhost/virtio drivers)

The VIRTIO spec defines a feature bit (VIRTIO_F_IN_ORDER) that devices
and drivers can negotiate when they are able to use descriptors in the
same order in which they have been made available.

This feature could allow to simplify the implementation and develop
optimizations to increase performance. For example, when
VIRTIO_F_IN_ORDER is negotiated, it may be easier to create batch of
buffers and reduce the amount of notification needed between devices
and drivers.

Currently the devices and drivers available on Linux and QEMU do not
support this feature. An implementation is available in DPDK for the
virtio-net driver.

The project could start with implementation for a single device/driver
in QEMU and Linux, then generalize it into the virtio core for split
and packed virtqueue layouts.

If time allows we could develop the support for packed virtqueue layout
in Linux vhost, QEMU's libvhost-user, and/or QEMU's virtio qtest code.

'''Links:'''
* [https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html VIRTIO spec 1.1]
** [https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-470009 "In-order use of descriptors" section for split virtqueues]
* [https://github.com/oasis-tcs/virtio-spec Source code for the VIRTIO spec]
* [https://mails.dpdk.org/archives/dev/2018-July/106069.html Patches that introduced VIRTIO_F_IN_ORDER in DPDK]
* [https://lists.oasis-open.org/archives/virtio/201803/msg00048.html Patch that introduced VIRTIO_F_IN_ORDER in VIRTIO spec]
* [https://patchew.org/QEMU/1533833677-27512-1-git-send-email-i.maximets at samsung.com/ Incomplete implementation proposed for QEMU]

'''Details:'''
* Skill level: intermediate
* Language: C
* Mentor: Stefano Garzarella <sgarzare at redhat.com>
** IRC/Matrix nick: sgarzare (OFTC/matrix.org)
* Suggested by: Jason Wang <jasowang at redhat.com>



From stefanha at gmail.com  Thu Feb 17 16:26:53 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Thu, 17 Feb 2022 16:26:53 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CABBoX7PcqRFHDm0LCwWOwmYmOwH2x70pM-3OyxfDXD1sE_fHrw@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CABBoX7PcqRFHDm0LCwWOwmYmOwH2x70pM-3OyxfDXD1sE_fHrw@mail.gmail.com>
Message-ID: <CAJSP0QUqqiHQi2VWdDTvurK8oJL7s7Ae5G3=iPzUhcOtM0q_TA@mail.gmail.com>

On Thu, 17 Feb 2022 at 07:08, Alice Frosi <afrosi at redhat.com> wrote:
>
> On Fri, Jan 28, 2022 at 6:04 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
> >
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> >
> > Good project ideas are suitable for remote 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'd like to propose this idea:
>
> Title: Create encrypted storage using VM-based container runtimes
>
> Cryptsetup requires root privileges in order to be able to encrypt
> storage with luks. However, privileged containers are generally
> discouraged for security reasons. A possible solution to avoid extra
> privileges is using VM-based container runtimes (e.g crun with libkrun
> or kata-containers) and running inside the Virtual Machine the tools
> for the storage encryption.
>
> This internship focus on a PoC for integrating and extending crun with
> libkrun in order to be able to create encrypted storage. The initial
> step will focus on creating encrypted images to demonstrate the
> feasibility and the necessary changes in the stack. If the timeframe
> allows it, an interesting follow-up of the first step is the
> encryption of persistent storage using block-based PVCs.
>
> Language: C, rust, golang
> Skills: containers and virtualization would be a big plus
> I won't put a level but the intern needs to be willing to dig into
> different source codes like crun (written in C), libkrun (written in
> Rust) and possibly podman or other kubernetes/containers projects
> (written in go)
> Mentor: Alice Frosi, Co-mentor: Sergio Lopez Pascual
>
> Let me know if the idea sounds feasible to you!
Thanks, I have added the idea:
https://wiki.qemu.org/Google_Summer_of_Code_2022#Create_encrypted_storage_using_VM-based_container_runtimes

Stefan


From stefanha at gmail.com  Thu Feb 17 16:27:29 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Thu, 17 Feb 2022 16:27:29 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <20220217141227.sk7hfng7raq6xvuh@sgarzare-redhat>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
 <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
 <20220217141227.sk7hfng7raq6xvuh@sgarzare-redhat>
Message-ID: <CAJSP0QVVehjYpFodccZsQUew_LM6Yz5rfdFDSAvP1-+vHKwLgA@mail.gmail.com>

On Thu, 17 Feb 2022 at 14:12, Stefano Garzarella <sgarzare at redhat.com> wrote:
>
> On Mon, Feb 14, 2022 at 02:01:52PM +0000, Stefan Hajnoczi wrote:
> >On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang at redhat.com> wrote:
> >>
> >> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha at gmail.com> wrote:
> >> >
> >> > Dear QEMU, KVM, and rust-vmm communities,
> >> > QEMU will apply for Google Summer of Code 2022
> >> > (https://summerofcode.withgoogle.com/) and has been accepted into
> >> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> >> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >> >
> >> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> >> > be a mentor. It's a great way to give back and you get to work with
> >> > people who are just starting out in open source.
> >> >
> >> > Please reply to this email by February 21st with your project ideas.
> >> >
> >> > Good project ideas are suitable for remote 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!
> >>
> >> Implementing the VIRTIO_F_IN_ORDER feature for both Qemu and kernel
> >> (vhost/virtio drivers) would be an interesting idea.
> >>
> >> It satisfies all the points above since it's supported by virtio spec.
> >>
> >> (Unfortunately, I won't have time in the mentoring)
> >
> >Thanks for this idea. As a stretch goal we could add implementing the
> >packed virtqueue layout in Linux vhost, QEMU's libvhost-user, and/or
> >QEMU's virtio qtest code.
> >
> >Stefano: Thank you for volunteering to mentor the project. Please
> >write a project description (see template below) and I will add this
> >idea:
> >
>
> I wrote a description of the project below. Let me know if there is
> anything to change.

Thanks, I have added the idea:
https://wiki.qemu.org/Google_Summer_of_Code_2022#VIRTIO_F_IN_ORDER_support_for_virtio_devices

Stefan


From pbonzini at redhat.com  Thu Feb 17 17:49:48 2022
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Thu, 17 Feb 2022 17:49:48 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
 <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
Message-ID: <70c04ba7-d617-580d-deaa-97018192e8a6@redhat.com>

On 2/14/22 15:01, Stefan Hajnoczi wrote:
> Thanks for this idea. As a stretch goal we could add implementing the
> packed virtqueue layout in Linux vhost, QEMU's libvhost-user, and/or
> QEMU's virtio qtest code.

Why not have a separate project for packed virtqueue layout?

Paolo


From stefanha at gmail.com  Sat Feb 19 09:37:09 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Sat, 19 Feb 2022 09:37:09 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <70c04ba7-d617-580d-deaa-97018192e8a6@redhat.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <CACGkMEvtENvpubmZY3UKptD-T=c9+JJV1kRm-ZPhP08xOJv2fQ@mail.gmail.com>
 <CAJSP0QX6JgCG7UdqaY=G8rc64ZqE912UzM7pQkSMBfzGywHaHg@mail.gmail.com>
 <70c04ba7-d617-580d-deaa-97018192e8a6@redhat.com>
Message-ID: <CAJSP0QXUiNLQmTap1EgX-fxc5N1OqpN=PY=6x9JdCGxMaMHk7Q@mail.gmail.com>

On Thu, 17 Feb 2022 at 17:49, Paolo Bonzini <pbonzini at redhat.com> wrote:
> On 2/14/22 15:01, Stefan Hajnoczi wrote:
> > Thanks for this idea. As a stretch goal we could add implementing the
> > packed virtqueue layout in Linux vhost, QEMU's libvhost-user, and/or
> > QEMU's virtio qtest code.
>
> Why not have a separate project for packed virtqueue layout?

Sure, but we need mentors and they overlap with the VIRTIO_F_IN_ORDER
project. Does anyone want to mentor a packed virtqueue layout project?

Stefan


From its at irrelevant.dk  Mon Feb 21 06:14:42 2022
From: its at irrelevant.dk (Klaus Jensen)
Date: Mon, 21 Feb 2022 06:14:42 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
Message-ID: <YhMtxWcFMjdQTioe@apples>

On Jan 28 15:47, Stefan Hajnoczi wrote:
> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
> 
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
> 
> Please reply to this email by February 21st with your project ideas.
> 
> Good project ideas are suitable for remote 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.
> 
> Internship program details:
> - Paid, remote work open source internships
> - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> hrs/week for 12 weeks
> - Mentored by volunteers from QEMU, KVM, and rust-vmm
> - Mentors typically spend at least 5 hours per week during the coding period
> 
> Changes since last year: GSoC now has 175 or 350 hour project sizes
> instead of 12 week full-time projects. GSoC will accept applicants who
> are not students, before it was limited to students.
> 
> For more background on QEMU internships, check out this video:
> https://www.youtube.com/watch?v=xNVCX7YMUL8
> 
> Please let me know if you have any questions!
> 
> Stefan
> 

Hi,

I'd like to revive the "NVMe Performance" proposal from Paolo and Stefan
from two years ago.

  https://wiki.qemu.org/Internships/ProjectIdeas/NVMePerformance

I'd like to mentor, but since this is "iothread-heavy", I'd like to be
able to draw a bit on Stefan, Paolo if possible.


Klaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20220221/7a69af16/attachment-0001.sig>

From stefanha at gmail.com  Mon Feb 21 09:34:30 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Mon, 21 Feb 2022 09:34:30 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <20220218210323.hw2kkid25l7jczjo@mozz.bu.edu>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <20220218210323.hw2kkid25l7jczjo@mozz.bu.edu>
Message-ID: <CAJSP0QXxJhxc6gr=DnPGomL+z+fcTfpUcGSDRzXt9ivP86qU+g@mail.gmail.com>

On Fri, 18 Feb 2022 at 21:05, Alexander Bulekov <alxndr at bu.edu> wrote:
>
> On 220128 1547, Stefan Hajnoczi wrote:
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> >
> > Good project ideas are suitable for remote 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!
>
> Here are two fuzzing-related ideas:

Hi Alex,
I have added both ideas to the wiki. I tried to edit them, including
adding specific goals for the intern to complete during the summer.
Please take a look at then and feel free to edit!

> Summary: Implement rapid guest-initiated snapshot/restore functionality (for
> Fuzzing).

https://wiki.qemu.org/Google_Summer_of_Code_2022#Implement_a_snapshot_fuzzing_device

> Summary: Implement a coverage-guided fuzzer for QEMU images

https://wiki.qemu.org/Google_Summer_of_Code_2022#Coverage-guided_disk_image_fuzzing

Stefan


From stefanha at gmail.com  Mon Feb 21 09:51:54 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Mon, 21 Feb 2022 09:51:54 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <YhMtxWcFMjdQTioe@apples>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <YhMtxWcFMjdQTioe@apples>
Message-ID: <CAJSP0QVNRYTOGDsjCJJLOT=7yo1EB6D9LBwgQ4-CE539HdgHNQ@mail.gmail.com>

On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its at irrelevant.dk> wrote:
>
> On Jan 28 15:47, Stefan Hajnoczi wrote:
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> >
> > Good project ideas are suitable for remote 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.
> >
> > Internship program details:
> > - Paid, remote work open source internships
> > - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> > hrs/week for 12 weeks
> > - Mentored by volunteers from QEMU, KVM, and rust-vmm
> > - Mentors typically spend at least 5 hours per week during the coding period
> >
> > Changes since last year: GSoC now has 175 or 350 hour project sizes
> > instead of 12 week full-time projects. GSoC will accept applicants who
> > are not students, before it was limited to students.
> >
> > For more background on QEMU internships, check out this video:
> > https://www.youtube.com/watch?v=xNVCX7YMUL8
> >
> > Please let me know if you have any questions!
> >
> > Stefan
> >
>
> Hi,
>
> I'd like to revive the "NVMe Performance" proposal from Paolo and Stefan
> from two years ago.
>
>   https://wiki.qemu.org/Internships/ProjectIdeas/NVMePerformance
>
> I'd like to mentor, but since this is "iothread-heavy", I'd like to be
> able to draw a bit on Stefan, Paolo if possible.

Hi Klaus,
I can give input but I probably will not have enough time to
participate as a full co-mentor or review every line of every patch.

If you want to go ahead with the project, please let me know and I'll post it.

One thing I noticed about the project idea is that KVM ioeventfd
doesn't have the right semantics to emulate the traditional Submission
Queue Tail Doorbell register. The issue is that ioeventfd does not
capture the value written by the driver to the MMIO register. eventfd
is a simple counter so QEMU just sees that the guest has written but
doesn't know which value. Although ioeventfd has modes for matching
specific values, I don't think that can be used for NVMe Submission
Queues because there are too many possible register values and each
one requires a separate file descriptor. It might request 100s of
ioeventfds per sq, which won't scale.

The good news is that when the Shadow Doorbell Buffer is implemented
and enabled by the driver, then I think it becomes possible to use
ioeventfd for the Submission Queue Tail Doorbell.

I wanted to mention this so applicants/interns don't go down a dead
end trying to figure out how to use ioeventfd for the traditional
Submission Queue Tail Doorbell register.

Stefan


From its at irrelevant.dk  Mon Feb 21 12:00:51 2022
From: its at irrelevant.dk (Klaus Jensen)
Date: Mon, 21 Feb 2022 12:00:51 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QVNRYTOGDsjCJJLOT=7yo1EB6D9LBwgQ4-CE539HdgHNQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <YhMtxWcFMjdQTioe@apples>
 <CAJSP0QVNRYTOGDsjCJJLOT=7yo1EB6D9LBwgQ4-CE539HdgHNQ@mail.gmail.com>
Message-ID: <YhN+5wz3MXVm3vXU@apples>

On Feb 21 09:51, Stefan Hajnoczi wrote:
> On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its at irrelevant.dk> wrote:
> >
> > On Jan 28 15:47, Stefan Hajnoczi wrote:
> > > Dear QEMU, KVM, and rust-vmm communities,
> > > QEMU will apply for Google Summer of Code 2022
> > > (https://summerofcode.withgoogle.com/) and has been accepted into
> > > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > > submit internship project ideas for QEMU, KVM, and rust-vmm!
> > >
> > > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > > be a mentor. It's a great way to give back and you get to work with
> > > people who are just starting out in open source.
> > >
> > > Please reply to this email by February 21st with your project ideas.
> > >
> > > Good project ideas are suitable for remote 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.
> > >
> > > Internship program details:
> > > - Paid, remote work open source internships
> > > - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> > > hrs/week for 12 weeks
> > > - Mentored by volunteers from QEMU, KVM, and rust-vmm
> > > - Mentors typically spend at least 5 hours per week during the coding period
> > >
> > > Changes since last year: GSoC now has 175 or 350 hour project sizes
> > > instead of 12 week full-time projects. GSoC will accept applicants who
> > > are not students, before it was limited to students.
> > >
> > > For more background on QEMU internships, check out this video:
> > > https://www.youtube.com/watch?v=xNVCX7YMUL8
> > >
> > > Please let me know if you have any questions!
> > >
> > > Stefan
> > >
> >
> > Hi,
> >
> > I'd like to revive the "NVMe Performance" proposal from Paolo and Stefan
> > from two years ago.
> >
> >   https://wiki.qemu.org/Internships/ProjectIdeas/NVMePerformance
> >
> > I'd like to mentor, but since this is "iothread-heavy", I'd like to be
> > able to draw a bit on Stefan, Paolo if possible.
> 
> Hi Klaus,
> I can give input but I probably will not have enough time to
> participate as a full co-mentor or review every line of every patch.
> 

Of course Stefan, I understand - I did not expect you to co-mentor :)

> If you want to go ahead with the project, please let me know and I'll post it.
> 

Yes, I'll go ahead as mentor for this.

@Keith, if you want to join in, let us know :)

> One thing I noticed about the project idea is that KVM ioeventfd
> doesn't have the right semantics to emulate the traditional Submission
> Queue Tail Doorbell register. The issue is that ioeventfd does not
> capture the value written by the driver to the MMIO register. eventfd
> is a simple counter so QEMU just sees that the guest has written but
> doesn't know which value. Although ioeventfd has modes for matching
> specific values, I don't think that can be used for NVMe Submission
> Queues because there are too many possible register values and each
> one requires a separate file descriptor. It might request 100s of
> ioeventfds per sq, which won't scale.
> 
> The good news is that when the Shadow Doorbell Buffer is implemented
> and enabled by the driver, then I think it becomes possible to use
> ioeventfd for the Submission Queue Tail Doorbell.
> 

Yes, I agree.

> I wanted to mention this so applicants/interns don't go down a dead
> end trying to figure out how to use ioeventfd for the traditional
> Submission Queue Tail Doorbell register.
> 

Yeah, thats what the Shadow Doorbell mechanic is for.

Suggested updated summary:

QEMU's NVMe emulation uses the traditional trap-and-emulation method to
emulate I/Os, thus the performance suffers due to frequent VM-exits.
Version 1.3 of the NVMe specification defines a new feature to update
doorbell registers using a Shadow Doorbell Buffer. This can be utilized
to enhance performance of emulated controllers by reducing the number of
Submission Queue Tail Doorbell writes.

Further more, it is possible to run emulation in a dedicated thread
called an IOThread. Emulating NVMe in a separate thread allows the vcpu
thread to continue execution and results in better performance.

Finally, it is possible for the emulation code to watch for changes to
the queue memory instead of waiting for doorbell writes. This technique
is called polling and reduces notification latency at the expense of an
another thread consuming CPU to detect queue activity.

The goal of this project is to add implement these optimizations so
QEMU's NVMe emulation performance becomes comparable to virtio-blk
performance.

Tasks include:

    Add Shadow Doorbell Buffer support to reduce doorbell writes
    Add Submission Queue polling
    Add IOThread support so emulation can run in a dedicated thread

Maybe add a link to this previous discussion as well:

https://lore.kernel.org/qemu-devel/1447825624-17011-1-git-send-email-mlin at kernel.org/T/#u


Klaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20220221/0b0cf765/attachment-0001.sig>

From stefanha at gmail.com  Tue Feb 22 09:48:20 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Tue, 22 Feb 2022 09:48:20 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <YhN+5wz3MXVm3vXU@apples>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <YhMtxWcFMjdQTioe@apples>
 <CAJSP0QVNRYTOGDsjCJJLOT=7yo1EB6D9LBwgQ4-CE539HdgHNQ@mail.gmail.com>
 <YhN+5wz3MXVm3vXU@apples>
Message-ID: <CAJSP0QXz6kuwx6mycYz_xzxiVjdVR_AqHnpygwV4Ht-7B9pYmw@mail.gmail.com>

On Mon, 21 Feb 2022 at 12:00, Klaus Jensen <its at irrelevant.dk> wrote:
>
> On Feb 21 09:51, Stefan Hajnoczi wrote:
> > On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its at irrelevant.dk> wrote:
> > >
> > > On Jan 28 15:47, Stefan Hajnoczi wrote:
> > > > Dear QEMU, KVM, and rust-vmm communities,
> > > > QEMU will apply for Google Summer of Code 2022
> > > > (https://summerofcode.withgoogle.com/) and has been accepted into
> > > > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > > > submit internship project ideas for QEMU, KVM, and rust-vmm!
> > > >
> > > > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > > > be a mentor. It's a great way to give back and you get to work with
> > > > people who are just starting out in open source.
> > > >
> > > > Please reply to this email by February 21st with your project ideas.
> > > >
> > > > Good project ideas are suitable for remote 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.
> > > >
> > > > Internship program details:
> > > > - Paid, remote work open source internships
> > > > - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> > > > hrs/week for 12 weeks
> > > > - Mentored by volunteers from QEMU, KVM, and rust-vmm
> > > > - Mentors typically spend at least 5 hours per week during the coding period
> > > >
> > > > Changes since last year: GSoC now has 175 or 350 hour project sizes
> > > > instead of 12 week full-time projects. GSoC will accept applicants who
> > > > are not students, before it was limited to students.
> > > >
> > > > For more background on QEMU internships, check out this video:
> > > > https://www.youtube.com/watch?v=xNVCX7YMUL8
> > > >
> > > > Please let me know if you have any questions!
> > > >
> > > > Stefan
> > > >
> > >
> > > Hi,
> > >
> > > I'd like to revive the "NVMe Performance" proposal from Paolo and Stefan
> > > from two years ago.
> > >
> > >   https://wiki.qemu.org/Internships/ProjectIdeas/NVMePerformance
> > >
> > > I'd like to mentor, but since this is "iothread-heavy", I'd like to be
> > > able to draw a bit on Stefan, Paolo if possible.
> >
> > Hi Klaus,
> > I can give input but I probably will not have enough time to
> > participate as a full co-mentor or review every line of every patch.
> >
>
> Of course Stefan, I understand - I did not expect you to co-mentor :)
>
> > If you want to go ahead with the project, please let me know and I'll post it.
> >
>
> Yes, I'll go ahead as mentor for this.
>
> @Keith, if you want to join in, let us know :)
>
> > One thing I noticed about the project idea is that KVM ioeventfd
> > doesn't have the right semantics to emulate the traditional Submission
> > Queue Tail Doorbell register. The issue is that ioeventfd does not
> > capture the value written by the driver to the MMIO register. eventfd
> > is a simple counter so QEMU just sees that the guest has written but
> > doesn't know which value. Although ioeventfd has modes for matching
> > specific values, I don't think that can be used for NVMe Submission
> > Queues because there are too many possible register values and each
> > one requires a separate file descriptor. It might request 100s of
> > ioeventfds per sq, which won't scale.
> >
> > The good news is that when the Shadow Doorbell Buffer is implemented
> > and enabled by the driver, then I think it becomes possible to use
> > ioeventfd for the Submission Queue Tail Doorbell.
> >
>
> Yes, I agree.
>
> > I wanted to mention this so applicants/interns don't go down a dead
> > end trying to figure out how to use ioeventfd for the traditional
> > Submission Queue Tail Doorbell register.
> >
>
> Yeah, thats what the Shadow Doorbell mechanic is for.
>
> Suggested updated summary:
>
> QEMU's NVMe emulation uses the traditional trap-and-emulation method to
> emulate I/Os, thus the performance suffers due to frequent VM-exits.
> Version 1.3 of the NVMe specification defines a new feature to update
> doorbell registers using a Shadow Doorbell Buffer. This can be utilized
> to enhance performance of emulated controllers by reducing the number of
> Submission Queue Tail Doorbell writes.
>
> Further more, it is possible to run emulation in a dedicated thread
> called an IOThread. Emulating NVMe in a separate thread allows the vcpu
> thread to continue execution and results in better performance.
>
> Finally, it is possible for the emulation code to watch for changes to
> the queue memory instead of waiting for doorbell writes. This technique
> is called polling and reduces notification latency at the expense of an
> another thread consuming CPU to detect queue activity.
>
> The goal of this project is to add implement these optimizations so
> QEMU's NVMe emulation performance becomes comparable to virtio-blk
> performance.
>
> Tasks include:
>
>     Add Shadow Doorbell Buffer support to reduce doorbell writes
>     Add Submission Queue polling
>     Add IOThread support so emulation can run in a dedicated thread
>
> Maybe add a link to this previous discussion as well:
>
> https://lore.kernel.org/qemu-devel/1447825624-17011-1-git-send-email-mlin at kernel.org/T/#u

Great, I have added the project idea. I left in the sq doorbell
ioeventfd task but moved it after the Shadow Doorbell Buffer support
task and made it clear that the ioeventfd can only be used when the
Shadow Doorbell Buffer is enabled:
https://wiki.qemu.org/Google_Summer_of_Code_2022#NVMe_Emulation_Performance_Optimization

Stefan


From kbusch at kernel.org  Tue Feb 22 15:03:40 2022
From: kbusch at kernel.org (Keith Busch)
Date: Tue, 22 Feb 2022 15:03:40 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QXz6kuwx6mycYz_xzxiVjdVR_AqHnpygwV4Ht-7B9pYmw@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <YhMtxWcFMjdQTioe@apples>
 <CAJSP0QVNRYTOGDsjCJJLOT=7yo1EB6D9LBwgQ4-CE539HdgHNQ@mail.gmail.com>
 <YhN+5wz3MXVm3vXU@apples>
 <CAJSP0QXz6kuwx6mycYz_xzxiVjdVR_AqHnpygwV4Ht-7B9pYmw@mail.gmail.com>
Message-ID: <20220222150335.GA1497257@dhcp-10-100-145-180.wdc.com>

On Tue, Feb 22, 2022 at 09:48:06AM +0000, Stefan Hajnoczi wrote:
> On Mon, 21 Feb 2022 at 12:00, Klaus Jensen <its at irrelevant.dk> wrote:
> >
> > Yes, I'll go ahead as mentor for this.
> >
> > @Keith, if you want to join in, let us know :)

Thank you for setting this up, I would be happy assist with the cause!

> > Suggested updated summary:
> >
> > QEMU's NVMe emulation uses the traditional trap-and-emulation method to
> > emulate I/Os, thus the performance suffers due to frequent VM-exits.
> > Version 1.3 of the NVMe specification defines a new feature to update
> > doorbell registers using a Shadow Doorbell Buffer. This can be utilized
> > to enhance performance of emulated controllers by reducing the number of
> > Submission Queue Tail Doorbell writes.
> >
> > Further more, it is possible to run emulation in a dedicated thread
> > called an IOThread. Emulating NVMe in a separate thread allows the vcpu
> > thread to continue execution and results in better performance.
> >
> > Finally, it is possible for the emulation code to watch for changes to
> > the queue memory instead of waiting for doorbell writes. This technique
> > is called polling and reduces notification latency at the expense of an
> > another thread consuming CPU to detect queue activity.
> >
> > The goal of this project is to add implement these optimizations so
> > QEMU's NVMe emulation performance becomes comparable to virtio-blk
> > performance.
> >
> > Tasks include:
> >
> >     Add Shadow Doorbell Buffer support to reduce doorbell writes
> >     Add Submission Queue polling
> >     Add IOThread support so emulation can run in a dedicated thread
> >
> > Maybe add a link to this previous discussion as well:
> >
> > https://lore.kernel.org/qemu-devel/1447825624-17011-1-git-send-email-mlin at kernel.org/T/#u
> 
> Great, I have added the project idea. I left in the sq doorbell
> ioeventfd task but moved it after the Shadow Doorbell Buffer support
> task and made it clear that the ioeventfd can only be used when the
> Shadow Doorbell Buffer is enabled:
> https://wiki.qemu.org/Google_Summer_of_Code_2022#NVMe_Emulation_Performance_Optimization

Looks great, this seems like a very useful addition to have. I like that
the feature can be broken down into two parts. Hopefully that makes it
more approachable.


From fandree at amazon.com  Wed Feb 23 08:48:29 2022
From: fandree at amazon.com (Andreea Florescu)
Date: Wed, 23 Feb 2022 08:48:29 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
Message-ID: <54dddcf5-85d7-5170-899e-589dd79a34fb@amazon.com>



On 1/28/22 17:47, 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.
>
>
>
> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
>
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
>
> Please reply to this email by February 21st with your project ideas.
Hey, I am a bit late here, but in case it is still possible, I would
like to also propose a project.

Title: Extend the aarch64 support for rust-vmm/vmm-reference

Summary:
The vmm-reference is a reference implementation of a Rust VMM based on 
rust-vmm crates.
This is currently used for testing the integration of rust-vmm 
components, with plans of extending it
such that it becomes a starting point for custom Rust VMMs.

The vmm-reference currently has support for x86_64 and POC level support 
for aarch64.
On aarch64, it just supports booting a dummy VM with no devices, while 
on x86_64 it has support for the
vsock-network and vsock-block devices. The purpose of this project is to 
extend the existing functionality
getting it closer to what is already available on x86_64, and consume 
the readily available crates
(for example vm-allocator) that would make the integration easier.

Resources:
- about the vmm-reference: https://github.com/rust-vmm/vmm-reference
- about the rust-vmm project: https://github.com/rust-vmm/community
- task breakdown for adding arm support: 
https://github.com/rust-vmm/vmm-reference/issues?q=is%3Aissue+is%3Aopen+label%3Aaarch64

Language:
- 90% Rust
- 10% Python (used for adapting the already existing integration tests)

Mentors:
- fandree at amazon.com
- gsserge at amazon.com
>
> Good project ideas are suitable for remote 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.
>
> Internship program details:
> - Paid, remote work open source internships
> - GSoC projects are 175 or 350 hours, Outreachy projects are 30
> hrs/week for 12 weeks
> - Mentored by volunteers from QEMU, KVM, and rust-vmm
> - Mentors typically spend at least 5 hours per week during the coding period
>
> Changes since last year: GSoC now has 175 or 350 hour project sizes
> instead of 12 week full-time projects. GSoC will accept applicants who
> are not students, before it was limited to students.
>
> For more background on QEMU internships, check out this video:
> https://www.youtube.com/watch?v=xNVCX7YMUL8
>
> Please let me know if you have any questions!
>
> Stefan




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.

From stefanha at gmail.com  Fri Feb 25 12:39:19 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Fri, 25 Feb 2022 12:39:19 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <20220222150335.GA1497257@dhcp-10-100-145-180.wdc.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <YhMtxWcFMjdQTioe@apples>
 <CAJSP0QVNRYTOGDsjCJJLOT=7yo1EB6D9LBwgQ4-CE539HdgHNQ@mail.gmail.com>
 <YhN+5wz3MXVm3vXU@apples>
 <CAJSP0QXz6kuwx6mycYz_xzxiVjdVR_AqHnpygwV4Ht-7B9pYmw@mail.gmail.com>
 <20220222150335.GA1497257@dhcp-10-100-145-180.wdc.com>
Message-ID: <CAJSP0QXQr1UBX9S_0QzwO89wLcTyBe+rofTY6+dyUNHvvDyPzA@mail.gmail.com>

On Tue, 22 Feb 2022 at 15:03, Keith Busch <kbusch at kernel.org> wrote:
>
> On Tue, Feb 22, 2022 at 09:48:06AM +0000, Stefan Hajnoczi wrote:
> > On Mon, 21 Feb 2022 at 12:00, Klaus Jensen <its at irrelevant.dk> wrote:
> > >
> > > Yes, I'll go ahead as mentor for this.
> > >
> > > @Keith, if you want to join in, let us know :)
>
> Thank you for setting this up, I would be happy assist with the cause!

Hi Keith,
I have added you as co-mentor. Thank you for participating!

Stefan


From stefanha at gmail.com  Fri Feb 25 12:55:13 2022
From: stefanha at gmail.com (Stefan Hajnoczi)
Date: Fri, 25 Feb 2022 12:55:13 -0000
Subject: [Rust-VMM] Call for GSoC and Outreachy project ideas for summer
 2022
In-Reply-To: <54dddcf5-85d7-5170-899e-589dd79a34fb@amazon.com>
References: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
 <54dddcf5-85d7-5170-899e-589dd79a34fb@amazon.com>
Message-ID: <CAJSP0QXknCnbF-NmPM-dqKfs7M15L8S+ejTrWfe+9c4pVznaSA@mail.gmail.com>

On Wed, 23 Feb 2022 at 08:48, Andreea Florescu <fandree at amazon.com> wrote:
> On 1/28/22 17:47, 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.
> >
> >
> >
> > Dear QEMU, KVM, and rust-vmm communities,
> > QEMU will apply for Google Summer of Code 2022
> > (https://summerofcode.withgoogle.com/) and has been accepted into
> > Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> > submit internship project ideas for QEMU, KVM, and rust-vmm!
> >
> > If you have experience contributing to QEMU, KVM, or rust-vmm you can
> > be a mentor. It's a great way to give back and you get to work with
> > people who are just starting out in open source.
> >
> > Please reply to this email by February 21st with your project ideas.
> Hey, I am a bit late here, but in case it is still possible, I would
> like to also propose a project.
>
> Title: Extend the aarch64 support for rust-vmm/vmm-reference

Great project idea. I have added it to the list!

Please take a look and let me know if you want to change anything:
https://wiki.qemu.org/Google_Summer_of_Code_2022#Extend_aarch64_support_in_rust-vmm.2Fvmm-reference

Stefan