Review v1/v0

.prjinfo/sendmail/cover.txt

@@ -61,41 +61,81 @@ We also anticipate a few more:
   * 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
+Changes since v1 (virtio-msg-patch1):
+
+First, thank you for the detailed comments and broad interest on v1.
+We tried to address most review feedback in this revision.
+
+Spec Functional / Behavioral:
+* Finalized the common header and addressing model:
+  * Keep a 16-byte common header
+  * Use 64-bit device numbers
+  * Use 16-bit msg_size plus 16-bit reserved
+  Rationale: support larger device-number spaces while keeping the transport
+  control-plane focused and limiting payload-transfer misuse.
+* Clarified device-number lifecycle guidance so bus implementations should avoid
+  immediate reuse of removed device numbers.
+  Rationale: reduce races with delayed messages when devices are removed and
+  added again.
+* Added explicit configuration semantics profiles (baseline vs strict) and
+  gated generation-mismatch refusal to strict-profile negotiation.
+  Rationale: preserve compatibility in baseline mode while allowing stricter
+  behavior when both sides opt in.
+* Clarified SET_CONFIG rejection behavior: rejected responses return
+  length = 0 with no payload.
+  Rationale: remove ambiguity for parser/validation behavior.
+* Clarified ordering baseline: request/response ordering is per-device in-order,
+  while events remain asynchronous and may arrive at any time relative to
+  request/response traffic.
+  Rationale: keep baseline semantics clear without over-constraining event
+  delivery.
+* Clarified virtqueue state transitions and reconfiguration rules around
+  enabled/disabled/reset states.
+  Rationale: align with transport expectations and avoid ambiguous queue-state
+  behavior.
+* Clarified GET_DEVICE_INFO semantics using number of 32-bit feature blocks and
+  aligned related field descriptions.
+  Rationale: improve consistency and implementation clarity.
+* Clarified GET_DEVICES semantics using direct slot/byte units; responders must
+  not return count values larger than requested; smaller (including zero) count
+  is valid when appropriate.
+  Rationale: make enumeration behavior precise while allowing efficient sparse
+  windows.
+* Added an informative known bus implementation examples section, including the
+  FF-A bus specification reference and current implementation examples.
+  Rationale: provide concrete context without constraining architecture choices.
+* Tightened conformance text to match the clarified normative behavior.
+
+Open topics and ongoing discussion:
+* Out-of-order/performance extensions:
+  We kept the baseline behavior simple in this revision. If clear performance
+  benefit is demonstrated, we are open to introducing an optional feature-bit
+  based extension in a follow-up patch set.
+* Graceful device removal sequencing:
+  Current direction is to handle graceful-remove sequencing in bus-specific
+  specifications. We welcome feedback on whether any additional transport-level
+  guidance would be useful.
+* Transport scope and mapping guidance:
+  Discussion is still ongoing on transport-vs-bus binding scope, response
+  status modeling, and mapping guidance for mmio/pci/vhost-user/KVM userspace
+  cases. We are collecting reviewer input before deciding on follow-up text.
+* Potential virtio-msg over virtqueues for PCI/MMIO:
+  This is still early discussion, including whether admin virtqueues should be
+  used or extended for this purpose. There is no consensus yet, and we are
+  continuing design exploration.
 
 Eco-system:
 * Added virtio-msg-loopback demo
-* Arm has published the first draft of the virtio-msg over FFA spec [6]
+* Arm has published a second draft of the virtio message bus over FF-A
+  specification (1.0 ALP1), aligned with the virtio-msg v1 proposal [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.
+This is v2 of the first non-RFC patch series. We are grateful for the review
+feedback and interest received on v1, and we ask for continued review on this
+revision.
 
 Background info and work in progress implementations:
 * HVAC project page with intro slides [1]
@@ -117,6 +157,6 @@ with this version of the spec.
 [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
+[6] https://developer.arm.com/documentation/den0153/0101/
 [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

conformance.tex

@@ -155,7 +155,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
 \begin{itemize}
 \item \ref{drivernormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Revisions / Driver Limits}
 \item \ref{drivernormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Versioning and Forward Compatibility / Driver}
-\item \ref{drivernormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Configuration Generation Count / Driver}
+\item \ref{drivernormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Configuration Semantics Profiles / Driver}
 \item \ref{drivernormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Endianness / Driver}
 \item \ref{drivernormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Common Message Format / Driver}
 \item \ref{drivernormative:Virtio Transport Options / Virtio Over Messages / Device Initialization / Overview / Driver}
@@ -285,7 +285,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
 \begin{itemize}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Revisions / Device Limits}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Versioning and Forward Compatibility / Device}
-\item \ref{devicenormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Configuration Generation Count / Device}
+\item \ref{devicenormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Configuration Semantics Profiles / Device}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Feature Blocks / Device}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Error Signaling / Device}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Endianness / Device}
@@ -360,6 +360,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
 \item \ref{busnormative:Virtio Transport Options / Virtio Over Messages / Device Discovery / Bus}
 \item \ref{busnormative:Virtio Transport Options / Virtio Over Messages / Device Operation / Driver Notifications / Bus}
 \item \ref{busnormative:Virtio Transport Options / Virtio Over Messages / Device Operation / Device Notifications / Bus}
+\item \ref{busnormative:Virtio Transport Options / Virtio Over Messages / Transport Messages / Runtime Notifications / Bus}
 \item \ref{busnormative:Virtio Transport Options / Virtio Over Messages / Device Operation / Hotplug and Removal / Bus}
 \item \ref{busnormative:Virtio Transport Options / Virtio Over Messages / Transport Messages / VIRTIO_MSG_EVENT_AVAIL / Bus}
 \item \ref{busnormative:Virtio Transport Options / Virtio Over Messages / Bus Messages / GET_DEVICES / Bus}