$Stefan Hajnoczi <[email protected]> writes: > On Wed, Jun 10, 2026 at 09:37:10AM +0100, Daniel P. Berrangé 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 PM Peter Maydell <[email protected]> >> > > wrote: >> > > > >> > > > On Tue, 9 Jun 2026 at 19:00, Stefan Hajnoczi <[email protected]> >> > > > wrote: >> > > > > I'm not sure if anyone brought up this topic on qemu-devel and with >> > > > > Michael before. As I mentioned in my reply, there are ways to avoid >> > > > > blocking vhost-user spec changes when qemu.git is frozen: >> > > > > >> > > > > The simplest approach is to keep merging vhost-user.rst changes >> > > > > during >> > > > > freeze since it does not jeopardize the release or introduce >> > > > > instability. >> >> snip >> >> > 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. >> >> Yes, the main impression I get having read through this whole thread >> is that vhost-user spec should have its own home outside QEMU. >> >> 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. >> >> 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. >> >> >> 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. >> >> 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.
While I agree getting it into OASIS it's a lot of work and not something particularly enticing, I also feel obligated to point that, in my experience, vhost-user is not seen as an standard to be follow to the same degree VIRTIO is across the industry. If there's a lightweight mechanism for getting it included (as Michael hinted there could be), getting vhost-user into VIRTIO could be useful to strengthen and solidify it as an industry-wide specification. Thanks, Sergio.
