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

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

FWIW,

Acked-by: Manivannan Sadhasivam <[email protected]>

- Mani

-- 
மணிவண்ணன் சதாசிவம்