Re: Where should the vhost-user specification live?

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 27, 2026 at 10:13:47AM +0100, Alex Bennée 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.
> 
> 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.
> 
>   * 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?
> 
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

I think what is missing here is what are the pros for any of the
proposed changed?  What are the issues we are trying to solve?
What 'queries about changing or updating the spec' were problematic?

Thanks,

-- 
MST