/
2025-10 Update and Notes

2025-10 Update and Notes

Summary of Month

Highlights

  • Spec: Added parallel request token and alignment padding in {SET/GET}_VQUEUE

  • Spec: Incorporated feedback from the mailing list

  • FFA: First draft of virtio-msg for FFA made publicly available

  • QEMU: First RFC for virtio-msg-amp (uses internally emulated PCI card)

  • AMP: Reproduced demo on 5050A w/ test automation. Ran 80 tests with 100% pass

  • OPTEE: First proof of concept demos for virtio-msg in OP-TEE using VSOCK

Plans

  • Spec:

    • Publish PR for functional changes (Add TID to common header, remove redundant lengths)

    • Publish PR with Peter’s editorial changes

    • Publish PR with hvac-demo updates

    • Publish Patch V1 to virtio-comment list (first non-RFC version)

  • hvac-demo updates:

    • Rebase demo-amp-dual-linux to LKML RFC v1/v2/v3

    • Stretch: Rebase all demos to use messages aligned with V1 spec patch (LKML RFC v3)

    • Stretch: Build AMD demo from hvac-demo repo

Issues

Meeting October 16 (moved from Oct 8 )

  • Review current spec changes

  • Added req_id to message header

  • Removed redundant lengths from SET_CONFIG and SET_FEATURES. The lengths are still needed for GET_FEATURES and GET_CONFIG and thus SET_* is not symmetric to GET_*. Are we sure we want to do this?

  • Included editorial fixes and suggestions from Matis

  • Included simple editorial fixes from Peter

  • TODO from Peter: make sure next offset is well described in overview and maybe add link back in message def

  • TODO from Peter: comprehend notification suppression in conformance statements

  • TODO from Peter: outcome of below items

 

Other suggestions from Peter:

  • Q: Replace tables with C structures A: for now leave as is

  • Q: Align all fields to element size (specifically {SET,GET}_VQUEUE. A: ?? Does this still fix FFA registers? Messages are byte streams not directly addressable C structures. A2: Ok to add pad but messages are STILL byte streams

  • Q: Specify interface between bus and transport. A: Does this belong in this spec? We specify requirements but not the actual interface as that can vary from implementation to implementation.

 

  • Q: Split normative non-normative text sections like the other chapters of the spec A: Yes, the conformance should be organized as the other transports do

  • Q: Define 3 elements for conformance: bus instance, not device-specific device-side bus endpoint, not device specific driver side bus end-point A: ?? Bill feels that we already do. Is the request to be more formal about it?

  • Q: Move conformance links to conformance.tex like the other transports A: yes that should be done. Lets do that as part of conformance re-work

 

  • Q: Should sending of RESET_VQUEUE w/o VIRTIO_F_RING_RESET be a MUST NOT instead of a SHOULD NOT. A: The feature was added for back compatatbility and the action is un-ambiquious so I think it is OK to be SHOULD NOT. MUST NOT is also ok.

  • Q: Should max message length, version, and features be messages instead of just “advertised”. Should features be negotiated. A: Yes I think at least some bus implementations will do that for version and features. I think max message size will be handled by some other way typically. I think the word “advertised” here say that the bus will advertise to the transport level.

  • msg_type: Q: define a bit for response expected? A: We do this in msg_id. It is not the same bit for transport and bus messages

  • Q: what should happen if msg_size does not match size implied by msg_id. A: If too short it is a mal formed message; if too long, it could be ignored or treated as invalid

  • Q: drivers don’t expect config writes to fail and won’t reread. A: config read and write is a transport level operation, drivers read via transport level ops and this behavior can be implemented in the common transport

  • Q: the current spec does not have the concept of shutting down a device. A: The spec does specify how to reset a device which is form of shutdown. Existing buses like PCI do support hotplug and unplug. As we are defining a new bus type, this info needs to go somewhere

  • Q: Why does the response repeat the request parameters in GET_FEATURES (and other places). A: response matching is optional. The message is more clear w/o having to cross reference to the request. I would not change this

Tenstoreent:

  • When will virtio-msg-amp be upstream: Bill target RFC end of Nov. Use current version for demo is fine but be ready to change.

  • New queue format is defined here: https://github.com/wmamills/hvac-demo/blob/main/notes/amp-data-structures.h

  • Want device on PCI-RC, driver side on EP Linux cores but EP HW is controlled via ARC cores. Have 4G memory window from RC to EP. ARC cores can inject IRQ to EP Linux cores. Need a way for EP Linux to send MSI to RC, will probibly need to go via ARC cores

Meeting October 23

  • Spec PR: drop redundant lengths commit, add SET_/GET_VQUEUE padding, other quick fixes

  • Spec RFCv3 next week after Edgar's QEMU RFC

  • Add FFA spec to cover letter

  • Maybe add kernel RFC?

  • Edgar to adjust QEMU and kernel common code to current spec and publish QEMU RFC

  • Cancel Nov 6 due to internal Linaro meeting

  • Move Nov 20 and later meetings 1 hour later so that India (that does not do daylight savings time)