Re: [PATCH v1 0/4] virtio-msg transport layer

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 03, 2026 at 08:48:00PM +0100, Edgar E. Iglesias wrote:
> On Tue, Feb 03, 2026 at 08:21:01AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Jan 26, 2026 at 11:32:26AM -0500, Bill Mills wrote:
> > > This series adds the virtio-msg transport layer.
> > > 
> > > The individuals and organizations involved in this effort have had difficulty in
> > > using the existing virtio-transports in various situations and desire to add one
> > > more transport that performs its transport layer operations by sending and
> > > receiving messages.
> > 
> > Is it arm and linaro, or more?
> > If more, could we get some acks on list from the people involved?
> > 
> >
> 
> AMD is also involved, I've acked patches 1, 3, and 4 (patch 2 has my Signed-off-by).
> 
> Cheers,
> Edgar
> 

Thank you

> 
> > > Implementations of virtio-msg will normally be done in multiple layers:
> > > * common / device level
> > > * bus level
> > > 
> > > The common / device level defines the messages exchanged between the driver
> > > and a device. This common part should lead to a common driver holding most
> > > of the virtio specifics and can be shared by all virtio-msg bus implementations.
> > > The kernel implementation in [3] shows this separation. As with other transport
> > > layers, virtio-msg should not require modifications to existing virtio device
> > > implementations (virtio-net, virtio-blk etc). The common / device level is the
> > > main focus of this version of the patch series.
> > > 
> > > The virtio-msg bus level implements the normal things a bus defines
> > > (enumeration, dma operations, etc) but also implements the message send and
> > > receive operations. A number of bus implementations are envisioned,
> > > some of which will be reusable and general purpose. Other bus implementations
> > > might be unique to a given situation, for example only used by a PCIe card
> > > and its driver.
> > > 
> > > The standard bus messages are an effort to avoid different bus implementations
> > > doing the same thing in different ways for no good reason. However the
> > > different environments will require different things. Instead of trying to
> > > anticipate all needs and provide something very abstract, we think
> > > implementation specific messages will be needed at the bus level. Over time,
> > > if we see similar messages across multiple bus implementations, we will move to
> > > standardize a bus level message for that.
> > > 
> > > We are working on a few reusable bus implementations:
> > > 
> > > * virtio-msg-ffa based on Arm FF-A interface for use between:
> > >   * normal world and secure world
> > >   * host and VM or VM to VM
> > >   * Can be used w/ or with out a hypervisor
> > >   * Any Hypervisor that implements FF-A can be used
> > >   * We have this working with pKVM and Xen
> > >   * We have this working with Trusty and OP-TEE
> > > 
> > > * virtio-msg-amp for use between heterogenous systems
> > >   * The main processors and its co-processors on an AMP SOC
> > >   * Two or more systems connected via PCIe
> > >   * Minimal requirements: bi-directional interrupts and
> > >     at least one shared memory area
> > >   * hvac-demo has 2 demos of this
> > >   * This is working on two hardware platforms
> > > 
> > > * virtio-msg-loopback for userspace implemented devices
> > >   * Allows user space to provide devices to its own kernel
> > >   * This is similar to fuse, cuse or loopback block devices but for virtio
> > >   * hvac-demo has a demo
> > > 
> > > We also anticipate a few more:
> > > 
> > > * virtio-msg-xen specific to Xen
> > >   * Usable on any Xen system (including x86 where FF-A does not exist)
> > >   * Using Xen events and page grants
> > > 
> > > * virtio-msg over admin virtqueues
> > >   * This allows any virtio-pci device that supports admin virtqueues to also
> > >     support a virtio-msg bus that supports sub devices
> > >   * [We are looking for collaborators for this work]
> > > 
> > > Changes since RFC2:
> > > 
> > > Spec Functional:
> > > * Made the common message header 8 bytes and added a token for optional use
> > >   when parallel outstanding requests are possible
> > > * Made the 8 byte fields align to 8 byte offsets.
> > >   This effects the {SET,GET}_VQUEUE messages
> > > * Many conformance cases have been tightened.
> > > 
> > > Spec Editorial:
> > > * Major restructure to better align with virtio spec
> > >   * Conformance model now matches other transports
> > >   * Use C structures to define messages instead of tables
> > > * Added a section to describe how responses are matched to requests
> > >   This includes the use of the new token field
> > > * Redefined / better described error handling between transport and bus
> > >   layers to eliminate the need for the bus to generate fake response messages
> > > * Included editorial feedback from RFC2
> > > 
> > > Eco-system:
> > > * Added virtio-msg-loopback demo
> > > * Arm has published the first draft of the virtio-msg over FFA spec [6]
> > > * virtio-msg over FFA has been demonstrated with both Trusty and OP-TEE
> > >   secure world
> > > * LKML RFC has been sent [7]
> > > * QEMU RFC has been sent [8]
> > > 
> > > This is the first non-RFC patch series. The known short comings have been
> > > addressed. We ask for review in earnest on this series and thank you for
> > > any feedback you can provide.
> > > 
> > > Background info and work in progress implementations:
> > > * HVAC project page with intro slides [1]
> > > * HVAC demo repo w/ instructions in README.md [2]
> > > * Kernel w/ virtio-msg common level and ffa support [3]
> > > * QEMU w/ support for one form of virtio-msg-amp [4]
> > > * Portable RTOS library w/ one form of virtio-msg-amp [5]
> > > 
> > > In addition to the QEMU system based demos in the hvac-demo repo, we also have
> > > two hardware systems running:
> > > * AMD x86 + AMD Arm Versal connected via PCIe
> > > * ST STM32MP157 A7 Linux using virtio-i2c provided by M4 Zephyr
> > > 
> > > Please note that although the demos work, a few have not been aligned
> > > with this version of the spec.
> > > 
> > > [1] https://linaro.atlassian.net/wiki/spaces/HVAC/overview
> > > [2] https://github.com/wmamills/hvac-demo
> > > [3] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=virtio/msg
> > > [4] https://github.com/edgarigl/qemu/commits/edgar/virtio-msg-rfc/
> > > [5] https://github.com/arnopo/open-amp/commits/virtio-msg/
> > > [6] https://documentation-service.arm.com/static/68f647791134f773ab3f0a7c
> > > [7] https://lore.kernel.org/all/cover.1753865268.git.viresh.kumar@linaro.org/
> > > [8] https://mail.gnu.org/archive/html/qemu-devel/2025-10/msg07438.html
> > > 
> > > Bertrand Marquis (2):
> > >   virtio-msg: add new command for bus normative
> > >   virtio-msg: add conformance entries in conformance chapter
> > > 
> > > Bill Mills (2):
> > >   virtio-msg: Add virtio-msg, a message based virtio transport layer
> > >   virtio-msg: link virtio-msg content
> > > 
> > >  commands.tex      |    3 +-
> > >  conformance.tex   |  105 ++-
> > >  content.tex       |    1 +
> > >  transport-msg.tex | 1640 +++++++++++++++++++++++++++++++++++++++++++++
> > >  4 files changed, 1746 insertions(+), 3 deletions(-)
> > >  create mode 100644 transport-msg.tex
> > > 
> > > -- 
> > > 2.34.1
> > > 
> >