Re: [PATCH v1 2/4] virtio-msg: Add virtio-msg, a message based virtio transport layer

On Tue, Feb 24, 2026 at 10:41:59AM -0500, Demi Marie Obenour wrote:
> On 1/26/26 11:32, Bill Mills wrote:
> > Add a new transport layer that is based on messages.
> > 
> > This transport layer still uses virtqueues as the other transport layers do
> > but implements transport layer operations by sending and receiving messages
> > instead of the "MMR" reads and writes used in virtio-mmio and virtio-pci.
> > 
> > This transport is useful when the device and driver are both implemented in
> > software but the trap and emulate operations of virtio-mmio and virtio-pci
> > can not be used.
> 
> Is it possible to map a virtio-mmio or virtio-pci device to virtio-msg?
> For instance, can a VMM present a virtio-mmio or virtio-pci device
> to its VM, while using virtio-msg to communicate with its backend?

Hi Demi,

Yes, that is possible. One of the first implementations of virtio-msg
was using a generic proxy in QEMU that translated virtio-mmio and
virtio-pci to virtio-msg, at the time there was no virtio-msg Linux
driver so this served as a stepping stone. I haven't kept the proxy
up to date though.

https://github.com/edgarigl/qemu/blob/edgar/virtio-msg/hw/virtio/virtio-msg-proxy-driver.c


We also have a proxy for Xen that translates a slightly modified version
of virtio-mmio to virtio-msg.

https://github.com/Xilinx/xen/tree/xlnx_rebase_4.20/xen/common/virtio

Best regards,
Edgar

> 
> > This transport is intended to be used in many situations, including:
> > * between a host processor and its co-processors
> > * between two different systems (not SMP) connected via PCIe
> > * between normal and secure worlds
> > * host to vm
> 
> How does this map to the vhost-user protocol [1]?  Vhost-user is a very
> common way to implement devices and it would be nice for virtio-msg
> to cleanly map to it.  Requiring a separate AF_UNIX transport could
> be quite disruptive.
> 
> [1]: https://www.qemu.org/docs/master/interop/vhost-user.html
> 
> > * vm to vm
> 
> This requires a method for VMs to implement devices, not just drivers.
> For Xen and FF-A this is easy, provided that there is an out-of-band
> means to enumerate which devices should be implemented.  However,
> these mechanisms are not hypervisor-agnostic.
> 
> It would be much better to have a standard virtio device that backends
> could use to implement virtio-msg devices.  There have been multiple
> attempts at a virtio vhost-user device backend [2], but it was never
> widely deployed.
> 
> [2]: https://stefanha.github.io/virtio/vhost-user-slave.html
> 
> > Signed-off-by: Bill Mills <[email protected]>
> > Signed-off-by: Bertrand Marquis <[email protected]>
> > Signed-off-by: Edgar E. Iglesias <[email protected]>
> > Signed-off-by: Arnaud Pouliquen <[email protected]>
> > ---
> >  transport-msg.tex | 1640 +++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 1640 insertions(+)
> >  create mode 100644 transport-msg.tex
> > 
> > diff --git a/transport-msg.tex b/transport-msg.tex
> > new file mode 100644
> > index 0000000..d4e31d7
> > --- /dev/null
> > +++ b/transport-msg.tex
> > @@ -0,0 +1,1640 @@
> > +\section{Virtio Over Messages}\label{sec:Virtio Transport Options / Virtio Over Messages}
> > +
> > +\newcommand{\conceptref}[1]{\hyperref[sec:Virtio Transport Options / Virtio Over Messages / Basic Concepts / #1]{#1}}
> > +\newcommand{\msgref}[1]{\hyperref[sec:Virtio Transport Options / Virtio Over Messages / Transport Messages / VIRTIO_MSG_#1]{VIRTIO_MSG_#1}}
> > +\newcommand{\busref}[1]{\hyperref[sec:Virtio Transport Options / Virtio Over Messages / Bus Messages / BUS_MSG_#1]{BUS_MSG_#1}}
> > +\newcommand{\msgdef}[1]{\subsubsection{VIRTIO_MSG_#1}\label{sec:Virtio Transport Options / Virtio Over Messages / Transport Messages / VIRTIO_MSG_#1}}
> > +\newcommand{\busdef}[1]{\subsubsection{BUS_MSG_#1}\label{sec:Virtio Transport Options / Virtio Over Messages / Bus Messages / BUS_MSG_#1}}
> > +
> > +This section defines \textbf{virtio-msg}, a transport mechanism that encapsulates
> > +virtio operations as discrete message exchanges rather than relying on PCI or
> > +memory-mapped I/O regions. It separates bus-level functionality (e.g., device
> > +enumeration, hotplug events) from device-specific operations (e.g., feature
> > +negotiation, virtqueue setup), ensuring that a single, generic transport layer
> > +can be reused across multiple bus implementations.
> > +
> > +virtio-msg addresses several key objectives:
> > +
> > +\begin{itemize}
> > +  \item \textbf{Support multiple bus implementations:}
> > +  Systems can rely on various communication methods such as hypercalls, local
> > +  IPC, network channels, or device trees for enumerating devices. virtio-msg
> > +  defines a common transport interface suitable for any of these mechanisms.
> > +
> > +  \item \textbf{Reduce per-bus complexity:}
> > +  Buses can implement a fully message-based workflow (including optional
> > +  enumeration via \busref{GET_DEVICES} and hotplug via \busref{EVENT_DEVICE})
> > +  or they can discover and manage devices through
> > +  alternative means such as platform firmware data. In either case, they
> > +  forward transport messages to and from each device.
> > +
> > +  \item \textbf{Preserve virtio semantics:}
> > +  The transport leverages standard virtio concepts (features, configuration
> > +  space, virtqueues), so existing virtio drivers and device implementations can
> > +  integrate smoothly once a device is discovered and registered.
> > +\end{itemize}
> 
> I see that there is support for device enumeration by drivers.
> What about driver enumeration by devices?  An FF-A endpoint or Xen VM
> needs to know which devices it should implement.  In embedded systems,
> this can be obtained from the device tree or ACPI.  However, dynamic
> systems need to create and destroy devices at runtime.
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)