Hi Alex, On Wed, May 27, 2026 at 11:13 AM Alex Bennée <[email protected]> wrote: > > > Hi, > > Apologies for the wide cross-posting but I wanted to find as many > interested parties as possible. > > The vhost-user specification currently lives in the main qemu > repository (docs/interop/vhost-user.rst) mainly due to historical > reasons. QEMU was one of the first VMMs to implement vhost-user and the > spec needed to live somewhere. > > However there are now vhost-user implementations for QEMU, rust-vmm, > cloud hypervisor and I think CrosVM. We get queries about changing or > updating the spec on qemu-devel from time to time and I feel that given > it is an interoperability specification we should think about hosting > it and its discussions elsewhere.
We recently discussed this with Dorinda and Stefano. I do see value in moving it elsewhere. Mainly to remove the friction of external communities navigating QEMU-specific tooling and workflows just to propose protocol updates. But also because, in my opinion, separating the specification would improve development agility by decoupling specification development from QEMU's review and release cycles. At least it is worth the discussion. Thanks for raising. > > I think broadly there are 4 options: > > * Move into the OASIS VirtIO group as an appendix/addendum to the main > VirtIO spec. > > This probably brings the widest visibility to changes to those that > might be affected. However it does come with a certain amount of > bureaucracy with the OASIS process where only members can vote on > changes. While intimately tied to VirtIO it's concerns are more > focused on practical implementation details of the IPC between VMMs > and device backends. While it does make sense for VirtIO, I'm wary of the added bureaucracy that OASIS would introduce for vhost-user. The scope for vhost-user is also much smaller, focusing more on the transport protocol as you pointed out, so I do not see the need to subject ourselves to that process. > > * Move to a separate project under the qemu-project space. > > QEMU hosts a number of sub-projects and mirrors so it would be easy > enough to split the spec into its own repo. Changes to the > specification could then be divorced from QEMU's release cycle and > at the maintainers option issues and merging strategies could be > configured for just the specification. > > * Create a new project just for vhost-user > > The interested parties could decide where to host (github, gitlab, > forgejo, whatever..) and decide to move away from mailing lists > altogether or create a mailing list but manage changes via the forge > interface. > > * Status quo > > Just keep the spec where it is and muddle through as before. Maybe > we could improve the contribution documentation for how and when > changes are discussed. > > Any thoughts? Another option could be rust-vmm. It is a project shared by multiple stakeholders. And while it is Rust-focused, its community heavily overlaps with the exact ecosystems driving modern vhost-user development. BR, Albert > > -- > Alex Bennée > Virtualisation Tech Lead @ Linaro >
