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

Hi Demi,

> On 24 Feb 2026, at 16:41, Demi Marie Obenour <[email protected]> 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?

I am not sure to understand what you mean here.

Right now a VMM would present a virtio device which will behave
the same on mmio, pci or virtio-msg.
In our transport implementation in Linux, we did not change anything
in the virtio drivers.

So the transport used is transparent even to the virtio driver on top.

>
>> 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

This is something i will need to look at to provide an answer but
vsock works for sure so this should to but I will have to confirm.

>
>> * 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.

For FF-A the way to enumerate devices is hypervisor agnostic as we have
extra messages in the bus to do so.

I started to research how to do a xen implementation (using only grant tables
and xen events) which will use a FIFO in one or two pages shared using
grant tables to transfer the messages and enumeration should work the
same way as with FF-A.

>
> 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.

What I am looking at right now is the following in linux:
- virtio-msg bus backend implemented in the kernel with a standard
virtio-msg bus interface to user
- virtio-msg transport backend implemented in Qemu (or any other VMM)
communicating with bus using a kernel interface

This makes Qemu bus agnostic and allows to have more implementations
of different busses using kernel drivers without changing Qemu.

Having something of a vhost-user backend seems feasible but would need
some work definitely.

>
> [2]: https://uk01.z.antigena.com/l/RPtFHkpliiy7NRgNtyaO30yBQpiAnIuLVyzAK2QZ0fGEIjSJVGx5Mu3MwXXt-LgQn2ZVpDwK1wfUHdgKxzrauRK4sFfiVoW3xPL5PablM52jV-ngF4DwusMzPUNSF6WQ1Ec3WMxworPUgzNgc1gDTMsD1H17lnI6v1cOcD1m5vAuK4eS7Ma8l5f5HhciCHG0H4ibv8wtWquW2fvs6m
>
>> 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.

For now on this would work as it works right now for xen pv devices or virtio devices,
you will start a qemu telling it which devices to create and those will be detected using
the normal device enumeration message (or hotplugged if created after boot). This is
why we add the message to signal that a device was added or removed.

Cheers
Bertrand

> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> <OpenPGP_0xB288B55FFF9C22C1.asc>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.