Call for GSoC and Outreachy project ideas for summer 2022

Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

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

Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alexander Graf]

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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Jason Wang]

On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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
>

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Jason Wang]

On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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
>

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefano Garzarella]

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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefano Garzarella]

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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alex Bennée]

Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alex Bennée]

Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Wed, 9 Feb 2022 at 14:50, Alexander Graf <graf@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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Wed, 9 Feb 2022 at 14:50, Alexander Graf <graf@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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang@redhat.com> wrote:
>
> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang@redhat.com> wrote:
>
> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 14 Feb 2022 at 13:42, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 14 Feb 2022 at 13:42, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Jason Wang]

On Mon, Feb 14, 2022 at 7:48 PM Stefano Garzarella <sgarzare@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@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
>

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Jason Wang]

On Mon, Feb 14, 2022 at 7:48 PM Stefano Garzarella <sgarzare@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@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
>

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Jason Wang]

On Mon, Feb 14, 2022 at 10:02 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang@redhat.com> wrote:
> >
> > On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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
>

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Jason Wang]

On Mon, Feb 14, 2022 at 10:02 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang@redhat.com> wrote:
> >
> > On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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
>

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alice Frosi]

On Fri, Jan 28, 2022 at 6:04 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alice Frosi]

On Fri, Jan 28, 2022 at 6:04 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefano Garzarella]

On Mon, Feb 14, 2022 at 02:01:52PM +0000, Stefan Hajnoczi wrote:
>On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang@redhat.com> wrote:
>>
>> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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@samsung.com/ Incomplete implementation proposed for QEMU]

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefano Garzarella]

On Mon, Feb 14, 2022 at 02:01:52PM +0000, Stefan Hajnoczi wrote:
>On Mon, 14 Feb 2022 at 07:11, Jason Wang <jasowang@redhat.com> wrote:
>>
>> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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@samsung.com/ Incomplete implementation proposed for QEMU]

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Thu, 17 Feb 2022 at 07:08, Alice Frosi <afrosi@redhat.com> wrote:
>
> On Fri, Jan 28, 2022 at 6:04 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Thu, 17 Feb 2022 at 07:08, Alice Frosi <afrosi@redhat.com> wrote:
>
> On Fri, Jan 28, 2022 at 6:04 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Thu, 17 Feb 2022 at 14:12, Stefano Garzarella <sgarzare@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@redhat.com> wrote:
> >>
> >> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Thu, 17 Feb 2022 at 14:12, Stefano Garzarella <sgarzare@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@redhat.com> wrote:
> >>
> >> On Fri, Jan 28, 2022 at 11:47 PM Stefan Hajnoczi <stefanha@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Paolo Bonzini]

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Paolo Bonzini]

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Paolo Bonzini]

On 1/28/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.

I would like to co-mentor one or more projects about adding more 
statistics to Mark Kanda's newly-born introspectable statistics 
subsystem in QEMU 
(https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/), 
for example integrating "info blockstats"; and/or, to add matching 
functionality to libvirt.

However, I will only be available for co-mentoring unfortunately.

Paolo

> 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
> 

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Paolo Bonzini]

On 1/28/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.

I would like to co-mentor one or more projects about adding more 
statistics to Mark Kanda's newly-born introspectable statistics 
subsystem in QEMU 
(https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/), 
for example integrating "info blockstats"; and/or, to add matching 
functionality to libvirt.

However, I will only be available for co-mentoring unfortunately.

Paolo

> 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
> 

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Thomas Huth]

On 28/01/2022 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.

I'd like to suggest an idea (shamelessly "inspired" by Philippe's suggestion 
last year):

=== Improve s390x (IBM Z) emulation with RISU ===

Summary: Adapt RISU to s390x and fix CPU emulation along the way.

RISU (Random Instruction Sequence generator for Userspace testing) is a tool 
for testing CPU instructions with randomly generated opcodes. The goal of 
this project is to adapt the RISU framework for the IBM Z architecture 
(a.k.a. s390x), so that it could be used to test the s390x emulation of QEMU 
for correctness. This will certainly help to spot some instruction emulation 
deficiencies in QEMU which should be addressed during this internship, too.

'''Links:'''
* [https://git.linaro.org/people/peter.maydell/risu.git/tree/
    Peter Maydell's RISU repository]
* [https://www.linux-kvm.org/images/6/63/01x03-ValidatingTCG.pdf
    KVM Forum 2014 presentation by Alex Bennée]
* [http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf
    z/Architecture Principles of Operation] (the description
    of the CPU instructions)

'''Details:'''
* Skill level: intermediate (a good basic understanding of CPU
   instructions is required)
* Language: C, Perl
* Mentor: Thomas Huth (thuth@redhat.com) (+1 TBD)


What do you think about that idea?

  Thanks,
   Thomas

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Michal Prívozník]

On 2/17/22 18:52, Paolo Bonzini wrote:
> On 1/28/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.
> 
> I would like to co-mentor one or more projects about adding more
> statistics to Mark Kanda's newly-born introspectable statistics
> subsystem in QEMU
> (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
> for example integrating "info blockstats"; and/or, to add matching
> functionality to libvirt.
> 
> However, I will only be available for co-mentoring unfortunately.

I'm happy to offer my helping hand in this. I mean the libvirt part,
since I am a libvirt developer.

I believe this will be listed in QEMU's ideas list, right?

Michal

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Michal Prívozník]

On 2/17/22 18:52, Paolo Bonzini wrote:
> On 1/28/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.
> 
> I would like to co-mentor one or more projects about adding more
> statistics to Mark Kanda's newly-born introspectable statistics
> subsystem in QEMU
> (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
> for example integrating "info blockstats"; and/or, to add matching
> functionality to libvirt.
> 
> However, I will only be available for co-mentoring unfortunately.

I'm happy to offer my helping hand in this. I mean the libvirt part,
since I am a libvirt developer.

I believe this will be listed in QEMU's ideas list, right?

Michal

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Paolo Bonzini]

On 2/18/22 12:39, Michal Prívozník wrote:
> On 2/17/22 18:52, Paolo Bonzini wrote:
>> I would like to co-mentor one or more projects about adding more
>> statistics to Mark Kanda's newly-born introspectable statistics
>> subsystem in QEMU
>> (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
>> for example integrating "info blockstats"; and/or, to add matching
>> functionality to libvirt.
>>
>> However, I will only be available for co-mentoring unfortunately.
> 
> I'm happy to offer my helping hand in this. I mean the libvirt part,
> since I am a libvirt developer.
> 
> I believe this will be listed in QEMU's ideas list, right?

Does Libvirt participate to GSoC as an independent organization this 
year?  If not, I'll add it as a Libvirt project on the QEMU ideas list.

Paolo

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alexander Bulekov]

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alexander Bulekov]

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Thu, 17 Feb 2022 at 17:49, Paolo Bonzini <pbonzini@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Thu, 17 Feb 2022 at 17:49, Paolo Bonzini <pbonzini@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Fri, 18 Feb 2022 at 16:03, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 2/18/22 12:39, Michal Prívozník wrote:
> > On 2/17/22 18:52, Paolo Bonzini wrote:
> >> I would like to co-mentor one or more projects about adding more
> >> statistics to Mark Kanda's newly-born introspectable statistics
> >> subsystem in QEMU
> >> (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
> >> for example integrating "info blockstats"; and/or, to add matching
> >> functionality to libvirt.
> >>
> >> However, I will only be available for co-mentoring unfortunately.
> >
> > I'm happy to offer my helping hand in this. I mean the libvirt part,
> > since I am a libvirt developer.
> >
> > I believe this will be listed in QEMU's ideas list, right?
>
> Does Libvirt participate to GSoC as an independent organization this
> year?  If not, I'll add it as a Libvirt project on the QEMU ideas list.

Libvirt participates as its own GSoC organization. If a project has
overlap we could do it in either org, or have a QEMU project and a
libvirt project if the amount of work is large enough.

Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Fri, 18 Feb 2022 at 16:03, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 2/18/22 12:39, Michal Prívozník wrote:
> > On 2/17/22 18:52, Paolo Bonzini wrote:
> >> I would like to co-mentor one or more projects about adding more
> >> statistics to Mark Kanda's newly-born introspectable statistics
> >> subsystem in QEMU
> >> (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
> >> for example integrating "info blockstats"; and/or, to add matching
> >> functionality to libvirt.
> >>
> >> However, I will only be available for co-mentoring unfortunately.
> >
> > I'm happy to offer my helping hand in this. I mean the libvirt part,
> > since I am a libvirt developer.
> >
> > I believe this will be listed in QEMU's ideas list, right?
>
> Does Libvirt participate to GSoC as an independent organization this
> year?  If not, I'll add it as a Libvirt project on the QEMU ideas list.

Libvirt participates as its own GSoC organization. If a project has
overlap we could do it in either org, or have a QEMU project and a
libvirt project if the amount of work is large enough.

Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Fri, 18 Feb 2022 at 11:40, Michal Prívozník <mprivozn@redhat.com> wrote:
>
> On 2/17/22 18:52, Paolo Bonzini wrote:
> > On 1/28/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.
> >
> > I would like to co-mentor one or more projects about adding more
> > statistics to Mark Kanda's newly-born introspectable statistics
> > subsystem in QEMU
> > (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
> > for example integrating "info blockstats"; and/or, to add matching
> > functionality to libvirt.
> >
> > However, I will only be available for co-mentoring unfortunately.
>
> I'm happy to offer my helping hand in this. I mean the libvirt part,
> since I am a libvirt developer.
>
> I believe this will be listed in QEMU's ideas list, right?

You're welcome to co-mentor the QEMU project indepently of a separate
libvirt project (if there is one). Your involvement would be great so
you can give input on what APIs libvirt wants.

Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Fri, 18 Feb 2022 at 11:40, Michal Prívozník <mprivozn@redhat.com> wrote:
>
> On 2/17/22 18:52, Paolo Bonzini wrote:
> > On 1/28/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.
> >
> > I would like to co-mentor one or more projects about adding more
> > statistics to Mark Kanda's newly-born introspectable statistics
> > subsystem in QEMU
> > (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
> > for example integrating "info blockstats"; and/or, to add matching
> > functionality to libvirt.
> >
> > However, I will only be available for co-mentoring unfortunately.
>
> I'm happy to offer my helping hand in this. I mean the libvirt part,
> since I am a libvirt developer.
>
> I believe this will be listed in QEMU's ideas list, right?

You're welcome to co-mentor the QEMU project indepently of a separate
libvirt project (if there is one). Your involvement would be great so
you can give input on what APIs libvirt wants.

Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Thu, 17 Feb 2022 at 18:24, Thomas Huth <thuth@redhat.com> wrote:
>
> On 28/01/2022 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.
>
> I'd like to suggest an idea (shamelessly "inspired" by Philippe's suggestion
> last year):
>
> === Improve s390x (IBM Z) emulation with RISU ===
>
> Summary: Adapt RISU to s390x and fix CPU emulation along the way.
>
> RISU (Random Instruction Sequence generator for Userspace testing) is a tool
> for testing CPU instructions with randomly generated opcodes. The goal of
> this project is to adapt the RISU framework for the IBM Z architecture
> (a.k.a. s390x), so that it could be used to test the s390x emulation of QEMU
> for correctness. This will certainly help to spot some instruction emulation
> deficiencies in QEMU which should be addressed during this internship, too.
>
> '''Links:'''
> * [https://git.linaro.org/people/peter.maydell/risu.git/tree/
>     Peter Maydell's RISU repository]
> * [https://www.linux-kvm.org/images/6/63/01x03-ValidatingTCG.pdf
>     KVM Forum 2014 presentation by Alex Bennée]
> * [http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf
>     z/Architecture Principles of Operation] (the description
>     of the CPU instructions)
>
> '''Details:'''
> * Skill level: intermediate (a good basic understanding of CPU
>    instructions is required)
> * Language: C, Perl
> * Mentor: Thomas Huth (thuth@redhat.com) (+1 TBD)
>
>
> What do you think about that idea?

That is a great project idea. I have added it to the wiki and expanded
the description a little to explain how RISU works:
https://wiki.qemu.org/Google_Summer_of_Code_2022#Improve_s390x_.28IBM_Z.29_emulation_with_RISU

Please add proposed tasks to the description so applicants have a
starting point for breaking down the project into sub-tasks and coming
up with a schedule.

Thanks,
Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Klaus Jensen]

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

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

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Klaus Jensen]

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

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

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Fri, 18 Feb 2022 at 21:05, Alexander Bulekov <alxndr@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Fri, 18 Feb 2022 at 21:05, Alexander Bulekov <alxndr@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Michal Prívozník]

On 2/19/22 14:46, Stefan Hajnoczi wrote:
> On Fri, 18 Feb 2022 at 16:03, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 2/18/22 12:39, Michal Prívozník wrote:
>>> On 2/17/22 18:52, Paolo Bonzini wrote:
>>>> I would like to co-mentor one or more projects about adding more
>>>> statistics to Mark Kanda's newly-born introspectable statistics
>>>> subsystem in QEMU
>>>> (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
>>>> for example integrating "info blockstats"; and/or, to add matching
>>>> functionality to libvirt.
>>>>
>>>> However, I will only be available for co-mentoring unfortunately.
>>>
>>> I'm happy to offer my helping hand in this. I mean the libvirt part,
>>> since I am a libvirt developer.
>>>
>>> I believe this will be listed in QEMU's ideas list, right?
>>
>> Does Libvirt participate to GSoC as an independent organization this
>> year?  If not, I'll add it as a Libvirt project on the QEMU ideas list.
> 
> Libvirt participates as its own GSoC organization. If a project has
> overlap we could do it in either org, or have a QEMU project and a
> libvirt project if the amount of work is large enough.

Indeed. Libvirt's participating on its own since 2016, IIRC. Since we're
still in org acceptance phase we have some time to decide this,
actually. We can do the final decision after participating orgs are
announced. My gut feeling says that it's going to be more work on QEMU
side which would warrant it to be on the QEMU ideas page.

But anyway, we can wait an see. Meanwhile, as Stefan is trying to
compile the list for org application, I'm okay with putting it onto
QEMU's list.

Michal

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Michal Prívozník]

On 2/19/22 14:46, Stefan Hajnoczi wrote:
> On Fri, 18 Feb 2022 at 16:03, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 2/18/22 12:39, Michal Prívozník wrote:
>>> On 2/17/22 18:52, Paolo Bonzini wrote:
>>>> I would like to co-mentor one or more projects about adding more
>>>> statistics to Mark Kanda's newly-born introspectable statistics
>>>> subsystem in QEMU
>>>> (https://patchew.org/QEMU/20220215150433.2310711-1-mark.kanda@oracle.com/),
>>>> for example integrating "info blockstats"; and/or, to add matching
>>>> functionality to libvirt.
>>>>
>>>> However, I will only be available for co-mentoring unfortunately.
>>>
>>> I'm happy to offer my helping hand in this. I mean the libvirt part,
>>> since I am a libvirt developer.
>>>
>>> I believe this will be listed in QEMU's ideas list, right?
>>
>> Does Libvirt participate to GSoC as an independent organization this
>> year?  If not, I'll add it as a Libvirt project on the QEMU ideas list.
> 
> Libvirt participates as its own GSoC organization. If a project has
> overlap we could do it in either org, or have a QEMU project and a
> libvirt project if the amount of work is large enough.

Indeed. Libvirt's participating on its own since 2016, IIRC. Since we're
still in org acceptance phase we have some time to decide this,
actually. We can do the final decision after participating orgs are
announced. My gut feeling says that it's going to be more work on QEMU
side which would warrant it to be on the QEMU ideas page.

But anyway, we can wait an see. Meanwhile, as Stefan is trying to
compile the list for org application, I'm okay with putting it onto
QEMU's list.

Michal

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Paolo Bonzini]

On 2/21/22 10:36, Michal Prívozník wrote:
> Indeed. Libvirt's participating on its own since 2016, IIRC. Since we're
> still in org acceptance phase we have some time to decide this,
> actually. We can do the final decision after participating orgs are
> announced. My gut feeling says that it's going to be more work on QEMU
> side which would warrant it to be on the QEMU ideas page.

There are multiple projects that can be done on this topic, some 
QEMU-only, some Libvirt-only.  For now I would announce the project on 
the Libvirt side (and focus on those projects) since you are comentoring.

Paolo

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Klaus Jensen]

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

On Feb 21 09:51, Stefan Hajnoczi wrote:
> On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its@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@kernel.org/T/#u


Klaus

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Klaus Jensen]

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

On Feb 21 09:51, Stefan Hajnoczi wrote:
> On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its@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@kernel.org/T/#u


Klaus

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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Michal Prívozník]

On 2/21/22 12:27, Paolo Bonzini wrote:
> On 2/21/22 10:36, Michal Prívozník wrote:
>> Indeed. Libvirt's participating on its own since 2016, IIRC. Since we're
>> still in org acceptance phase we have some time to decide this,
>> actually. We can do the final decision after participating orgs are
>> announced. My gut feeling says that it's going to be more work on QEMU
>> side which would warrant it to be on the QEMU ideas page.
> 
> There are multiple projects that can be done on this topic, some
> QEMU-only, some Libvirt-only.  For now I would announce the project on
> the Libvirt side (and focus on those projects) since you are comentoring.
> 

Alright then. I've listed the project idea here:

https://gitlab.com/libvirt/libvirt/-/issues/276

Please let me know what do you think.

Michal

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 21 Feb 2022 at 12:00, Klaus Jensen <its@irrelevant.dk> wrote:
>
> On Feb 21 09:51, Stefan Hajnoczi wrote:
> > On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its@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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 21 Feb 2022 at 12:00, Klaus Jensen <its@irrelevant.dk> wrote:
>
> On Feb 21 09:51, Stefan Hajnoczi wrote:
> > On Mon, 21 Feb 2022 at 06:14, Klaus Jensen <its@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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Keith Busch]

On Tue, Feb 22, 2022 at 09:48:06AM +0000, Stefan Hajnoczi wrote:
> On Mon, 21 Feb 2022 at 12:00, Klaus Jensen <its@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@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.

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Keith Busch]

On Tue, Feb 22, 2022 at 09:48:06AM +0000, Stefan Hajnoczi wrote:
> On Mon, 21 Feb 2022 at 12:00, Klaus Jensen <its@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@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.

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Andreea Florescu]

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@amazon.com
- gsserge@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.

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Tue, 22 Feb 2022 at 15:03, Keith Busch <kbusch@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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Tue, 22 Feb 2022 at 15:03, Keith Busch <kbusch@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@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Wed, 23 Feb 2022 at 08:48, Andreea Florescu <fandree@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Wed, 23 Feb 2022 at 08:48, Andreea Florescu <fandree@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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 14 Feb 2022 at 13:58, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Wed, 9 Feb 2022 at 14:50, Alexander Graf <graf@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@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.

Hi Alex,
Would you like me to add this project idea to the list? Please see
what I wrote above about adding details about the tasks involved.

Thanks,
Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Mon, 14 Feb 2022 at 13:58, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Wed, 9 Feb 2022 at 14:50, Alexander Graf <graf@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@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.

Hi Alex,
Would you like me to add this project idea to the list? Please see
what I wrote above about adding details about the tasks involved.

Thanks,
Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Alexander Graf]

Hey Stefan!

On 16.03.22 14:16, Stefan Hajnoczi wrote:
> On Mon, 14 Feb 2022 at 13:58, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> On Wed, 9 Feb 2022 at 14:50, Alexander Graf <graf@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@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:


I must've completely missed your email, sorry :).


>> - Implement a device model for the TPM device (link to spec or driver
>> code below)
>> - Implement vsock device (or is this virtio-mmio vsock?)


Yeah, it's derived from Firecracker. So virtio-mmio for 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.
> Hi Alex,
> Would you like me to add this project idea to the list? Please see
> what I wrote above about adding details about the tasks involved.


Petre literally pointed me to the fact that the project did not end up 
on the wiki page a few hours ago. I added it and augmented the bits 
above. Please let me know if you see anything else missing! :)


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

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Wed, 16 Mar 2022 at 13:36, Alexander Graf <graf@amazon.com> wrote:
> Petre literally pointed me to the fact that the project did not end up
> on the wiki page a few hours ago. I added it and augmented the bits
> above. Please let me know if you see anything else missing! :)

Thanks for posting it!

Stefan

Re: Call for GSoC and Outreachy project ideas for summer 2022

[Stefan Hajnoczi]

On Wed, 16 Mar 2022 at 13:36, Alexander Graf <graf@amazon.com> wrote:
> Petre literally pointed me to the fact that the project did not end up
> on the wiki page a few hours ago. I added it and augmented the bits
> above. Please let me know if you see anything else missing! :)

Thanks for posting it!

Stefan