Re: Where should the vhost-user specification live?

--qvfpYexFwf7TVkyW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 10, 2026 at 09:37:10AM +0100, Daniel P. Berrang=C3=A9 wrote:
> On Tue, Jun 09, 2026 at 08:51:15PM +0100, Peter Maydell wrote:
> > On Tue, 9 Jun 2026 at 20:45, Stefan Hajnoczi <[email protected]> wrote:
> > >
> > > On Tue, Jun 9, 2026 at 2:51=E2=80=AFPM Peter Maydell <peter.maydell@l=
inaro.org> wrote:
> > > >
> > > > On Tue, 9 Jun 2026 at 19:00, Stefan Hajnoczi <[email protected]> w=
rote:
> > > > > I'm not sure if anyone brought up this topic on qemu-devel and wi=
th
> > > > > Michael before. As I mentioned in my reply, there are ways to avo=
id
> > > > > blocking vhost-user spec changes when qemu.git is frozen:
> > > > >
> > > > > The simplest approach is to keep merging vhost-user.rst changes d=
uring
> > > > > freeze since it does not jeopardize the release or introduce
> > > > > instability.
>=20
> snip
>=20
> > I tend to view the specs subsection of the docs as being
> > for things where either QEMU really is the authoritative
> > source (eg fw_cfg), or where the spec is for something that's
> > basically moribund and has no better home. If vhost-user is
> > a cross-project specification that it so active that it
> > cannot live within QEMU's release process, then I think
> > it deserves to have its own independent home.
>=20
> Yes, the main impression I get having read through this whole thread
> is that vhost-user spec should have its own home outside QEMU.
>=20
> We can come up with all sorts of rationalizations for how to make
> things work in the context of QEMU, but they all just come across
> as excuses to avoid changing the fairly arbitrary historical use
> of qemu.git. Even if as QEMU maintainers we consider that we're a
> "neutral" home, I can understand why it might not be perceived that
> way from the outside.
>=20
> If people want agility such that we need to make exceptions for
> our rules during freeze that is one flag that it doesn't belong
> with the main qemu.git, but there are broader points that are
> pushing my view in that direction too.
>=20
>=20
> Not mentioned is that engaging with the QEMU mailing list as a
> non-regular QEMU contributor is not a very attractive task.
> While QEMU may be satisfied with email, QEMU are in a tiny
> minority these days. The rest of the OSS community has
> decided that git forges are the better way to collaborate.
>=20
> Our dev list is very high volume, with changes very easily (and
> often) lost in the noise, even from regular contributors, such
> that we have to teach people to (repeatedly) "ping" to attract
> attention.

A separate repo in a git forge definitely has the advantage of making
communication easier to follow for anyone interested only in the
vhost-user protocol.

> If we want agility though, IMHO it is best to stay away from the
> bureucracy of the OASIS virtio spec / committee, which is a big
> turn off IME.

Yes, OASIS adds overhead.

The downside is that vhost-user suffers from being outside the VIRTIO
spec umbrella. It's really a VIRTIO Transport and would benefit from the
discipline of actually being part of the spec as such. At the moment
vhost-user is not really bound to VIRTIO through any interface (i.e.
VIRTIO Transport) or device lifecycle that is guaranteed to align with
the VIRTIO spec. This has led to both design problems and bugs that
would be prevented by making it a VIRTIO Transport.

In addition to the OASIS overhead you mentioned, the other issue is that
moving vhost-user into the VIRTIO spec would require reconciling the
the vhost-user protocol with the VIRITO Transport's interface and also
rewriting parts of the vhost-user spec that are not up to the level
(e.g. adding conformance clauses, eliminating some informal language,
etc).

In other words, it's a bunch of work. Although from a purist perspective
I think it's the right place for vhost-user, I think it would be an
unpopular solution.

> If we're considering a move of the spec, we should probably consider
> the best home for some of the related code parts too:
>=20
>   subprojects/libvhost-user/
>   contrib/vhost-user-blk/
>   contrib/vhost-user-bridge/
>   contrib/vhost-user-gpu/
>   contrib/vhost-user-input/
>   contrib/vhost-user-scsi/
>=20
> IIUC, the subprojects is fully standalone code with no dependency
> on QEMU. It remained within QEMU for "convenience" allowing us to
> consume them from the impls under contrib/. While the contrib code
> has some depedencies on QEMU, overall they appear pretty light and
> so likely easily detached
>=20
>   $ git grep '#include "' vhost-user-* | awk '{print $2}' | sort | uniq
>   "hw/virtio/virtio-gpu-bswap.h"
>   "hw/virtio/virtio-gpu-pixman.h"
>   "libvhost-user-glib.h"
>   "libvhost-user.h"
>   "qapi/error.h"
>   "qemu/atomic.h"
>   "qemu/bswap.h"
>   "qemu/ctype.h"
>   "qemu/drm.h"
>   "qemu/iov.h"
>   "qemu/osdep.h"
>   "qemu/queue.h"
>   "qemu/sockets.h"
>   "standard-headers/linux/input.h"
>   "standard-headers/linux/virtio_blk.h"
>   "standard-headers/linux/virtio_gpu.h"
>   "standard-headers/linux/virtio_input.h"
>   "standard-headers/linux/virtio_net.h"
>   "standard-headers/linux/virtio_scsi.h"
>   "virgl.h"
>   "vugbm.h"
>   "vugpu.h"
>=20
>=20
> We have a often repeated desire to eliminate the "contrib" tree
> as a concept, since it is currently effectively a "dumping ground"
> for things which are either unmaintained or didn't have a better
> home yet. This might be a chance to provide a better home for a
> big part of it.
>=20
> IMHO this suggests it is worth creating a new top level gitlab project
> for it all to live in and form a dedicated team around it, rather than
> trying to pick any existing location.

Some vhost-user back-ends in the contrib/ directory are used by QEMU's
test suite. An alternative way of integrating them into the tests could
be found, but I wanted to mention that dependency.

Stefan

--qvfpYexFwf7TVkyW
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmorHPMACgkQnKSrs4Gr
c8ioTgf9HCe8SudpuvZI/ECQCsZCNqoDK8UcuO3QE0Eglajbskm9qx76JdaY+ujM
nKqtUJiUTPxzbSbFwUaatttGlc48BkJXlPQEZoXcf7mqp38EUROnQASMW+rN3Afk
cK3zKkORSj1sdIO2ewqvO/o3iPYFzzC4JvkJb9HtDs9rQyZdbVdUxtHLmiWuwttu
zCRW1Ri12nT/Dd+zX8x2D0KwV8Tjg6NaESK0TiFEalppjju0n0tFmD3u2nJPdAi0
doXCCWaaXXmC6K8iqgBGnZTMtGcj3ZKCx3hGg1sJvHKNn/AIwBdlGWazyDwTWKqx
hnxDScpm5GmHUHoAKemBRuakaUpHtA==
=mSHC
-----END PGP SIGNATURE-----

--qvfpYexFwf7TVkyW--