Sorry for the delay, I was out for some days :-)
Looks good to me too!
Cheers, Edgar
On Fri, Jun 20, 2025 at 07:10:29AM +0000, Arnaud POULIQUEN wrote:
Hi Bill,
Look goot to me too. I also approved PR 23
Thanks, Arnaud
-----Original Message----- From: Bertrand Marquis Bertrand.Marquis@arm.com Sent: Friday, June 20, 2025 8:25 AM To: Bill Mills (bill.mills@linaro.org) bill.mills@linaro.org Cc: virtio-msg@lists.linaro.org; Edgar E . Iglesias edgar.iglesias@amd.com; Arnaud POULIQUEN - foss arnaud.pouliquen@foss.st.com; Viresh Kumar viresh.kumar@linaro.org; Alex Bennee alex.bennee@linaro.org Subject: [Virtio-msg] Re: [PATCH RFC v2 0/1] virtio-msg transport layer
Hi Bill,
On 20 Jun 2025, at 01:08, Bill Mills bill.mills@linaro.org wrote:
All,
This is just to our list. I will be sending this to the upstream list tomorrow. If you see anything high priority and quick to fix let me know.
Looks good to me
Beyond the PR#20 I had to do one more commit to get rid of non-ASCII characters. This commit is squashed below but you can see it alone here: https://github.com/Linaro/virtio-msg-spec/pull/23
Looks good to me, added my review approval.
The new base line is virtio-msg-rfc2. This branch is current published at the Linaro repo as the latest commit on upstream virtio-1.4 and the PR for RFC2 is seen here: https://github.com/Linaro/virtio-msg-spec/pull/22
Thanks Bertrand
Thanks, Bill
On 6/19/25 6:54 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.
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 two 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
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
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-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
Once developed this can provide a single kernel demo of virtio-msg
[Work has begun on this]
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 RFC1:
- reformated document to better conform to the virtio spec style
- created an introduction chapter
- created a basic concept chapter
- created bus operation and device initialization and operation
chapters
- reworked description of transport and bus messages
- attempted a "compliance chapter"
- reused spec macros
- switched to MAY/MUST/SHALL/SHOULD wording
- eliminate the use of terms front-end and back-end and use driver
and device
- made the maximum message size variable per bus instance
- use "device number" for virtio-msg device instances on the bus
instead of adding yet another meaning for "device ID"
- added the configuration generation count and its use
- described types of things that can be done with bus specific
messages such as setup of bus level shared memory and out of band notifications
- removed wording of notification being optional at transport level
and described bus level notifications of in-band, out-of-band, and polled from driver side bus
- removed the ERROR message from transport level. Errors should be
handled at the bus level to better match virtio-pci and virtio-mmio
- removed bus level reset and status from standard bus messages
- replaced bus messages DEVICE_{ADDED,REMOVED} with
EVENT_DEVICE
- changed names to GET_DEVICE_FEATURES and SET_DRIVER_FEATURES
for
clarity
- made SET_DEVICE_STATE return new state as it may not match
- Don't echo back the data in SET_VQUEUE (it cannot change)
- defined request/response vs event message id ranges
- match field size of next offset and wrap to virtio-{pci,mmio}
- added maximum number of virtqueues to DEVICE_INFO
- added admin virtqueue and SHM support
This series is a work in progress and we acknowledge at least the following issues we need to work on:
- Better conformance documentation
- Publish an update to Arm FF-A spec that shows virtio-msg binding
(work underway)
- Publish virtio-msg-amp data structures and messages somewhere
- Align implementations to this version and send PATCH v1 (non-rfc)
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, they are not yet aligned with each other nor 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-new [5] https://github.com/arnopo/open-amp/commits/virtio-msg/
Bill Mills (1): virtio-msg: Add virtio-msg, a message based virtio transport layer
content.tex | 1 + transport-msg.tex | 1354 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 1355 insertions(+) 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. _______________________________________________ Virtio-msg mailing list -- virtio-msg@lists.linaro.org To unsubscribe send an email to virtio-msg-leave@lists.linaro.org