Speaker
Description
eBPF programs can exchange data efficiently with other programs and userspace through maps, ring buffers, and kfuncs, but these mechanisms stop at the boundary of a kernel instance. The Linux kernel has no generic, safe, low-latency mechanism for eBPF programs in a guest and host to communicate through shared memory across the VM boundary. Roy’s Google Summer of Code (GSoC) project [1] reimplements Himadri’s in-kernel thesis [2] prototype of Phantom Tracker using eBPF and, in turn, highlights the need for paravirtualized shared-memory drivers that expose reliable communication APIs to eBPF programs across the VM boundary.
The thesis models vCPU lifecycle states using the distinction between phantom and viable vCPUs. A phantom vCPU satisfies two conditions: (1) it is runnable but waiting in the run queue of a pCPU on the host, and (2) a worker thread of the guest parallel application that had been running on that vCPU is now stalled because the vCPU is not executing. Conversely, any vCPU that does not satisfy both conditions is considered viable. Across the VM boundary, Phantom Tracker correlates guest-side information about which vCPUs are running worker threads of the parallel application with host-side scheduler wake-up and context-switch events involving those vCPUs. The GSoC project uses a configurable eBPF timer that aggregates these observations and computes a per-VM metric called the phantom average. Guest userspace parallel runtime libraries, such as libgomp, can use this metric to adapt the application’s degree of parallelism at runtime and minimize the number of phantom vCPUs.
Communication between the host and guest is implemented using QEMU’s Inter-VM Shared Memory (IVSHMEM) device [3]. While the thesis prototype relied on custom IVSHMEM drivers tied to custom kernels, the eBPF implementation resulted in the development of new eBPF-compatible drivers [4]. By presenting the lessons learned while working on this GSoC project, this talk discusses the broader applicability of our eBPF-compatible IVSHMEM drivers within the QEMU/KVM virtualization stack and invites discussion on the scope for upstreaming them.
[1] https://summerofcode.withgoogle.com/programs/2026/projects/iXbp42du
[2] https://inria.hal.science/tel-05438117v3
[3] https://www.qemu.org/docs/master/system/devices/ivshmem.html
[4] https://github.com/himadrics/phantom-tracker/tree/main/pvsched-shmem