Call for GSoC/Outreachy internship project ideas

Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

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

Internship programs
---------------------------
GSoC (https://summerofcode.withgoogle.com/) and Outreachy
(https://www.outreachy.org/) offer paid open source remote work
internships to eligible people wishing to participate in open source
development. QEMU has been part of these internship programs for many
years. Our mentors have enjoyed helping talented interns make their
first open source contributions and some former interns continue to
participate today.

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

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

=== TITLE ===

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

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

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

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

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

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

Thanks,
Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

On Tue, 23 Jan 2024 at 22:47, Gurchetan Singh
<gurchetansingh@chromium.org> wrote:
> Title:
> - Improve display integration for upstream virtualized graphics
>
> Summary:
> - The Rutabaga Virtual Graphics interface's UI integration upstream is very simple, but in deployment it will be complex.  This project aims to bridge the gap between downstream consumers and upstream QEMU.
>
> Looking for someone interested in Rust + system level graphics to help realize the next steps.

Hi Gurchetan,
It's unclear what this project idea entails.

Based on your email my guess is you're looking for someone to help
upstream code into QEMU, but I'm not sure. Last year there was a
project to upstream bsd-user emulation code into QEMU and I think that
type of project can work well.

Or maybe you're looking for someone to write a QEMU UI code that uses
rutabaga_gfx.

Can you describe the next steps in more detail?

The project description should contain enough information for someone
who knows how to program but has no domain knowledge in Rutabaga,
virtio-gpu, or QEMU.

> Note: developers should be willing to sign Google CLA, here:
>
> https://cla.developers.google.com/about/google-individual
>
> But everything will be FOSS.

Which codebase will this project touch? If a CLA is required then it
sounds like it's not qemu.git?

> Links
> - https://crosvm.dev/book/appendix/rutabaga_gfx.html
> - https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/
>
> Skills
>  - Level: Advanced
>  - Rust, Vulkan, virtualization, cross-platform graphics

Re: Call for GSoC/Outreachy internship project ideas

[Gurchetan Singh]

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

On Wed, Jan 24, 2024 at 4:51 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Tue, 23 Jan 2024 at 22:47, Gurchetan Singh
> <gurchetansingh@chromium.org> wrote:
> > Title:
> > - Improve display integration for upstream virtualized graphics
> >
> > Summary:
> > - The Rutabaga Virtual Graphics interface's UI integration upstream is
> very simple, but in deployment it will be complex.  This project aims to
> bridge the gap between downstream consumers and upstream QEMU.
> >
> > Looking for someone interested in Rust + system level graphics to help
> realize the next steps.
>
> Hi Gurchetan,
> It's unclear what this project idea entails.
>
> Based on your email my guess is you're looking for someone to help
> upstream code into QEMU, but I'm not sure. Last year there was a
> project to upstream bsd-user emulation code into QEMU and I think that
> type of project can work well.
>
> Or maybe you're looking for someone to write a QEMU UI code that uses
> rutabaga_gfx.
>
> Can you describe the next steps in more detail?
>
> The project description should contain enough information for someone
> who knows how to program but has no domain knowledge in Rutabaga,
> virtio-gpu, or QEMU.
>
> > Note: developers should be willing to sign Google CLA, here:
> >
> > https://cla.developers.google.com/about/google-individual
> >
> > But everything will be FOSS.
>
> Which codebase will this project touch? If a CLA is required then it
> sounds like it's not qemu.git?
>

Good points, I think we need to think about this a bit more ....  I hereby
withdraw the idea!


>
> > Links
> > - https://crosvm.dev/book/appendix/rutabaga_gfx.html
> > -
> https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/
> >
> > Skills
> >  - Level: Advanced
> >  - Rust, Vulkan, virtualization, cross-platform graphics
>

[-- Attachment #2: Type: text/html, Size: 2922 bytes --]

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

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

On Wed, Jan 31, 2024, 18:55 Gurchetan Singh <gurchetansingh@chromium.org>
wrote:

>
>
> On Wed, Jan 24, 2024 at 4:51 AM Stefan Hajnoczi <stefanha@gmail.com>
> wrote:
>
>> On Tue, 23 Jan 2024 at 22:47, Gurchetan Singh
>> <gurchetansingh@chromium.org> wrote:
>> > Title:
>> > - Improve display integration for upstream virtualized graphics
>> >
>> > Summary:
>> > - The Rutabaga Virtual Graphics interface's UI integration upstream is
>> very simple, but in deployment it will be complex.  This project aims to
>> bridge the gap between downstream consumers and upstream QEMU.
>> >
>> > Looking for someone interested in Rust + system level graphics to help
>> realize the next steps.
>>
>> Hi Gurchetan,
>> It's unclear what this project idea entails.
>>
>> Based on your email my guess is you're looking for someone to help
>> upstream code into QEMU, but I'm not sure. Last year there was a
>> project to upstream bsd-user emulation code into QEMU and I think that
>> type of project can work well.
>>
>> Or maybe you're looking for someone to write a QEMU UI code that uses
>> rutabaga_gfx.
>>
>> Can you describe the next steps in more detail?
>>
>> The project description should contain enough information for someone
>> who knows how to program but has no domain knowledge in Rutabaga,
>> virtio-gpu, or QEMU.
>>
>> > Note: developers should be willing to sign Google CLA, here:
>> >
>> > https://cla.developers.google.com/about/google-individual
>> >
>> > But everything will be FOSS.
>>
>> Which codebase will this project touch? If a CLA is required then it
>> sounds like it's not qemu.git?
>>
>
> Good points, I think we need to think about this a bit more ....  I hereby
> withdraw the idea!
>

The project doesn't necessarily need to be in qemu.git. Just something that
is related to QEMU. Past projects have included rust-vmm crates, libnbd,
libblkio, etc.

If the code is used in conjunction with a QEMU guest, then it is probably
in scope.

We can discuss further if you like.

Stefan


>
>>
>> > Links
>> > - https://crosvm.dev/book/appendix/rutabaga_gfx.html
>> > -
>> https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/
>> >
>> > Skills
>> >  - Level: Advanced
>> >  - Rust, Vulkan, virtualization, cross-platform graphics
>>
>

[-- Attachment #2: Type: text/html, Size: 4086 bytes --]

Re: Call for GSoC/Outreachy internship project ideas

[Eugenio Perez Martin]

On Mon, Jan 15, 2024 at 5:33 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code and Outreachy internship
> programs again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email before
> January 30th.
>


=== Add packed virtqueue to Shadow Virtqueue ===
Summary: Add the packed virtqueue format support to QEMU's Shadow Virtqueue.

To perform a virtual machine live migration with an external device to
qemu, qemu needs a way to know which memory the device modifies so it
is able to resend it. Otherwise the guest would resume with invalid /
outdated memory in the destination.

This is especially hard with passthrough hardware devices, as
transports like PCI imposes a few security and performance challenges.
As a method to overcome this for virtio devices, qemu can offer an
emulated virtqueue to the device, called Shadow Virtqueue (SVQ),
instead of allowing the device to communicate directly with the guest.
SVQ will then forward the writes to the guest, being the effective
writer in the guest memory and knowing when a portion of it needs to
be resent.

Compared with original Split Virtqueues, already supported by Shadow
Virtqueue, Packed virtqueue is a more compact representation that uses
less memory size and allows both devices and drivers to exchange the
same amount of information with less memory operations.

The task is to complete the packed virtqueue support for SVQ, using
the kernel virtio ring driver as a reference. There is already a setup
that can be used to test the changes.

Links:
* https://www.redhat.com/en/blog/virtio-devices-and-drivers-overview-headjack-and-phone
* https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
* https://www.redhat.com/en/blog/packed-virtqueue-how-reduce-overhead-virtio
* https://www.youtube.com/watch?v=x9ARoNVzS04

Details:
* Skill level: Intermediate
* Language: C

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

On Mon, 29 Jan 2024 at 13:53, Eugenio Perez Martin <eperezma@redhat.com> wrote:
>
> On Mon, Jan 15, 2024 at 5:33 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code and Outreachy internship
> > programs again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email before
> > January 30th.
> >
>
>
> === Add packed virtqueue to Shadow Virtqueue ===

Yes! I'm a fan of packed virtqueues, so I'm excited to see this project idea :).

> Summary: Add the packed virtqueue format support to QEMU's Shadow Virtqueue.
>
> To perform a virtual machine live migration with an external device to
> qemu, qemu needs a way to know which memory the device modifies so it
> is able to resend it. Otherwise the guest would resume with invalid /
> outdated memory in the destination.
>
> This is especially hard with passthrough hardware devices, as
> transports like PCI imposes a few security and performance challenges.
> As a method to overcome this for virtio devices, qemu can offer an
> emulated virtqueue to the device, called Shadow Virtqueue (SVQ),
> instead of allowing the device to communicate directly with the guest.
> SVQ will then forward the writes to the guest, being the effective
> writer in the guest memory and knowing when a portion of it needs to
> be resent.
>
> Compared with original Split Virtqueues, already supported by Shadow
> Virtqueue, Packed virtqueue is a more compact representation that uses
> less memory size and allows both devices and drivers to exchange the
> same amount of information with less memory operations.
>
> The task is to complete the packed virtqueue support for SVQ, using
> the kernel virtio ring driver as a reference. There is already a setup
> that can be used to test the changes.
>
> Links:
> * https://www.redhat.com/en/blog/virtio-devices-and-drivers-overview-headjack-and-phone
> * https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
> * https://www.redhat.com/en/blog/packed-virtqueue-how-reduce-overhead-virtio
> * https://www.youtube.com/watch?v=x9ARoNVzS04
>
> Details:
> * Skill level: Intermediate
> * Language: C

I have added this project idea to the wiki. I made minor edits (e.g.
consistently using "guest" instead of both "virtual machine" and
"guest" to minimize the amount of terminology). I also added a link to
the vhost-shadow-virtqueue.c source code so applicants have a starting
point for researching the code.

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

Please edit the page to clarify the following:
- Project size: 90 (small), 175 (medium), or 350 (large) hours
- A list of suggested tasks for the coding period that applicants can
research and refine for their project plan

Possible stretch goals if the intern completes packed svq support
early or maybe you have your own ideas:
- Split/rename vhost-shadow-virtqueue.c into a VIRTIO driver-side
virtqueue API (which could be used by any other feature that acts as a
VIRTIO driver, like vhost-user clients) and shadow virtqueue logic
- Implement packed virtqueue support in other components where it is
not yet supported (like kernel vhost)

Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Eugenio Perez Martin]

On Mon, Jan 29, 2024 at 8:40 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Mon, 29 Jan 2024 at 13:53, Eugenio Perez Martin <eperezma@redhat.com> wrote:
> >
> > On Mon, Jan 15, 2024 at 5:33 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > >
> > > Dear QEMU and KVM communities,
> > > QEMU will apply for the Google Summer of Code and Outreachy internship
> > > programs again this year. Regular contributors can submit project
> > > ideas that they'd like to mentor by replying to this email before
> > > January 30th.
> > >
> >
> >
> > === Add packed virtqueue to Shadow Virtqueue ===
>
> Yes! I'm a fan of packed virtqueues, so I'm excited to see this project idea :).
>

It's about time! :).


> > Summary: Add the packed virtqueue format support to QEMU's Shadow Virtqueue.
> >
> > To perform a virtual machine live migration with an external device to
> > qemu, qemu needs a way to know which memory the device modifies so it
> > is able to resend it. Otherwise the guest would resume with invalid /
> > outdated memory in the destination.
> >
> > This is especially hard with passthrough hardware devices, as
> > transports like PCI imposes a few security and performance challenges.
> > As a method to overcome this for virtio devices, qemu can offer an
> > emulated virtqueue to the device, called Shadow Virtqueue (SVQ),
> > instead of allowing the device to communicate directly with the guest.
> > SVQ will then forward the writes to the guest, being the effective
> > writer in the guest memory and knowing when a portion of it needs to
> > be resent.
> >
> > Compared with original Split Virtqueues, already supported by Shadow
> > Virtqueue, Packed virtqueue is a more compact representation that uses
> > less memory size and allows both devices and drivers to exchange the
> > same amount of information with less memory operations.
> >
> > The task is to complete the packed virtqueue support for SVQ, using
> > the kernel virtio ring driver as a reference. There is already a setup
> > that can be used to test the changes.
> >
> > Links:
> > * https://www.redhat.com/en/blog/virtio-devices-and-drivers-overview-headjack-and-phone
> > * https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
> > * https://www.redhat.com/en/blog/packed-virtqueue-how-reduce-overhead-virtio
> > * https://www.youtube.com/watch?v=x9ARoNVzS04
> >
> > Details:
> > * Skill level: Intermediate
> > * Language: C
>
> I have added this project idea to the wiki. I made minor edits (e.g.
> consistently using "guest" instead of both "virtual machine" and
> "guest" to minimize the amount of terminology). I also added a link to
> the vhost-shadow-virtqueue.c source code so applicants have a starting
> point for researching the code.
>
> https://wiki.qemu.org/Internships/ProjectIdeas/PackedShadowVirtqueue
>

Good points, thank you very much!

> Please edit the page to clarify the following:
> - Project size: 90 (small), 175 (medium), or 350 (large) hours
> - A list of suggested tasks for the coding period that applicants can
> research and refine for their project plan
>
> Possible stretch goals if the intern completes packed svq support
> early or maybe you have your own ideas:
> - Split/rename vhost-shadow-virtqueue.c into a VIRTIO driver-side
> virtqueue API (which could be used by any other feature that acts as a
> VIRTIO driver, like vhost-user clients) and shadow virtqueue logic
> - Implement packed virtqueue support in other components where it is
> not yet supported (like kernel vhost)
>

Added, good ideas! Please let me know if you think something should be
further corrected or feel free to modify yourself.

Thanks!

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

Hi Eugenio,
Stefano Garzarella and I had a SVQ-related project idea that I have added:
https://wiki.qemu.org/Google_Summer_of_Code_2024#vhost-user_memory_isolation

We want to support vhost-user devices without exposing guest RAM. This
is attractive for security reasons in vhost-user-vsock where a process
that connects multiple guests should not give access to other guests'
RAM in the case of a security bug. It is also useful on host platforms
where guest RAM cannot be shared (we think this is the case on macOS
Hypervisor.framework).

Please let us know if you have any thoughts about sharing/refactoring
the SVQ code.

Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Eugenio Perez Martin]

On Tue, Jan 30, 2024 at 8:34 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Hi Eugenio,
> Stefano Garzarella and I had a SVQ-related project idea that I have added:
> https://wiki.qemu.org/Google_Summer_of_Code_2024#vhost-user_memory_isolation
>
> We want to support vhost-user devices without exposing guest RAM. This
> is attractive for security reasons in vhost-user-vsock where a process
> that connects multiple guests should not give access to other guests'
> RAM in the case of a security bug. It is also useful on host platforms
> where guest RAM cannot be shared (we think this is the case on macOS
> Hypervisor.framework).
>
> Please let us know if you have any thoughts about sharing/refactoring
> the SVQ code.
>

I'm totally in, sure :).

Actually I've been thinking about adding multithreading to SVQ. Since
SVQ reuses a lot of code from the emulated devices in virtio.c, it
would be great to add multithread to net devices too.

On the other hand, I've not added indirect descriptor support because
SVQ does not copy buffer memory by default, and there was little
benefit because HW does not like indirections. It seems to me that
reuse for your proposal would enable a justification to finally add
it.

Looking forward to this project, and I'd be happy to help it for sure. Thanks!

Re: Call for GSoC/Outreachy internship project ideas

[Alexander Graf]

Hey Stefan,

Thanks a lot for setting up GSoC this year again!

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


=== Implement -M nitro-enclave in QEMU  ===

'''Summary:''' AWS EC2 provides the ability to create an isolated 
sibling VM context from within a VM. This project implements the machine 
model and input data format parsing needed to run these sibling VMs 
stand alone 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 called NSM.

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 NSM, the vsock 
communication channel and building firmware which loads the special 
"EIF" file format which contains kernel, initramfs and metadata from a 
-kernel image.

If the student finishes early, we can then proceed to implement the 
Nitro Enclaves parent driver in QEMU as well to create a full QEMU-only 
Nitro Enclaves environment.

'''Tasks:'''
* Implement a device model for the NSM device (link to spec and driver 
code below)
* Implement a new machine model
* Implement firmware for the new machine model that implements EIF parsing
* Add tests for the NSM device
* Add integration test for the machine model executing an actual EIF payload

'''Links:'''
* https://aws.amazon.com/ec2/nitro/nitro-enclaves/
* 
https://lore.kernel.org/lkml/20200921121732.44291-10-andraprs@amazon.com/T/
* 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/misc/nsm.c

'''Details:'''
* Skill level: intermediate - advanced (some understanding of QEMU 
machine modeling would be good)
* Language: C
* Mentor: agraf
* Suggested by: Alexander Graf (OFTC: agraf, Email: graf@amazon.com)



Alex

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

On Tue, 30 Jan 2024 at 14:16, Alexander Graf <agraf@csgraf.de> wrote:
> === Implement -M nitro-enclave in QEMU  ===
>
> '''Summary:''' AWS EC2 provides the ability to create an isolated
> sibling VM context from within a VM. This project implements the machine
> model and input data format parsing needed to run these sibling VMs
> stand alone in QEMU.

Thanks, Alex. I have added this project to the wiki and added a few
links (e.g. EIF file format). Feel free to edit:

https://wiki.qemu.org/Google_Summer_of_Code_2024#Implement_-M_nitro-enclave_in_QEMU

Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Palmer Dabbelt]

On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
> Dear QEMU and KVM communities,
> QEMU will apply for the Google Summer of Code and Outreachy internship
> programs again this year. Regular contributors can submit project
> ideas that they'd like to mentor by replying to this email before
> January 30th.

It's the 30th, sorry if this is late but I just saw it today.  +Alistair 
and Daniel, as I didn't sync up with anyone about this so not sure if 
someone else is looking already (we're not internally).

> Internship programs
> ---------------------------
> GSoC (https://summerofcode.withgoogle.com/) and Outreachy
> (https://www.outreachy.org/) offer paid open source remote work
> internships to eligible people wishing to participate in open source
> development. QEMU has been part of these internship programs for many
> years. Our mentors have enjoyed helping talented interns make their
> first open source contributions and some former interns continue to
> participate today.
>
> Who can mentor
> ----------------------
> Regular contributors to QEMU and KVM can participate as mentors.
> Mentorship involves about 5 hours of time commitment per week to
> communicate with the intern, review their patches, etc. Time is also
> required during the intern selection phase to communicate with
> applicants. Being a mentor is an opportunity to help someone get
> started in open source development, will give you experience with
> managing a project in a low-stakes environment, and a chance to
> explore interesting technical ideas that you may not have time to
> develop yourself.
>
> How to propose your idea
> ----------------------------------
> Reply to this email with the following project idea template filled in:
>
> === TITLE ===
>
> '''Summary:''' Short description of the project
>
> Detailed description of the project that explains the general idea,
> including a list of high-level tasks that will be completed by the
> project, and provides enough background for someone unfamiliar with
> the codebase to do research. Typically 2 or 3 paragraphs.
>
> '''Links:'''
> * Wiki links to relevant material
> * External links to mailing lists or web sites
>
> '''Details:'''
> * Skill level: beginner or intermediate or advanced
> * Language: C/Python/Rust/etc

I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and 
might have some tricky parts.  That said it's tripping some people up 
and as far as I know nobody's started looking at it, so I figrued I'd 
write something up.

I can try and dig up some more links if folks thing it's interesting, 
IIRC there's been a handful of bug reports related to very small loops 
that run ~10x slower when vectorized.  Large benchmarks like SPEC have 
also shown slowdowns.

---

=== RISC-V Vector TCG Frontend Optimization ===

'''Summary:''' The RISC-V vector extension has been implemented in QEMU, 
but we have some performance pathologies mapping it to existing TCG 
backends.  This project would aim to improve the performance of the 
RISC-V vector ISA's mappings to TCG.

The RISC-V TCG frontend (ie, decoding RISC-V instructions 
and emitting TCG calls to emulate them) has some inefficient mappings to 
TCG, which results in binaries that have vector instructions frequently 
performing worse than those without, sometimes even up to 10x slower.  
This causes various headaches for users, including running toolchain 
regressions and doing distro work.  This project's aim would be to bring 
the performance of vectorized RISC-V code to a similar level as the 
corresponding scalar code.

This will definitely require changing the RISC-V TCG frontend.  It's 
likely there is some remaining optimization work that can be done 
without adding TCG primitives, but it may be necessary to do some core 
TCG work in order to improve performance sufficiently.

'''Links:'''
* https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg04495.html

'''Details'''
* Skill level: intermediate
* Language: C, RISC-V assembly

>
> More information
> ----------------------
> You can find out about the process we follow here:
> Video: https://www.youtube.com/watch?v=xNVCX7YMUL8
> Slides (PDF): https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
>
> The QEMU wiki page for GSoC 2024 is now available:
> https://wiki.qemu.org/Google_Summer_of_Code_2024
>
> Thanks,
> Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
> > Dear QEMU and KVM communities,
> > QEMU will apply for the Google Summer of Code and Outreachy internship
> > programs again this year. Regular contributors can submit project
> > ideas that they'd like to mentor by replying to this email before
> > January 30th.
>
> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
> and Daniel, as I didn't sync up with anyone about this so not sure if
> someone else is looking already (we're not internally).
>
> > Internship programs
> > ---------------------------
> > GSoC (https://summerofcode.withgoogle.com/) and Outreachy
> > (https://www.outreachy.org/) offer paid open source remote work
> > internships to eligible people wishing to participate in open source
> > development. QEMU has been part of these internship programs for many
> > years. Our mentors have enjoyed helping talented interns make their
> > first open source contributions and some former interns continue to
> > participate today.
> >
> > Who can mentor
> > ----------------------
> > Regular contributors to QEMU and KVM can participate as mentors.
> > Mentorship involves about 5 hours of time commitment per week to
> > communicate with the intern, review their patches, etc. Time is also
> > required during the intern selection phase to communicate with
> > applicants. Being a mentor is an opportunity to help someone get
> > started in open source development, will give you experience with
> > managing a project in a low-stakes environment, and a chance to
> > explore interesting technical ideas that you may not have time to
> > develop yourself.
> >
> > How to propose your idea
> > ----------------------------------
> > Reply to this email with the following project idea template filled in:
> >
> > === TITLE ===
> >
> > '''Summary:''' Short description of the project
> >
> > Detailed description of the project that explains the general idea,
> > including a list of high-level tasks that will be completed by the
> > project, and provides enough background for someone unfamiliar with
> > the codebase to do research. Typically 2 or 3 paragraphs.
> >
> > '''Links:'''
> > * Wiki links to relevant material
> > * External links to mailing lists or web sites
> >
> > '''Details:'''
> > * Skill level: beginner or intermediate or advanced
> > * Language: C/Python/Rust/etc
>
> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and
> might have some tricky parts.  That said it's tripping some people up
> and as far as I know nobody's started looking at it, so I figrued I'd
> write something up.
>
> I can try and dig up some more links if folks thing it's interesting,
> IIRC there's been a handful of bug reports related to very small loops
> that run ~10x slower when vectorized.  Large benchmarks like SPEC have
> also shown slowdowns.

Hi Palmer,
Performance optimization can be challenging for newcomers. I wouldn't
recommend it for a GSoC project unless you have time to seed the
project idea with specific optimizations to implement based on your
experience and profiling. That way the intern has a solid starting
point where they can have a few successes before venturing out to do
their own performance analysis.

Do you have the time to profile and add specifics to the project idea
by Feb 21st? If that sounds good to you, I'll add it to the project
ideas list and you can add more detailed tasks in the coming weeks.

Thanks,
Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Palmer Dabbelt]

On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@gmail.com wrote:
> On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
>> > Dear QEMU and KVM communities,
>> > QEMU will apply for the Google Summer of Code and Outreachy internship
>> > programs again this year. Regular contributors can submit project
>> > ideas that they'd like to mentor by replying to this email before
>> > January 30th.
>>
>> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
>> and Daniel, as I didn't sync up with anyone about this so not sure if
>> someone else is looking already (we're not internally).
>>
>> > Internship programs
>> > ---------------------------
>> > GSoC (https://summerofcode.withgoogle.com/) and Outreachy
>> > (https://www.outreachy.org/) offer paid open source remote work
>> > internships to eligible people wishing to participate in open source
>> > development. QEMU has been part of these internship programs for many
>> > years. Our mentors have enjoyed helping talented interns make their
>> > first open source contributions and some former interns continue to
>> > participate today.
>> >
>> > Who can mentor
>> > ----------------------
>> > Regular contributors to QEMU and KVM can participate as mentors.
>> > Mentorship involves about 5 hours of time commitment per week to
>> > communicate with the intern, review their patches, etc. Time is also
>> > required during the intern selection phase to communicate with
>> > applicants. Being a mentor is an opportunity to help someone get
>> > started in open source development, will give you experience with
>> > managing a project in a low-stakes environment, and a chance to
>> > explore interesting technical ideas that you may not have time to
>> > develop yourself.
>> >
>> > How to propose your idea
>> > ----------------------------------
>> > Reply to this email with the following project idea template filled in:
>> >
>> > === TITLE ===
>> >
>> > '''Summary:''' Short description of the project
>> >
>> > Detailed description of the project that explains the general idea,
>> > including a list of high-level tasks that will be completed by the
>> > project, and provides enough background for someone unfamiliar with
>> > the codebase to do research. Typically 2 or 3 paragraphs.
>> >
>> > '''Links:'''
>> > * Wiki links to relevant material
>> > * External links to mailing lists or web sites
>> >
>> > '''Details:'''
>> > * Skill level: beginner or intermediate or advanced
>> > * Language: C/Python/Rust/etc
>>
>> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and
>> might have some tricky parts.  That said it's tripping some people up
>> and as far as I know nobody's started looking at it, so I figrued I'd
>> write something up.
>>
>> I can try and dig up some more links if folks thing it's interesting,
>> IIRC there's been a handful of bug reports related to very small loops
>> that run ~10x slower when vectorized.  Large benchmarks like SPEC have
>> also shown slowdowns.
>
> Hi Palmer,
> Performance optimization can be challenging for newcomers. I wouldn't
> recommend it for a GSoC project unless you have time to seed the
> project idea with specific optimizations to implement based on your
> experience and profiling. That way the intern has a solid starting
> point where they can have a few successes before venturing out to do
> their own performance analysis.

Ya, I agree.  That's part of the reason why I wasn't sure if it's a 
good idea.  At least for this one I think there should be some easy to 
understand performance issue, as the loops that go very slowly consist 
of a small number of instructions and go a lot slower.

I'm actually more worried about this running into a rabbit hole of 
adding new TCG operations or even just having no well defined mappings 
between RVV and AVX, those might make the project really hard.

> Do you have the time to profile and add specifics to the project idea
> by Feb 21st? If that sounds good to you, I'll add it to the project
> ideas list and you can add more detailed tasks in the coming weeks.

I can at least dig up some of the examples I ran into, there's been a 
handful filtering in over the last year or so.

This one 
<https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba> 
still has a much more than 10x slowdown (73ms -> 13s) with 
vectorization, for example.

> Thanks,
> Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Alistair Francis]

On Wed, Jan 31, 2024 at 10:30 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@gmail.com wrote:
> > On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>
> >> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
> >> > Dear QEMU and KVM communities,
> >> > QEMU will apply for the Google Summer of Code and Outreachy internship
> >> > programs again this year. Regular contributors can submit project
> >> > ideas that they'd like to mentor by replying to this email before
> >> > January 30th.
> >>
> >> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
> >> and Daniel, as I didn't sync up with anyone about this so not sure if
> >> someone else is looking already (we're not internally).
> >>
> >> > Internship programs
> >> > ---------------------------
> >> > GSoC (https://summerofcode.withgoogle.com/) and Outreachy
> >> > (https://www.outreachy.org/) offer paid open source remote work
> >> > internships to eligible people wishing to participate in open source
> >> > development. QEMU has been part of these internship programs for many
> >> > years. Our mentors have enjoyed helping talented interns make their
> >> > first open source contributions and some former interns continue to
> >> > participate today.
> >> >
> >> > Who can mentor
> >> > ----------------------
> >> > Regular contributors to QEMU and KVM can participate as mentors.
> >> > Mentorship involves about 5 hours of time commitment per week to
> >> > communicate with the intern, review their patches, etc. Time is also
> >> > required during the intern selection phase to communicate with
> >> > applicants. Being a mentor is an opportunity to help someone get
> >> > started in open source development, will give you experience with
> >> > managing a project in a low-stakes environment, and a chance to
> >> > explore interesting technical ideas that you may not have time to
> >> > develop yourself.
> >> >
> >> > How to propose your idea
> >> > ----------------------------------
> >> > Reply to this email with the following project idea template filled in:
> >> >
> >> > === TITLE ===
> >> >
> >> > '''Summary:''' Short description of the project
> >> >
> >> > Detailed description of the project that explains the general idea,
> >> > including a list of high-level tasks that will be completed by the
> >> > project, and provides enough background for someone unfamiliar with
> >> > the codebase to do research. Typically 2 or 3 paragraphs.
> >> >
> >> > '''Links:'''
> >> > * Wiki links to relevant material
> >> > * External links to mailing lists or web sites
> >> >
> >> > '''Details:'''
> >> > * Skill level: beginner or intermediate or advanced
> >> > * Language: C/Python/Rust/etc
> >>
> >> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and
> >> might have some tricky parts.  That said it's tripping some people up
> >> and as far as I know nobody's started looking at it, so I figrued I'd
> >> write something up.
> >>
> >> I can try and dig up some more links if folks thing it's interesting,
> >> IIRC there's been a handful of bug reports related to very small loops
> >> that run ~10x slower when vectorized.  Large benchmarks like SPEC have
> >> also shown slowdowns.
> >
> > Hi Palmer,
> > Performance optimization can be challenging for newcomers. I wouldn't
> > recommend it for a GSoC project unless you have time to seed the
> > project idea with specific optimizations to implement based on your
> > experience and profiling. That way the intern has a solid starting
> > point where they can have a few successes before venturing out to do
> > their own performance analysis.
>
> Ya, I agree.  That's part of the reason why I wasn't sure if it's a
> good idea.  At least for this one I think there should be some easy to
> understand performance issue, as the loops that go very slowly consist
> of a small number of instructions and go a lot slower.
>
> I'm actually more worried about this running into a rabbit hole of
> adding new TCG operations or even just having no well defined mappings
> between RVV and AVX, those might make the project really hard.
>
> > Do you have the time to profile and add specifics to the project idea
> > by Feb 21st? If that sounds good to you, I'll add it to the project
> > ideas list and you can add more detailed tasks in the coming weeks.
>
> I can at least dig up some of the examples I ran into, there's been a
> handful filtering in over the last year or so.
>
> This one
> <https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba>
> still has a much more than 10x slowdown (73ms -> 13s) with
> vectorization, for example.

It's probably worth creating a Gitlab issue for this and adding all of
the examples there. That way we have a single place to store them all

Alistair

>
> > Thanks,
> > Stefan
>

Re: Call for GSoC/Outreachy internship project ideas

[Palmer Dabbelt]

On Tue, 30 Jan 2024 17:26:11 PST (-0800), alistair23@gmail.com wrote:
> On Wed, Jan 31, 2024 at 10:30 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@gmail.com wrote:
>> > On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >>
>> >> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
>> >> > Dear QEMU and KVM communities,
>> >> > QEMU will apply for the Google Summer of Code and Outreachy internship
>> >> > programs again this year. Regular contributors can submit project
>> >> > ideas that they'd like to mentor by replying to this email before
>> >> > January 30th.
>> >>
>> >> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
>> >> and Daniel, as I didn't sync up with anyone about this so not sure if
>> >> someone else is looking already (we're not internally).
>> >>
>> >> > Internship programs
>> >> > ---------------------------
>> >> > GSoC (https://summerofcode.withgoogle.com/) and Outreachy
>> >> > (https://www.outreachy.org/) offer paid open source remote work
>> >> > internships to eligible people wishing to participate in open source
>> >> > development. QEMU has been part of these internship programs for many
>> >> > years. Our mentors have enjoyed helping talented interns make their
>> >> > first open source contributions and some former interns continue to
>> >> > participate today.
>> >> >
>> >> > Who can mentor
>> >> > ----------------------
>> >> > Regular contributors to QEMU and KVM can participate as mentors.
>> >> > Mentorship involves about 5 hours of time commitment per week to
>> >> > communicate with the intern, review their patches, etc. Time is also
>> >> > required during the intern selection phase to communicate with
>> >> > applicants. Being a mentor is an opportunity to help someone get
>> >> > started in open source development, will give you experience with
>> >> > managing a project in a low-stakes environment, and a chance to
>> >> > explore interesting technical ideas that you may not have time to
>> >> > develop yourself.
>> >> >
>> >> > How to propose your idea
>> >> > ----------------------------------
>> >> > Reply to this email with the following project idea template filled in:
>> >> >
>> >> > === TITLE ===
>> >> >
>> >> > '''Summary:''' Short description of the project
>> >> >
>> >> > Detailed description of the project that explains the general idea,
>> >> > including a list of high-level tasks that will be completed by the
>> >> > project, and provides enough background for someone unfamiliar with
>> >> > the codebase to do research. Typically 2 or 3 paragraphs.
>> >> >
>> >> > '''Links:'''
>> >> > * Wiki links to relevant material
>> >> > * External links to mailing lists or web sites
>> >> >
>> >> > '''Details:'''
>> >> > * Skill level: beginner or intermediate or advanced
>> >> > * Language: C/Python/Rust/etc
>> >>
>> >> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and
>> >> might have some tricky parts.  That said it's tripping some people up
>> >> and as far as I know nobody's started looking at it, so I figrued I'd
>> >> write something up.
>> >>
>> >> I can try and dig up some more links if folks thing it's interesting,
>> >> IIRC there's been a handful of bug reports related to very small loops
>> >> that run ~10x slower when vectorized.  Large benchmarks like SPEC have
>> >> also shown slowdowns.
>> >
>> > Hi Palmer,
>> > Performance optimization can be challenging for newcomers. I wouldn't
>> > recommend it for a GSoC project unless you have time to seed the
>> > project idea with specific optimizations to implement based on your
>> > experience and profiling. That way the intern has a solid starting
>> > point where they can have a few successes before venturing out to do
>> > their own performance analysis.
>>
>> Ya, I agree.  That's part of the reason why I wasn't sure if it's a
>> good idea.  At least for this one I think there should be some easy to
>> understand performance issue, as the loops that go very slowly consist
>> of a small number of instructions and go a lot slower.
>>
>> I'm actually more worried about this running into a rabbit hole of
>> adding new TCG operations or even just having no well defined mappings
>> between RVV and AVX, those might make the project really hard.
>>
>> > Do you have the time to profile and add specifics to the project idea
>> > by Feb 21st? If that sounds good to you, I'll add it to the project
>> > ideas list and you can add more detailed tasks in the coming weeks.
>>
>> I can at least dig up some of the examples I ran into, there's been a
>> handful filtering in over the last year or so.
>>
>> This one
>> <https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba>
>> still has a much more than 10x slowdown (73ms -> 13s) with
>> vectorization, for example.
>
> It's probably worth creating a Gitlab issue for this and adding all of
> the examples there. That way we have a single place to store them all

Makes sense.  I think I'd been telling people to make bug reports for 
them, so there might be some in there already -- I just dug this one out 
of some history.

Here's a start: https://gitlab.com/qemu-project/qemu/-/issues/2137

>
> Alistair
>
>>
>> > Thanks,
>> > Stefan
>>

Re: Call for GSoC/Outreachy internship project ideas

[Alex Bennée]

Palmer Dabbelt <palmer@dabbelt.com> writes:

> On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@gmail.com wrote:
>> On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>
>>> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
>>> > Dear QEMU and KVM communities,
>>> > QEMU will apply for the Google Summer of Code and Outreachy internship
>>> > programs again this year. Regular contributors can submit project
>>> > ideas that they'd like to mentor by replying to this email before
>>> > January 30th.
>>>
>>> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
>>> and Daniel, as I didn't sync up with anyone about this so not sure if
>>> someone else is looking already (we're not internally).
<snip>
>> Hi Palmer,
>> Performance optimization can be challenging for newcomers. I wouldn't
>> recommend it for a GSoC project unless you have time to seed the
>> project idea with specific optimizations to implement based on your
>> experience and profiling. That way the intern has a solid starting
>> point where they can have a few successes before venturing out to do
>> their own performance analysis.
>
> Ya, I agree.  That's part of the reason why I wasn't sure if it's a
> good idea.  At least for this one I think there should be some easy to
> understand performance issue, as the loops that go very slowly consist
> of a small number of instructions and go a lot slower.
>
> I'm actually more worried about this running into a rabbit hole of
> adding new TCG operations or even just having no well defined mappings
> between RVV and AVX, those might make the project really hard.

You shouldn't have a hard guest-target mapping. But are you already
using the TCGVec types and they are not expanding to AVX when its
available?

Remember for anything float we will end up with softfloat anyway so we
can't use SIMD on the backend.

>
>> Do you have the time to profile and add specifics to the project idea
>> by Feb 21st? If that sounds good to you, I'll add it to the project
>> ideas list and you can add more detailed tasks in the coming weeks.
>
> I can at least dig up some of the examples I ran into, there's been a
> handful filtering in over the last year or so.
>
> This one
> <https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba>
> still has a much more than 10x slowdown (73ms -> 13s) with
> vectorization, for example.
>
>> Thanks,
>> Stefan

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC/Outreachy internship project ideas

[Palmer Dabbelt]

On Thu, 01 Feb 2024 09:39:22 PST (-0800), alex.bennee@linaro.org wrote:
> Palmer Dabbelt <palmer@dabbelt.com> writes:
>
>> On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@gmail.com wrote:
>>> On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>>
>>>> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
>>>> > Dear QEMU and KVM communities,
>>>> > QEMU will apply for the Google Summer of Code and Outreachy internship
>>>> > programs again this year. Regular contributors can submit project
>>>> > ideas that they'd like to mentor by replying to this email before
>>>> > January 30th.
>>>>
>>>> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
>>>> and Daniel, as I didn't sync up with anyone about this so not sure if
>>>> someone else is looking already (we're not internally).
> <snip>
>>> Hi Palmer,
>>> Performance optimization can be challenging for newcomers. I wouldn't
>>> recommend it for a GSoC project unless you have time to seed the
>>> project idea with specific optimizations to implement based on your
>>> experience and profiling. That way the intern has a solid starting
>>> point where they can have a few successes before venturing out to do
>>> their own performance analysis.
>>
>> Ya, I agree.  That's part of the reason why I wasn't sure if it's a
>> good idea.  At least for this one I think there should be some easy to
>> understand performance issue, as the loops that go very slowly consist
>> of a small number of instructions and go a lot slower.
>>
>> I'm actually more worried about this running into a rabbit hole of
>> adding new TCG operations or even just having no well defined mappings
>> between RVV and AVX, those might make the project really hard.
>
> You shouldn't have a hard guest-target mapping. But are you already
> using the TCGVec types and they are not expanding to AVX when its
> available?

Ya, sorry, I guess that was an odd way to describe it.  IIUC we're doing 
sane stuff, it's just that RISC-V has a very different vector masking 
model than other ISAs.  I just said AVX there because I only care about 
the performance on Intel servers, since that's what I run QEMU on.  I'd 
asssume we have similar performance problems on other targets, I just 
haven't looked.

So my worry would be that the RVV things we're doing slowly just don't 
have fast implementations via AVX and thus we run into some intractable 
problems.  That sort of stuff can be really frusturating for an intern, 
as everything's new to them so it can be hard to know when something's 
an optimization dead end.

That said, we're seeing 100x slowdows in microbenchmarks and 10x 
slowdowns in real code, so I think there sholud be some way to do 
better.

> Remember for anything float we will end up with softfloat anyway so we
> can't use SIMD on the backend.

Yep, but we have a handful of integer slowdowns too so I think there's 
some meat to chew on here.  The softfloat stuff should be equally slow 
for scalar/vector, so we shouldn't be tripping false positives there.

>>> Do you have the time to profile and add specifics to the project idea
>>> by Feb 21st? If that sounds good to you, I'll add it to the project
>>> ideas list and you can add more detailed tasks in the coming weeks.
>>
>> I can at least dig up some of the examples I ran into, there's been a
>> handful filtering in over the last year or so.
>>
>> This one
>> <https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba>
>> still has a much more than 10x slowdown (73ms -> 13s) with
>> vectorization, for example.
>>
>>> Thanks,
>>> Stefan
>
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

Re: Call for GSoC/Outreachy internship project ideas

[Alex Bennée]

Palmer Dabbelt <palmer@dabbelt.com> writes:

> On Thu, 01 Feb 2024 09:39:22 PST (-0800), alex.bennee@linaro.org wrote:
>> Palmer Dabbelt <palmer@dabbelt.com> writes:
>>
>>> On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@gmail.com wrote:
>>>> On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>>>
>>>>> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
>>>>> > Dear QEMU and KVM communities,
>>>>> > QEMU will apply for the Google Summer of Code and Outreachy internship
>>>>> > programs again this year. Regular contributors can submit project
>>>>> > ideas that they'd like to mentor by replying to this email before
>>>>> > January 30th.
>>>>>
>>>>> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
>>>>> and Daniel, as I didn't sync up with anyone about this so not sure if
>>>>> someone else is looking already (we're not internally).
>> <snip>
>>>> Hi Palmer,
>>>> Performance optimization can be challenging for newcomers. I wouldn't
>>>> recommend it for a GSoC project unless you have time to seed the
>>>> project idea with specific optimizations to implement based on your
>>>> experience and profiling. That way the intern has a solid starting
>>>> point where they can have a few successes before venturing out to do
>>>> their own performance analysis.
>>>
>>> Ya, I agree.  That's part of the reason why I wasn't sure if it's a
>>> good idea.  At least for this one I think there should be some easy to
>>> understand performance issue, as the loops that go very slowly consist
>>> of a small number of instructions and go a lot slower.
>>>
>>> I'm actually more worried about this running into a rabbit hole of
>>> adding new TCG operations or even just having no well defined mappings
>>> between RVV and AVX, those might make the project really hard.
>>
>> You shouldn't have a hard guest-target mapping. But are you already
>> using the TCGVec types and they are not expanding to AVX when its
>> available?
>
> Ya, sorry, I guess that was an odd way to describe it.  IIUC we're
> doing sane stuff, it's just that RISC-V has a very different vector
> masking model than other ISAs.  I just said AVX there because I only
> care about the performance on Intel servers, since that's what I run
> QEMU on.  I'd asssume we have similar performance problems on other
> targets, I just haven't looked.
>
> So my worry would be that the RVV things we're doing slowly just don't
> have fast implementations via AVX and thus we run into some
> intractable problems.  That sort of stuff can be really frusturating
> for an intern, as everything's new to them so it can be hard to know
> when something's an optimization dead end.
>
> That said, we're seeing 100x slowdows in microbenchmarks and 10x
> slowdowns in real code, so I think there sholud be some way to do
> better.

It would be nice if you could convert that micro-benchmark to plain C
for a tcg/multiarch test case. It would be a useful tool for testing
changes.

>
>> Remember for anything float we will end up with softfloat anyway so we
>> can't use SIMD on the backend.
>
> Yep, but we have a handful of integer slowdowns too so I think there's
> some meat to chew on here.  The softfloat stuff should be equally slow
> for scalar/vector, so we shouldn't be tripping false positives there.
>
>>>> Do you have the time to profile and add specifics to the project idea
>>>> by Feb 21st? If that sounds good to you, I'll add it to the project
>>>> ideas list and you can add more detailed tasks in the coming weeks.
>>>
>>> I can at least dig up some of the examples I ran into, there's been a
>>> handful filtering in over the last year or so.
>>>
>>> This one
>>> <https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba>
>>> still has a much more than 10x slowdown (73ms -> 13s) with
>>> vectorization, for example.
>>>
>>>> Thanks,
>>>> Stefan
>>
>> -- Alex Bennée
>> Virtualisation Tech Lead @ Linaro

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Call for GSoC/Outreachy internship project ideas

[Palmer Dabbelt]

On Thu, 01 Feb 2024 10:57:00 PST (-0800), alex.bennee@linaro.org wrote:
> Palmer Dabbelt <palmer@dabbelt.com> writes:
>
>> On Thu, 01 Feb 2024 09:39:22 PST (-0800), alex.bennee@linaro.org wrote:
>>> Palmer Dabbelt <palmer@dabbelt.com> writes:
>>>
>>>> On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@gmail.com wrote:
>>>>> On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>>>>
>>>>>> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
>>>>>> > Dear QEMU and KVM communities,
>>>>>> > QEMU will apply for the Google Summer of Code and Outreachy internship
>>>>>> > programs again this year. Regular contributors can submit project
>>>>>> > ideas that they'd like to mentor by replying to this email before
>>>>>> > January 30th.
>>>>>>
>>>>>> It's the 30th, sorry if this is late but I just saw it today.  +Alistair
>>>>>> and Daniel, as I didn't sync up with anyone about this so not sure if
>>>>>> someone else is looking already (we're not internally).
>>> <snip>
>>>>> Hi Palmer,
>>>>> Performance optimization can be challenging for newcomers. I wouldn't
>>>>> recommend it for a GSoC project unless you have time to seed the
>>>>> project idea with specific optimizations to implement based on your
>>>>> experience and profiling. That way the intern has a solid starting
>>>>> point where they can have a few successes before venturing out to do
>>>>> their own performance analysis.
>>>>
>>>> Ya, I agree.  That's part of the reason why I wasn't sure if it's a
>>>> good idea.  At least for this one I think there should be some easy to
>>>> understand performance issue, as the loops that go very slowly consist
>>>> of a small number of instructions and go a lot slower.
>>>>
>>>> I'm actually more worried about this running into a rabbit hole of
>>>> adding new TCG operations or even just having no well defined mappings
>>>> between RVV and AVX, those might make the project really hard.
>>>
>>> You shouldn't have a hard guest-target mapping. But are you already
>>> using the TCGVec types and they are not expanding to AVX when its
>>> available?
>>
>> Ya, sorry, I guess that was an odd way to describe it.  IIUC we're
>> doing sane stuff, it's just that RISC-V has a very different vector
>> masking model than other ISAs.  I just said AVX there because I only
>> care about the performance on Intel servers, since that's what I run
>> QEMU on.  I'd asssume we have similar performance problems on other
>> targets, I just haven't looked.
>>
>> So my worry would be that the RVV things we're doing slowly just don't
>> have fast implementations via AVX and thus we run into some
>> intractable problems.  That sort of stuff can be really frusturating
>> for an intern, as everything's new to them so it can be hard to know
>> when something's an optimization dead end.
>>
>> That said, we're seeing 100x slowdows in microbenchmarks and 10x
>> slowdowns in real code, so I think there sholud be some way to do
>> better.
>
> It would be nice if you could convert that micro-benchmark to plain C
> for a tcg/multiarch test case. It would be a useful tool for testing
> changes.

Yep.  I actually gave it a shot before posting the C++ version and it 
seems kind of fragile, just poking it boring looknig ways changes the 
behavior.  Some of that was tied up in me trying to get GCC to generate 
similar code to clang, though, so hopefully that's all manageable.  I 
certainly wouldn't want to throw something that wacky at an intern for 
their first project, though.  So I don't have a good version yet.

I'm also hoping the fuzzer reproduces some nice small examples, but no 
luck yet...

>
>>
>>> Remember for anything float we will end up with softfloat anyway so we
>>> can't use SIMD on the backend.
>>
>> Yep, but we have a handful of integer slowdowns too so I think there's
>> some meat to chew on here.  The softfloat stuff should be equally slow
>> for scalar/vector, so we shouldn't be tripping false positives there.
>>
>>>>> Do you have the time to profile and add specifics to the project idea
>>>>> by Feb 21st? If that sounds good to you, I'll add it to the project
>>>>> ideas list and you can add more detailed tasks in the coming weeks.
>>>>
>>>> I can at least dig up some of the examples I ran into, there's been a
>>>> handful filtering in over the last year or so.
>>>>
>>>> This one
>>>> <https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba>
>>>> still has a much more than 10x slowdown (73ms -> 13s) with
>>>> vectorization, for example.
>>>>
>>>>> Thanks,
>>>>> Stefan
>>>
>>> -- Alex Bennée
>>> Virtualisation Tech Lead @ Linaro
>
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and
> might have some tricky parts.  That said it's tripping some people up
> and as far as I know nobody's started looking at it, so I figrued I'd
> write something up.

Hi Palmer,
Your idea has been added:
https://wiki.qemu.org/Google_Summer_of_Code_2024#RISC-V_Vector_TCG_Frontend_Optimization

I added links to the vector extension specification and the RISC-V TCG
frontend source code.

Please add concrete tasks (e.g. specific optimizations the intern
should implement and benchmark) by Feb 21st. Thank you!

Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Palmer Dabbelt]

On Wed, 31 Jan 2024 06:39:25 PST (-0800), stefanha@gmail.com wrote:
> On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
>> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and
>> might have some tricky parts.  That said it's tripping some people up
>> and as far as I know nobody's started looking at it, so I figrued I'd
>> write something up.
>
> Hi Palmer,
> Your idea has been added:
> https://wiki.qemu.org/Google_Summer_of_Code_2024#RISC-V_Vector_TCG_Frontend_Optimization
>
> I added links to the vector extension specification and the RISC-V TCG
> frontend source code.
>
> Please add concrete tasks (e.g. specific optimizations the intern
> should implement and benchmark) by Feb 21st. Thank you!

OK.  We've got a few examples starting to filter in, I'll keep updating 
the bug until we get some nice concrete reproducers for slowdows of 
decent vectorized code.  Then I'll take a look and what's inside them, 
with any luck it'll be simple to figure out which vector instructions 
are commonly used and slow -- there's a bunch of stuff in the RVV 
translation that doesn't map cleanly, so I'm guessing it'll be in there.

If that all goes smoothly then I think we should have a reasonably 
actionable intern project, but LMK if you were thinking of something 
else?

> Stefan

Re: Call for GSoC/Outreachy internship project ideas

[Stefan Hajnoczi]

On Wed, 31 Jan 2024 at 10:59, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Wed, 31 Jan 2024 06:39:25 PST (-0800), stefanha@gmail.com wrote:
> > On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@gmail.com wrote:
> >> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and
> >> might have some tricky parts.  That said it's tripping some people up
> >> and as far as I know nobody's started looking at it, so I figrued I'd
> >> write something up.
> >
> > Hi Palmer,
> > Your idea has been added:
> > https://wiki.qemu.org/Google_Summer_of_Code_2024#RISC-V_Vector_TCG_Frontend_Optimization
> >
> > I added links to the vector extension specification and the RISC-V TCG
> > frontend source code.
> >
> > Please add concrete tasks (e.g. specific optimizations the intern
> > should implement and benchmark) by Feb 21st. Thank you!
>
> OK.  We've got a few examples starting to filter in, I'll keep updating
> the bug until we get some nice concrete reproducers for slowdows of
> decent vectorized code.  Then I'll take a look and what's inside them,
> with any luck it'll be simple to figure out which vector instructions
> are commonly used and slow -- there's a bunch of stuff in the RVV
> translation that doesn't map cleanly, so I'm guessing it'll be in there.
>
> If that all goes smoothly then I think we should have a reasonably
> actionable intern project, but LMK if you were thinking of something
> else?

That's great!

Thanks,
Stefan