From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel <qemu-devel@nongnu.org>,
virtio-comment@lists.linux.dev, dev@lists.cloudhypervisor.org,
rust-vmm@lists.opendev.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Stefano Garzarella <sgarzare@redhat.com>,
Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
Demi Marie Obenour <demi@invisiblethingslab.com>,
Alyssa Ross <hi@alyssa.is>, Albert Esteve <aesteve@redhat.com>,
Mark Burton <MBURTON@QTI.QUALCOMM.COM>,
Matti Moell <matti@qti.qualcomm.com>,
Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Dorinda Bassey <dbassey@redhat.com>,
Sergio Lopez <slp@redhat.com>,
Vishwanath Seshagiri <vishs@meta.com>,
Rob Bradford <rbradford@meta.com>,
Zhengyu Zhao <zhaozhengyu@bytedance.com>,
Jorge E. Moreira <jemoreira@google.com>
Subject: Where should the vhost-user specification live?
Date: Wed, 27 May 2026 10:13:47 +0100 [thread overview]
Message-ID: <874ijtz038.fsf@draig.linaro.org> (raw)
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
next reply other threads:[~2026-05-27 9:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 9:13 Alex Bennée [this message]
2026-05-27 12:55 ` Where should the vhost-user specification live? Michael S. Tsirkin
2026-05-27 13:58 ` Alex Bennée
2026-06-01 12:32 ` Albert Esteve
2026-06-01 12:39 ` Michael S. Tsirkin
2026-06-01 13:05 ` Albert Esteve
2026-06-01 13:11 ` Michael S. Tsirkin
2026-06-01 13:51 ` Stefan Hajnoczi
2026-06-01 14:22 ` Michael S. Tsirkin
2026-06-01 16:58 ` Stefan Hajnoczi
2026-06-01 14:27 ` Albert Esteve
2026-06-01 14:37 ` Michael S. Tsirkin
2026-06-01 15:18 ` Stefan Hajnoczi
2026-06-01 20:04 ` Michael S. Tsirkin
2026-06-02 10:38 ` Dorinda Bassey
2026-06-04 16:28 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874ijtz038.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=MBURTON@QTI.QUALCOMM.COM \
--cc=aesteve@redhat.com \
--cc=dbassey@redhat.com \
--cc=demi@invisiblethingslab.com \
--cc=dev@lists.cloudhypervisor.org \
--cc=hi@alyssa.is \
--cc=jemoreira@google.com \
--cc=manos.pitsidianakis@linaro.org \
--cc=matti@qti.qualcomm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rbradford@meta.com \
--cc=rust-vmm@lists.opendev.org \
--cc=sgarzare@redhat.com \
--cc=slp@redhat.com \
--cc=stefanha@redhat.com \
--cc=viresh.kumar@linaro.org \
--cc=virtio-comment@lists.linux.dev \
--cc=vishs@meta.com \
--cc=zhaozhengyu@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.