Hi Bill,
Some minor comments inline after.
On 21 Jan 2026, at 22:28, Bill Mills bill.mills@linaro.org wrote:
All,
[Ignore the version with 8 patches. This is the correct one.]
This is local to our mailing list. I have also updated the PR [1].
Please let me know if you have feedback as I plan to send to the public mail list on Friday.
Thanks, Bill
[1] https://github.com/Linaro/virtio-msg-spec/pull/29
On 1/21/26 4:07 PM, 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.
How much of the bus level should be described in the virtio spec is one item we wish to discuss. This draft takes a middle approach by describing the bus level and defining some standard bus level messages that MAY be used by the bus. It also describes a range of bus messages that are implementation dependent.
We might want to rephrase the previous paragraph as this is not a draft anymore. At this stage i would suggest to remove it as we describe standard bus messages after.
The rest looks good to me.
Cheers Bertrand
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=vir... [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
-- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur
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.