Re: Call for GSoC and Outreachy project ideas for summer 2022
On Wed, 16 Mar 2022 at 13:36, Alexander Graf 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
Hey Stefan! On 16.03.22 14:16, Stefan Hajnoczi wrote: On Mon, 14 Feb 2022 at 13:58, Stefan Hajnoczi wrote: On Wed, 9 Feb 2022 at 14:50, Alexander Graf 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-andra...@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
On Mon, 14 Feb 2022 at 13:58, Stefan Hajnoczi wrote: > > On Wed, 9 Feb 2022 at 14:50, Alexander Graf 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-andra...@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
On Wed, 23 Feb 2022 at 08:48, Andreea Florescu 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
On Tue, 22 Feb 2022 at 15:03, Keith Busch wrote: > > On Tue, Feb 22, 2022 at 09:48:06AM +, Stefan Hajnoczi wrote: > > On Mon, 21 Feb 2022 at 12:00, Klaus Jensen 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
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: - fand...@amazon.com - gsse...@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
On Tue, Feb 22, 2022 at 09:48:06AM +, Stefan Hajnoczi wrote: > On Mon, 21 Feb 2022 at 12:00, Klaus Jensen 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-m...@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
On Mon, 21 Feb 2022 at 12:00, Klaus Jensen wrote: > > On Feb 21 09:51, Stefan Hajnoczi wrote: > > On Mon, 21 Feb 2022 at 06:14, Klaus Jensen 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
Re: Call for GSoC and Outreachy project ideas for summer 2022
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
On Feb 21 09:51, Stefan Hajnoczi wrote: > On Mon, 21 Feb 2022 at 06:14, Klaus Jensen 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 perf
Re: Call for GSoC and Outreachy project ideas for summer 2022
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
On Fri, 18 Feb 2022 at 21:05, Alexander Bulekov 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
On Mon, 21 Feb 2022 at 06:14, Klaus Jensen 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
On 2/19/22 14:46, Stefan Hajnoczi wrote: > On Fri, 18 Feb 2022 at 16:03, Paolo Bonzini 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.ka...@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
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 signature.asc Description: PGP signature
Re: Call for GSoC and Outreachy project ideas for summer 2022
On Thu, 17 Feb 2022 at 18:24, Thomas Huth 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 (th...@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
On Fri, 18 Feb 2022 at 16:03, Paolo Bonzini 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.ka...@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
On Fri, 18 Feb 2022 at 11:40, Michal Prívozník 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.ka...@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
On Thu, 17 Feb 2022 at 17:49, Paolo Bonzini 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
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
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.ka...@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
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.ka...@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
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 (th...@redhat.com) (+1 TBD) What do you think about that idea? Thanks, Thomas
Re: Call for GSoC and Outreachy project ideas for summer 2022
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
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.ka...@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
On Thu, 17 Feb 2022 at 14:12, Stefano Garzarella wrote: > > On Mon, Feb 14, 2022 at 02:01:52PM +, Stefan Hajnoczi wrote: > >On Mon, 14 Feb 2022 at 07:11, Jason Wang wrote: > >> > >> On Fri, Jan 28, 2022 at 11:47 PM 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! > >> > >> 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
On Thu, 17 Feb 2022 at 07:08, Alice Frosi wrote: > > On Fri, Jan 28, 2022 at 6:04 PM 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'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
On Mon, Feb 14, 2022 at 02:01:52PM +, Stefan Hajnoczi wrote: On Mon, 14 Feb 2022 at 07:11, Jason Wang wrote: On Fri, Jan 28, 2022 at 11:47 PM 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! 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.maxim...@samsung.com/ Incomplete implementation proposed for QEMU] '''Details:''' * Skill level: intermediate * Language: C * Mentor: Stefano Garzarella ** IRC/Matrix nick: sgarzare (OFTC/matrix.org) * Suggested by: Jason Wang
Re: Call for GSoC and Outreachy project ideas for summer 2022
On Fri, Jan 28, 2022 at 6:04 PM 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'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
On Mon, Feb 14, 2022 at 10:02 PM Stefan Hajnoczi wrote: > > On Mon, 14 Feb 2022 at 07:11, Jason Wang wrote: > > > > On Fri, Jan 28, 2022 at 11:47 PM 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! > > > > 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
On Mon, Feb 14, 2022 at 7:48 PM Stefano Garzarella 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 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
On Mon, 14 Feb 2022 at 13:42, Alex Bennée wrote: > > > Stefan Hajnoczi 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
On Wed, 9 Feb 2022 at 14:50, Alexander Graf 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-andra...@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
On Mon, 14 Feb 2022 at 07:11, Jason Wang wrote: > > On Fri, Jan 28, 2022 at 11:47 PM 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! > > 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 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
On Mon, Feb 14, 2022 at 03:11:20PM +0800, Jason Wang wrote: On Fri, Jan 28, 2022 at 11:47 PM 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! 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
On Fri, Jan 28, 2022 at 11:47 PM 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! 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
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-andra...@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
