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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 5160 bytes --]

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?

> 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 <bill.mills@linaro.org>
> Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> ---
>  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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]