libvfio-user

VMMs like QEMU run the entire emulation inside a single process. That works fine until you want an implementation that doesn't align with QEMU's runtime environment, such as SPDK to handle multiple VMs' virtual disks and multiple physical disks from a single process. For this, we've built vfio-user, a protocol modelled after the kernel's VFIO framework that lets device emulation run in a separate process. In vfio-user, there's the vfio-user client, which runs in the VMM, and the vfio-user server, which is the separate process where the device emulation runs. We also built libvfio-user, the vfio-user server-side library, which facilitates implementing a PCI device in C or Python (Rust should be possible as well). This makes it easy to quickly prototype devices without modifying QEMU and to reuse the same device implementation across multip

Cool. I've actually been playing with QEMU internals a lot recently. Specifically with the multi-process experimental features. Although I can't seem to find any consistency on where the main project is headed. They admit that the documentation pages can be well out-of-date with the upstream implementations, but they seem split-brained even within the code. The main project ships with the multi-process qemu approach, mostly defined in their docs: https://www.qemu.org/docs/master/system/multi-process.html https://www.qemu.org/docs/master/devel/multi-process.html But I saw some update buried in a mailing list that development of the multi-process system has been superseded by vfio-user, mostly led by nutanix: https://github.com/nutanix/libvfio-user The nutanix repo refers to an oracle-led fork of qemu with the full vfio-user implementation