Re: [PATCH v2 3/6] virtio-msg: Add virtio-msg, a message based virtio transport layer

Michael Riesch <[email protected]> Wed, 8 Jul 2026 17:43:57 +0200
Newsgroups dev.linux.lists.virtio-comment
Message-ID <[email protected]>
Hi all,

Sorry for being late to the party. In January 2026 I received a very
warm welcome in the virtio-msg group meetings, which I subsequently
attended (or at least, I tried to do so). Now, in July 2026, I finally
get around to read the whole thing.

The reason for this may have been that "Things just worked (tm)". Basing
on Viresh's patches for virtio-msg in the Linux kernel and Mani's work
towards virtio-msg over PCIe (including glue code that ties virtio-msg
to the PCIe endpoint controller framework), we were able to build a
virtual GPU out of a off-the-shelf SBC. So no real reason for
intervention, right?!

That said, obviously we would like this to happen, and maybe saying out
loud that this is superb work and a highly valuable contribution to the
ecosystem helps.

On 6/15/26 11:10, Bertrand Marquis 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.
> 
> 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
> * vm to vm
> 
> Signed-off-by: Bertrand Marquis <[email protected]>
> Signed-off-by: Bill Mills <[email protected]>
> Signed-off-by: Edgar E. Iglesias <[email protected]>
> Signed-off-by: Arnaud Pouliquen <[email protected]>

This is superb work and a highly valuable contribution to the ecosystem.
Thanks a lot to all people involved in this!

Reviewed-by: Michael Riesch <[email protected]>

One thing, though:

> [...]
> +\subsubsection{Transport Feature Bits}
> +\label{sec:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Transport Feature Bits}
> +
> +Transport feature bits are bus-instance parameters. They are advertised as part
> +of the transport parameters described in
> +\ref{sec:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Revisions}
> +and are not carried in the device feature blocks exchanged by
> +\msgref{GET_DEVICE_FEATURES} and \msgref{SET_DRIVER_FEATURES}.
> +
> +The following transport feature bits are defined:
> +
> +\begin{tabular}{|l|l|l|p{7cm}|}
> +\hline
> +Bit & Name & Minimum revision & Meaning \\
> +\hline
> +0 & \texttt{VIRTIO\_MSG\_F\_STRICT\_CONFIG\_GENERATION} & 1 &
> +Select strict configuration semantics profile. When this feature is not
> +advertised for the bus instance, the baseline profile applies. See
> +\ref{sec:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Configuration Semantics Profiles}. \\
> +\hline
> +\end{tabular}

This table overruns the page width in my LaTeX build?!

> [...]

Best regards,
Michael