Internships/ProjectIdeas/IORegionFD: Difference between revisions

Latest revision as of 12:56, 13 September 2020

ioregionfd - new device access dispatch mechanism

Summary: Implement a mechanism in the Linux kvm.ko kernel module to dispatch device accesses directly to a process or thread without jumping through the QEMU vCPU thread.

Virtual devices such as graphics cards and network cards can be emulated in dedicated tasks (processes or threads) instead of running in QEMU's vCPU or main loop threads. Dedicated tasks have security and performance advantages because they are isolated and can run on dedicated physical CPUs.

Some devices cannot be emulated efficiently yet because there is no way for the Linux kvm.ko kernel module to dispatch device accesses directly to the device emulation task. Today it is necessary to jump through the QEMU vCPU thread first and then forward the access to the dedicated task, which is slow. A few existing devices use the ioeventfd mechanism to avoid this but it only works for "doorbell" writes, not for read accesses or non-doorbell writes. This project is about implementing a general solution called ioregionfd.

Here is how read accesses and non-doorbell writes are dispatched today:

kvm.ko  <---ioctl(KVM_RUN)---> QEMU <---messages---> device task

ioregionfd eliminates the extra step through QEMU like this:

kvm.ko  <---ioregionfd---> device task

This project consists of implementing the KVM_SET_IOREGIONFD ioctl in the Linux kvm.ko kernel module and writing test cases. As a stretch goal you could update QEMU's emulated NVMe device to run in a dedicated QEMU IOThread using ioregionfd.

Please take a look at the ioregionfd API design discussion link below to understand the new ioctl proposal.

This project idea is suitable if you would like to gain Linux kernel programming and virtualization/emulation experience. No prior kernel programming experience is required but you must be able to write production-quality C (understand pointers, dynamic memory allocation, and error-handling in C).

Links:

Details:

Skill level: advanced
Language: C
Mentor: Stefan Hajnoczi <stefanha@redhat.com>

@@ Line 1: / Line 1: @@
 === ioregionfd - new device access dispatch mechanism ===
-'''Summary:''' Implement the ioregionfd device access dispatch mechanism in the Linux kvm.ko kernel module so that device emulation processes or threads can handle device accesses without jumping through the QEMU vCPU thread.
+'''Summary:''' Implement a mechanism in the Linux kvm.ko kernel module to dispatch device accesses directly to a process or thread without jumping through the QEMU vCPU thread.
-Virtual devices including graphics cards, network cards, storage controllers, and more can be emulated in dedicated tasks (processes or threads) instead of running in QEMU's vCPU or main loop threads. Dedicated tasks can have security and performance advantages over handling device emulation in QEMU's normal threads.
+Virtual devices such as graphics cards and network cards can be emulated in dedicated tasks (processes or threads) instead of running in QEMU's vCPU or main loop threads. Dedicated tasks have security and performance advantages because they are isolated and can run on dedicated physical CPUs.
-However, certain devices cannot be emulated efficiently in a dedicated task yet because there is no way for the Linux kvm.ko kernel module to dispatch device accesses from the guest directly to the device emulation task. Today it is necessary to jump through the QEMU vCPU thread first and then forward the access to the dedicated task, which is slow. A few existing devices use the ioeventfd mechanism to avoid the performance overhead of jumping through QEMU's vCPU thread but it only works for "doorbell" writes, not for read accesses or non-doorbell writes.
+Some devices cannot be emulated efficiently yet because there is no way for the Linux kvm.ko kernel module to dispatch device accesses directly to the device emulation task. Today it is necessary to jump through the QEMU vCPU thread first and then forward the access to the dedicated task, which is slow. A few existing devices use the ioeventfd mechanism to avoid this but it only works for "doorbell" writes, not for read accesses or non-doorbell writes. This project is about implementing a general solution called ioregionfd.
-Here is how read accesses and non-doorbell writes need to be dispatched today:
+Here is how read accesses and non-doorbell writes are dispatched today:
   kvm.ko  <---ioctl(KVM_RUN)---> QEMU <---messages---> device task
-ioregionfd has been proposed as a solution that lets kvm.ko dispatch device accesses directly to device emulation tasks. It eliminates the extra step through QEMU and looks like this:
+ioregionfd eliminates the extra step through QEMU like this:
   kvm.ko  <---ioregionfd---> device task
-This project consists of implementing the KVM_SET_IOREGIONFD ioctl in the Linux kvm.ko kernel module and writing test cases that exercise the kvm.ko. As a stretch goal you could use ioregionfd in QEMU's NVMe device emulation code so that it can run in a dedicated QEMU IOThread.
+This project consists of implementing the KVM_SET_IOREGIONFD ioctl in the Linux kvm.ko kernel module and writing test cases. As a stretch goal you could update QEMU's emulated NVMe device to run in a dedicated QEMU IOThread using ioregionfd.
-This project idea is suitable if you would like to gain Linux kernel programming and virtualization/emulation experience. No prior kernel programming experience is required but you must be fluent in C and able to write production-quality code.
+Please take a look at the ioregionfd API design discussion link below to understand the new ioctl proposal.
+This project idea is suitable if you would like to gain Linux kernel programming and virtualization/emulation experience. No prior kernel programming experience is required but you must be able to write production-quality C (understand pointers, dynamic memory allocation, and error-handling in C).
 '''Links:'''