* [virtio-dev] [RFC PATCH v3] virtio-can: Device specification.
@ 2023-06-09 14:22 Mikhail Golubev-Ciuchea
2024-01-08 17:18 ` [virtio-dev] Re: [virtio-comment] " Mikhail Golubev-Ciuchea
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Mikhail Golubev-Ciuchea @ 2023-06-09 14:22 UTC (permalink / raw)
To: virtio-comment, virtio-dev, linux-can
Cc: Harald Mommer, Mikhail Golubev-Ciuchea
From: Harald Mommer <harald.mommer@opensynergy.com>
virtio-can is a virtual CAN device. It provides a way to give access to
a CAN controller from a driver guest. The device is aimed to be used by
driver guests running a HLOS as well as by driver guests running a
typical RTOS as used in controller environments.
Signed-off-by: Harald Mommer <Harald.Mommer@opensynergy.com>
Signed-off-by: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
---
RFC v3:
* Add length fields in CAN RX and TX messages.
* Replace bus off indication queue with a config space bit.
* Clarify handling of unknown flag bits set in CAN frame.
* Remove MISRA C suffixes in constants.
* Reserve 16 bits in RX/TX messages for CAN XL priority.
* Reserve 8 bits in RX/TX messages for CAN classic DLC.
* Rework according to general virtio spec POV.
* Implementation:
driver: https://lore.kernel.org/all/20230607145613.133203-1-Mikhail.Golubev-Ciuchea@opensynergy.com/
QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
RFC v2:
* Add CAN classic feature flag.
* Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
* Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
* Reserve 32 bits in RX/TX messages.
* Remove priorities of messages.
conformance.tex | 12 +-
content.tex | 1 +
device-types/can/description.tex | 249 ++++++++++++++++++++++++
device-types/can/device-conformance.tex | 8 +
device-types/can/driver-conformance.tex | 7 +
introduction.tex | 2 +
6 files changed, 275 insertions(+), 4 deletions(-)
create mode 100644 device-types/can/description.tex
create mode 100644 device-types/can/device-conformance.tex
create mode 100644 device-types/can/driver-conformance.tex
diff --git a/conformance.tex b/conformance.tex
index 01ccd69..a07ef02 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
\ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
\ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
-\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
-\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
+\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
+\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
+\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
\end{itemize}
@@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\ref{sec:Conformance / Device Conformance / Memory Device Conformance},
\ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
\ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
-\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
-\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
+\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
+\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
+\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
\end{itemize}
@@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\input{device-types/scmi/driver-conformance.tex}
\input{device-types/gpio/driver-conformance.tex}
\input{device-types/pmem/driver-conformance.tex}
+\input{device-types/can/driver-conformance.tex}
\conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
@@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\input{device-types/scmi/device-conformance.tex}
\input{device-types/gpio/device-conformance.tex}
\input{device-types/pmem/device-conformance.tex}
+\input{device-types/can/device-conformance.tex}
\conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
A conformant implementation MUST be either transitional or
diff --git a/content.tex b/content.tex
index d2ab9eb..8806b57 100644
--- a/content.tex
+++ b/content.tex
@@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
\input{device-types/scmi/description.tex}
\input{device-types/gpio/description.tex}
\input{device-types/pmem/description.tex}
+\input{device-types/can/description.tex}
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
diff --git a/device-types/can/description.tex b/device-types/can/description.tex
new file mode 100644
index 0000000..2511d9c
--- /dev/null
+++ b/device-types/can/description.tex
@@ -0,0 +1,249 @@
+\section{CAN Device}\label{sec:Device Types / CAN Device}
+
+virtio-can is a virtio based CAN (Controller Area Network) controller.
+It is used to give a virtual machine access to a CAN bus. The CAN bus
+might either be a physical CAN bus or a virtual CAN bus between virtual
+machines or a combination of both.
+
+\subsection{Device ID}\label{sec:Device Types / CAN Device / Device ID}
+
+36
+
+\subsection{Virtqueues}\label{sec:Device Types / CAN Device / Virtqueues}
+
+\begin{description}
+\item[0] Txq
+\item[1] Rxq
+\item[2] Controlq
+\end{description}
+
+The \field{Txq} is used to send CAN packets to the CAN bus.
+
+The \field{Rxq} is used to receive CAN packets from the CAN bus.
+
+The \field{Controlq} is used to control the state of the CAN controller.
+
+\subsection{Feature bits}{Device Types / CAN Device / Feature bits}
+
+Actual CAN controllers support Extended CAN IDs with 29 bits (CAN~2.0B)
+as well as Standard CAN IDs with 11 bits (CAN~2.0A). The support of
+CAN~2.0B Extended CAN IDs is considered as mandatory for this
+specification.
+
+\begin{description}
+
+\item[VIRTIO_CAN_F_CAN_CLASSIC (0)]
+
+The device supports classic CAN frames with a maximum payload size of 8
+bytes.
+
+\item[VIRTIO_CAN_F_CAN_FD (1)]
+
+The device supports CAN FD frames with a maximum payload size of 64
+bytes.
+
+\item[VIRTIO_CAN_F_RTR_FRAMES (2)]
+
+The device supports RTR (remote transmission request) frames. RTR frames
+are only supported with classic CAN.
+
+\item[VIRTIO_CAN_F_LATE_TX_ACK (3)]
+
+The virtio CAN device marks transmission requests from the \field{Txq}
+as used after the CAN message has been transmitted on the CAN bus. If
+this feature bit has not been negotiated, the device is allowed to mark
+transmission requests already as used when the CAN message has been
+scheduled for transmission but might not yet have been transmitted on
+the CAN bus.
+
+\end{description}
+
+\subsubsection{Feature bit requirements}\label{sec:Device Types / CAN Device / Feature bits / Feature bit requirements}
+
+Some CAN feature bits require other CAN feature bits:
+\begin{description}
+\item[VIRTIO_CAN_F_RTR_FRAMES] Requires VIRTIO_CAN_F_CAN_CLASSIC.
+\end{description}
+
+It is required that at least one of VIRTIO_CAN_F_CAN_CLASSIC and
+VIRTIO_CAN_F_CAN_FD is negotiated.
+
+\subsection{Device configuration layout}\label{sec:Device Types / CAN Device / Device configuration layout}
+
+Device configuration fields are listed below, they are read-only for a
+driver. The \field{status} always exists. A single read-only bit (for
+the driver) is currently defined for \field{status}:
+
+\begin{lstlisting}
+struct virtio_can_config {
+#define VIRTIO_CAN_S_CTRL_BUSOFF (1 << 0)
+ le16 status;
+};
+\end{lstlisting}
+
+The bit VIRTIO_CAN_S_CTRL_BUSOFF in \field{status} is used to indicate
+the unsolicited CAN controller state change from started to stopped due
+to a detected bus off condition.
+
+\drivernormative{\subsubsection}{Device Initialization}{Device Types / CAN Device / Device Operation / Initialization}
+
+The driver MUST populate the \field{Rxq} with empty device-writeable
+buffers of at least the size of struct virtio_can_rx, see section
+\ref{struct virtio_can_rx}.
+
+\subsection{Device Operation}\label{sec:Device Types / CAN Device / Device Operation}
+
+A device operation has an outcome which is described by one of the
+following values:
+
+\begin{lstlisting}
+#define VIRTIO_CAN_RESULT_OK 0
+#define VIRTIO_CAN_RESULT_NOT_OK 1
+\end{lstlisting}
+
+Other values are to be treated like VIRTIO_CAN_RESULT_NOT_OK.
+
+\subsubsection{Controller Mode}\label{sec:Device Types / CAN Device / Device Operation / Controller Mode}
+
+The general format of a request in the \field{Controlq} is
+
+\begin{lstlisting}
+struct virtio_can_control_out {
+#define VIRTIO_CAN_SET_CTRL_MODE_START 0x0201
+#define VIRTIO_CAN_SET_CTRL_MODE_STOP 0x0202
+ le16 msg_type;
+};
+\end{lstlisting}
+
+To participate in bus communication the CAN controller is started by
+sending a VIRTIO_CAN_SET_CTRL_MODE_START control message, to stop
+participating in bus communication it is stopped by sending a
+VIRTIO_CAN_SET_CTRL_MODE_STOP control message. Both requests are
+confirmed by the result of the operation.
+
+\begin{lstlisting}
+struct virtio_can_control_in {
+ u8 result;
+};
+\end{lstlisting}
+
+If the transition succeeded the \field{result} is VIRTIO_CAN_RESULT_OK
+otherwise it is VIRTIO_CAN_RESULT_NOT_OK. If a status update is
+necessary, the device updates the configuration \field{status} before
+marking the request used. As the configuration \field{status} change is
+caused by a request from the driver the device is allowed to omit the
+configuration change notification here. The device marks the request
+used when the CAN controller has finalized the transition to the
+requested controller mode.
+
+On transition to the STOPPED state the device cancels all CAN messages
+already pending for transmission and marks them as used with
+\field{result} VIRTIO_CAN_RESULT_NOT_OK. In the STOPPED state the
+device marks messages received from the
+\field{Txq} as used with \field{result} VIRTIO_CAN_RESULT_NOT_OK without
+transmitting them to the CAN bus.
+
+Initially the CAN controller is in the STOPPED state.
+
+Control queue messages are processed in order.
+
+\devicenormative{\subsubsection}{CAN Message Transmission}{Device Types / CAN Device / Device Operation / CAN Message Transmission}
+
+The driver transmits messages by placing outgoing CAN messages in the
+\field{Txq} virtqueue.
+
+\label{struct virtio_can_tx_out}
+\begin{lstlisting}
+struct virtio_can_tx_out {
+#define VIRTIO_CAN_TX 0x0001
+ le16 msg_type;
+ le16 length; /* 0..8 CC, 0..64 CAN-FD, 0..2048 CAN-XL, 12 bits */
+ u8 reserved_classic_dlc; /* If CAN classic length = 8 then DLC can be 8..15 */
+ u8 padding;
+ le16 reserved_xl_priority; /* May be needed for CAN XL priority */
+#define VIRTIO_CAN_FLAGS_FD 0x4000
+#define VIRTIO_CAN_FLAGS_EXTENDED 0x8000
+#define VIRTIO_CAN_FLAGS_RTR 0x2000
+ le32 flags;
+ le32 can_id;
+ u8 sdu[];
+};
+
+struct virtio_can_tx_in {
+ u8 result;
+};
+\end{lstlisting}
+
+The length of the \field{sdu} is determined by the \field{length}.
+
+The type of a CAN message identifier is determined by \field{flags}. The
+3 most significant bits of \field{can_id} do not bear the information
+about the type of the CAN message identifier and are 0.
+
+The device MUST reject any CAN frame type for which support has not been
+negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
+schedule the message for transmission. A CAN frame with an undefined bit
+set in \field{flags} is treated like a CAN frame for which support has
+not been negotiated.
+
+The device MUST reject any CAN frame for which \field{can_id} or
+\field{sdu} length are out of range or the CAN controller is in an
+invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
+NOT schedule the message for transmission.
+
+If the parameters are valid the message is scheduled for transmission.
+
+If feature VIRTIO_CAN_F_CAN_LATE_TX_ACK has been negotiated the
+transmission request MUST be marked as used with \field{result} set to
+VIRTIO_CAN_OK after the CAN controller acknowledged the successful
+transmission on the CAN bus. If this feature bit has not been negotiated
+the transmission request MAY already be marked as used with
+\field{result} set to VIRTIO_CAN_OK when the transmission request has
+been processed by the virtio CAN device and send down the protocol stack
+being scheduled for transmission.
+
+\subsubsection{CAN Message Reception}\label{sec:Device Types / CAN Device / Device Operation / CAN Message Reception}
+
+Messages can be received by providing empty incoming buffers to the
+virtqueue \field{Rxq}.
+
+\label{struct virtio_can_rx}
+\begin{lstlisting}
+struct virtio_can_rx {
+#define VIRTIO_CAN_RX 0x0101
+ le16 msg_type;
+ le16 length; /* 0..8 CC, 0..64 CAN-FD, 0..2048 CAN-XL, 12 bits */
+ u8 reserved_classic_dlc; /* If CAN classic length = 8 then DLC can be 8..15 */
+ u8 padding;
+ le16 reserved_xl_priority; /* May be needed for CAN XL priority */
+ le32 flags;
+ le32 can_id;
+ u8 sdu[];
+};
+\end{lstlisting}
+
+If the feature VIRTIO_CAN_F_CAN_FD has been negotiated the maximal
+possible \field{sdu} length is 64, if the feature has not been
+negotiated the maximal possible \field{sdu} length is 8.
+
+The actual length of the \field{sdu} is determined by the \field{length}.
+
+The type of a CAN message identifier is determined by \field{flags} in
+the same way as for transmitted CAN messages, see section \ref{struct
+virtio_can_tx_out}. The 3 most significant bits of \field{can_id} do not
+bear the information about the type of the CAN message identifier and
+are 0. The flag bits are exactly the same as for the \field{flags} of
+struct virtio_can_tx_out.
+
+\subsubsection{BusOff Indication}\label{sec:Device Types / CAN Device / Device Operation / BusOff Indication}
+
+There are certain error conditions so that the physical CAN controller
+has to stop participating in CAN communication on the bus. If such an
+error condition occurs the device informs the driver about the
+unsolicited CAN controller state change by setting the
+VIRTIO_CAN_S_CTRL_BUSOFF bit in the configuration \field{status} field.
+
+After bus-off detection the CAN controller is in STOPPED state. The CAN
+controller does not participate in bus communication any more so all CAN
+messages pending for transmission are put into the used queue with
+\field{result} VIRTIO_CAN_RESULT_NOT_OK.
diff --git a/device-types/can/device-conformance.tex b/device-types/can/device-conformance.tex
new file mode 100644
index 0000000..f944ffd
--- /dev/null
+++ b/device-types/can/device-conformance.tex
@@ -0,0 +1,8 @@
+\conformance{\subsection}{CAN Device Conformance}\label{sec:Conformance / Device Conformance / CAN Device Conformance}
+
+A CAN device MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{devicenormative:Device Types / CAN Device / Feature bits}
+\item \ref{devicenormative:Device Types / CAN Device / Device Operation / CAN Message Transmission}
+\end{itemize}
diff --git a/device-types/can/driver-conformance.tex b/device-types/can/driver-conformance.tex
new file mode 100644
index 0000000..32e3e87
--- /dev/null
+++ b/device-types/can/driver-conformance.tex
@@ -0,0 +1,7 @@
+\conformance{\subsection}{CAN Driver Conformance}\label{sec:Conformance / Driver Conformance / CAN Driver Conformance}
+
+A CAN driver MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{drivernormative:Device Types / CAN Device / Device Operation / Initialization}
+\end{itemize}
diff --git a/introduction.tex b/introduction.tex
index b7155bf..d560c63 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -101,6 +101,8 @@ \section{Normative References}\label{sec:Normative References}
\phantomsection\label{intro:SEC1}\textbf{[SEC1]} &
Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
\newline\url{https://www.secg.org/sec1-v2.pdf}\\
+ \phantomsection\label{intro:CAN}\textbf{[CAN]} &
+ ISO 11898-1:2015 Road vehicles -- Controller area network (CAN) -- Part 1: Data link layer and physical signalling\\
\end{longtable}
--
2.34.1
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2023-06-09 14:22 [virtio-dev] [RFC PATCH v3] virtio-can: Device specification Mikhail Golubev-Ciuchea
@ 2024-01-08 17:18 ` Mikhail Golubev-Ciuchea
2024-01-15 16:24 ` Cornelia Huck
` (2 more replies)
2024-02-13 14:57 ` [virtio-dev] " Cornelia Huck
2024-02-16 11:08 ` Cornelia Huck
2 siblings, 3 replies; 15+ messages in thread
From: Mikhail Golubev-Ciuchea @ 2024-01-08 17:18 UTC (permalink / raw)
To: virtio-comment, virtio-dev, linux-can; +Cc: Harald Mommer
Hi all!
I kindly request a vote.
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
Best wishes,
Mikhail Golubev-Ciuchea
On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
> From: Harald Mommer <harald.mommer@opensynergy.com>
>
> virtio-can is a virtual CAN device. It provides a way to give access to
> a CAN controller from a driver guest. The device is aimed to be used by
> driver guests running a HLOS as well as by driver guests running a
> typical RTOS as used in controller environments.
>
> Signed-off-by: Harald Mommer <Harald.Mommer@opensynergy.com>
> Signed-off-by: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
> ---
>
> RFC v3:
> * Add length fields in CAN RX and TX messages.
> * Replace bus off indication queue with a config space bit.
> * Clarify handling of unknown flag bits set in CAN frame.
> * Remove MISRA C suffixes in constants.
> * Reserve 16 bits in RX/TX messages for CAN XL priority.
> * Reserve 8 bits in RX/TX messages for CAN classic DLC.
> * Rework according to general virtio spec POV.
> * Implementation:
> driver: https://lore.kernel.org/all/20230607145613.133203-1-Mikhail.Golubev-Ciuchea@opensynergy.com/
> QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
>
> RFC v2:
> * Add CAN classic feature flag.
> * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
> * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
> * Reserve 32 bits in RX/TX messages.
> * Remove priorities of messages.
>
> conformance.tex | 12 +-
> content.tex | 1 +
> device-types/can/description.tex | 249 ++++++++++++++++++++++++
> device-types/can/device-conformance.tex | 8 +
> device-types/can/driver-conformance.tex | 7 +
> introduction.tex | 2 +
> 6 files changed, 275 insertions(+), 4 deletions(-)
> create mode 100644 device-types/can/description.tex
> create mode 100644 device-types/can/device-conformance.tex
> create mode 100644 device-types/can/driver-conformance.tex
>
> diff --git a/conformance.tex b/conformance.tex
> index 01ccd69..a07ef02 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
> \ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
> \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
> -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
> -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
> +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
> +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
> +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
>
> \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> \end{itemize}
> @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \ref{sec:Conformance / Device Conformance / Memory Device Conformance},
> \ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
> \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
> -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
> -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
> +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
> +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
> +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
>
> \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> \end{itemize}
> @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \input{device-types/scmi/driver-conformance.tex}
> \input{device-types/gpio/driver-conformance.tex}
> \input{device-types/pmem/driver-conformance.tex}
> +\input{device-types/can/driver-conformance.tex}
>
> \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
>
> @@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \input{device-types/scmi/device-conformance.tex}
> \input{device-types/gpio/device-conformance.tex}
> \input{device-types/pmem/device-conformance.tex}
> +\input{device-types/can/device-conformance.tex}
>
> \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
> A conformant implementation MUST be either transitional or
> diff --git a/content.tex b/content.tex
> index d2ab9eb..8806b57 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
> \input{device-types/scmi/description.tex}
> \input{device-types/gpio/description.tex}
> \input{device-types/pmem/description.tex}
> +\input{device-types/can/description.tex}
>
> \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
>
> diff --git a/device-types/can/description.tex b/device-types/can/description.tex
> new file mode 100644
> index 0000000..2511d9c
> --- /dev/null
> +++ b/device-types/can/description.tex
> @@ -0,0 +1,249 @@
> +\section{CAN Device}\label{sec:Device Types / CAN Device}
> +
> +virtio-can is a virtio based CAN (Controller Area Network) controller.
> +It is used to give a virtual machine access to a CAN bus. The CAN bus
> +might either be a physical CAN bus or a virtual CAN bus between virtual
> +machines or a combination of both.
> +
> +\subsection{Device ID}\label{sec:Device Types / CAN Device / Device ID}
> +
> +36
> +
> +\subsection{Virtqueues}\label{sec:Device Types / CAN Device / Virtqueues}
> +
> +\begin{description}
> +\item[0] Txq
> +\item[1] Rxq
> +\item[2] Controlq
> +\end{description}
> +
> +The \field{Txq} is used to send CAN packets to the CAN bus.
> +
> +The \field{Rxq} is used to receive CAN packets from the CAN bus.
> +
> +The \field{Controlq} is used to control the state of the CAN controller.
> +
> +\subsection{Feature bits}{Device Types / CAN Device / Feature bits}
> +
> +Actual CAN controllers support Extended CAN IDs with 29 bits (CAN~2.0B)
> +as well as Standard CAN IDs with 11 bits (CAN~2.0A). The support of
> +CAN~2.0B Extended CAN IDs is considered as mandatory for this
> +specification.
> +
> +\begin{description}
> +
> +\item[VIRTIO_CAN_F_CAN_CLASSIC (0)]
> +
> +The device supports classic CAN frames with a maximum payload size of 8
> +bytes.
> +
> +\item[VIRTIO_CAN_F_CAN_FD (1)]
> +
> +The device supports CAN FD frames with a maximum payload size of 64
> +bytes.
> +
> +\item[VIRTIO_CAN_F_RTR_FRAMES (2)]
> +
> +The device supports RTR (remote transmission request) frames. RTR frames
> +are only supported with classic CAN.
> +
> +\item[VIRTIO_CAN_F_LATE_TX_ACK (3)]
> +
> +The virtio CAN device marks transmission requests from the \field{Txq}
> +as used after the CAN message has been transmitted on the CAN bus. If
> +this feature bit has not been negotiated, the device is allowed to mark
> +transmission requests already as used when the CAN message has been
> +scheduled for transmission but might not yet have been transmitted on
> +the CAN bus.
> +
> +\end{description}
> +
> +\subsubsection{Feature bit requirements}\label{sec:Device Types / CAN Device / Feature bits / Feature bit requirements}
> +
> +Some CAN feature bits require other CAN feature bits:
> +\begin{description}
> +\item[VIRTIO_CAN_F_RTR_FRAMES] Requires VIRTIO_CAN_F_CAN_CLASSIC.
> +\end{description}
> +
> +It is required that at least one of VIRTIO_CAN_F_CAN_CLASSIC and
> +VIRTIO_CAN_F_CAN_FD is negotiated.
> +
> +\subsection{Device configuration layout}\label{sec:Device Types / CAN Device / Device configuration layout}
> +
> +Device configuration fields are listed below, they are read-only for a
> +driver. The \field{status} always exists. A single read-only bit (for
> +the driver) is currently defined for \field{status}:
> +
> +\begin{lstlisting}
> +struct virtio_can_config {
> +#define VIRTIO_CAN_S_CTRL_BUSOFF (1 << 0)
> + le16 status;
> +};
> +\end{lstlisting}
> +
> +The bit VIRTIO_CAN_S_CTRL_BUSOFF in \field{status} is used to indicate
> +the unsolicited CAN controller state change from started to stopped due
> +to a detected bus off condition.
> +
> +\drivernormative{\subsubsection}{Device Initialization}{Device Types / CAN Device / Device Operation / Initialization}
> +
> +The driver MUST populate the \field{Rxq} with empty device-writeable
> +buffers of at least the size of struct virtio_can_rx, see section
> +\ref{struct virtio_can_rx}.
> +
> +\subsection{Device Operation}\label{sec:Device Types / CAN Device / Device Operation}
> +
> +A device operation has an outcome which is described by one of the
> +following values:
> +
> +\begin{lstlisting}
> +#define VIRTIO_CAN_RESULT_OK 0
> +#define VIRTIO_CAN_RESULT_NOT_OK 1
> +\end{lstlisting}
> +
> +Other values are to be treated like VIRTIO_CAN_RESULT_NOT_OK.
> +
> +\subsubsection{Controller Mode}\label{sec:Device Types / CAN Device / Device Operation / Controller Mode}
> +
> +The general format of a request in the \field{Controlq} is
> +
> +\begin{lstlisting}
> +struct virtio_can_control_out {
> +#define VIRTIO_CAN_SET_CTRL_MODE_START 0x0201
> +#define VIRTIO_CAN_SET_CTRL_MODE_STOP 0x0202
> + le16 msg_type;
> +};
> +\end{lstlisting}
> +
> +To participate in bus communication the CAN controller is started by
> +sending a VIRTIO_CAN_SET_CTRL_MODE_START control message, to stop
> +participating in bus communication it is stopped by sending a
> +VIRTIO_CAN_SET_CTRL_MODE_STOP control message. Both requests are
> +confirmed by the result of the operation.
> +
> +\begin{lstlisting}
> +struct virtio_can_control_in {
> + u8 result;
> +};
> +\end{lstlisting}
> +
> +If the transition succeeded the \field{result} is VIRTIO_CAN_RESULT_OK
> +otherwise it is VIRTIO_CAN_RESULT_NOT_OK. If a status update is
> +necessary, the device updates the configuration \field{status} before
> +marking the request used. As the configuration \field{status} change is
> +caused by a request from the driver the device is allowed to omit the
> +configuration change notification here. The device marks the request
> +used when the CAN controller has finalized the transition to the
> +requested controller mode.
> +
> +On transition to the STOPPED state the device cancels all CAN messages
> +already pending for transmission and marks them as used with
> +\field{result} VIRTIO_CAN_RESULT_NOT_OK. In the STOPPED state the
> +device marks messages received from the
> +\field{Txq} as used with \field{result} VIRTIO_CAN_RESULT_NOT_OK without
> +transmitting them to the CAN bus.
> +
> +Initially the CAN controller is in the STOPPED state.
> +
> +Control queue messages are processed in order.
> +
> +\devicenormative{\subsubsection}{CAN Message Transmission}{Device Types / CAN Device / Device Operation / CAN Message Transmission}
> +
> +The driver transmits messages by placing outgoing CAN messages in the
> +\field{Txq} virtqueue.
> +
> +\label{struct virtio_can_tx_out}
> +\begin{lstlisting}
> +struct virtio_can_tx_out {
> +#define VIRTIO_CAN_TX 0x0001
> + le16 msg_type;
> + le16 length; /* 0..8 CC, 0..64 CAN-FD, 0..2048 CAN-XL, 12 bits */
> + u8 reserved_classic_dlc; /* If CAN classic length = 8 then DLC can be 8..15 */
> + u8 padding;
> + le16 reserved_xl_priority; /* May be needed for CAN XL priority */
> +#define VIRTIO_CAN_FLAGS_FD 0x4000
> +#define VIRTIO_CAN_FLAGS_EXTENDED 0x8000
> +#define VIRTIO_CAN_FLAGS_RTR 0x2000
> + le32 flags;
> + le32 can_id;
> + u8 sdu[];
> +};
> +
> +struct virtio_can_tx_in {
> + u8 result;
> +};
> +\end{lstlisting}
> +
> +The length of the \field{sdu} is determined by the \field{length}.
> +
> +The type of a CAN message identifier is determined by \field{flags}. The
> +3 most significant bits of \field{can_id} do not bear the information
> +about the type of the CAN message identifier and are 0.
> +
> +The device MUST reject any CAN frame type for which support has not been
> +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> +schedule the message for transmission. A CAN frame with an undefined bit
> +set in \field{flags} is treated like a CAN frame for which support has
> +not been negotiated.
> +
> +The device MUST reject any CAN frame for which \field{can_id} or
> +\field{sdu} length are out of range or the CAN controller is in an
> +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> +NOT schedule the message for transmission.
> +
> +If the parameters are valid the message is scheduled for transmission.
> +
> +If feature VIRTIO_CAN_F_CAN_LATE_TX_ACK has been negotiated the
> +transmission request MUST be marked as used with \field{result} set to
> +VIRTIO_CAN_OK after the CAN controller acknowledged the successful
> +transmission on the CAN bus. If this feature bit has not been negotiated
> +the transmission request MAY already be marked as used with
> +\field{result} set to VIRTIO_CAN_OK when the transmission request has
> +been processed by the virtio CAN device and send down the protocol stack
> +being scheduled for transmission.
> +
> +\subsubsection{CAN Message Reception}\label{sec:Device Types / CAN Device / Device Operation / CAN Message Reception}
> +
> +Messages can be received by providing empty incoming buffers to the
> +virtqueue \field{Rxq}.
> +
> +\label{struct virtio_can_rx}
> +\begin{lstlisting}
> +struct virtio_can_rx {
> +#define VIRTIO_CAN_RX 0x0101
> + le16 msg_type;
> + le16 length; /* 0..8 CC, 0..64 CAN-FD, 0..2048 CAN-XL, 12 bits */
> + u8 reserved_classic_dlc; /* If CAN classic length = 8 then DLC can be 8..15 */
> + u8 padding;
> + le16 reserved_xl_priority; /* May be needed for CAN XL priority */
> + le32 flags;
> + le32 can_id;
> + u8 sdu[];
> +};
> +\end{lstlisting}
> +
> +If the feature VIRTIO_CAN_F_CAN_FD has been negotiated the maximal
> +possible \field{sdu} length is 64, if the feature has not been
> +negotiated the maximal possible \field{sdu} length is 8.
> +
> +The actual length of the \field{sdu} is determined by the \field{length}.
> +
> +The type of a CAN message identifier is determined by \field{flags} in
> +the same way as for transmitted CAN messages, see section \ref{struct
> +virtio_can_tx_out}. The 3 most significant bits of \field{can_id} do not
> +bear the information about the type of the CAN message identifier and
> +are 0. The flag bits are exactly the same as for the \field{flags} of
> +struct virtio_can_tx_out.
> +
> +\subsubsection{BusOff Indication}\label{sec:Device Types / CAN Device / Device Operation / BusOff Indication}
> +
> +There are certain error conditions so that the physical CAN controller
> +has to stop participating in CAN communication on the bus. If such an
> +error condition occurs the device informs the driver about the
> +unsolicited CAN controller state change by setting the
> +VIRTIO_CAN_S_CTRL_BUSOFF bit in the configuration \field{status} field.
> +
> +After bus-off detection the CAN controller is in STOPPED state. The CAN
> +controller does not participate in bus communication any more so all CAN
> +messages pending for transmission are put into the used queue with
> +\field{result} VIRTIO_CAN_RESULT_NOT_OK.
> diff --git a/device-types/can/device-conformance.tex b/device-types/can/device-conformance.tex
> new file mode 100644
> index 0000000..f944ffd
> --- /dev/null
> +++ b/device-types/can/device-conformance.tex
> @@ -0,0 +1,8 @@
> +\conformance{\subsection}{CAN Device Conformance}\label{sec:Conformance / Device Conformance / CAN Device Conformance}
> +
> +A CAN device MUST conform to the following normative statements:
> +
> +\begin{itemize}
> +\item \ref{devicenormative:Device Types / CAN Device / Feature bits}
> +\item \ref{devicenormative:Device Types / CAN Device / Device Operation / CAN Message Transmission}
> +\end{itemize}
> diff --git a/device-types/can/driver-conformance.tex b/device-types/can/driver-conformance.tex
> new file mode 100644
> index 0000000..32e3e87
> --- /dev/null
> +++ b/device-types/can/driver-conformance.tex
> @@ -0,0 +1,7 @@
> +\conformance{\subsection}{CAN Driver Conformance}\label{sec:Conformance / Driver Conformance / CAN Driver Conformance}
> +
> +A CAN driver MUST conform to the following normative statements:
> +
> +\begin{itemize}
> +\item \ref{drivernormative:Device Types / CAN Device / Device Operation / Initialization}
> +\end{itemize}
> diff --git a/introduction.tex b/introduction.tex
> index b7155bf..d560c63 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -101,6 +101,8 @@ \section{Normative References}\label{sec:Normative References}
> \phantomsection\label{intro:SEC1}\textbf{[SEC1]} &
> Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
> \newline\url{https://www.secg.org/sec1-v2.pdf}\\
> + \phantomsection\label{intro:CAN}\textbf{[CAN]} &
> + ISO 11898-1:2015 Road vehicles -- Controller area network (CAN) -- Part 1: Data link layer and physical signalling\\
>
> \end{longtable}
>
--
Mikhail Golubev-Ciuchea
OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
Telefon: +49 (30) 60985400
EMail:
mikhail.golubev-ciuchea@opensynergy.com<mailto:mikhail.golubev-ciuchea@opensynergy.com>
www.opensynergy.com
Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Regis Adjamah
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-01-08 17:18 ` [virtio-dev] Re: [virtio-comment] " Mikhail Golubev-Ciuchea
@ 2024-01-15 16:24 ` Cornelia Huck
2024-02-02 12:45 ` Cornelia Huck
2024-02-20 12:19 ` Matias Ezequiel Vara Larsen
2024-02-21 10:37 ` Matias Ezequiel Vara Larsen
2 siblings, 1 reply; 15+ messages in thread
From: Cornelia Huck @ 2024-01-15 16:24 UTC (permalink / raw)
To: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can
Cc: Harald Mommer
On Mon, Jan 08 2024, Mikhail Golubev-Ciuchea <mikhail.golubev-ciuchea@opensynergy.com> wrote:
> Hi all!
>
> I kindly request a vote.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
Oh, that has been a while... I believe that this still fits on top,
although it has conflicts with virtio-spi, but nothing that a bit of
fiddling can't sort out.
The main problem is that we're currently in a bit of an unfortunate
situation regarding voting: There's still a twice-postponed migration of
the OASIS infrastructure coming up, and I don't want to risk the voting
period being affected by an outage... hopefully we'll get a new schedule
soon.
In the meanwhile, if anyone could spare a few cycles looking at this,
it'd be appreciated. Nothing jumped out at me, but I'm not a CAN expert;
I'd be happy to open voting but for the looming migration issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-01-15 16:24 ` Cornelia Huck
@ 2024-02-02 12:45 ` Cornelia Huck
0 siblings, 0 replies; 15+ messages in thread
From: Cornelia Huck @ 2024-02-02 12:45 UTC (permalink / raw)
To: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can
Cc: Harald Mommer
On Mon, Jan 15 2024, Cornelia Huck <cohuck@redhat.com> wrote:
> On Mon, Jan 08 2024, Mikhail Golubev-Ciuchea <mikhail.golubev-ciuchea@opensynergy.com> wrote:
>
>> Hi all!
>>
>> I kindly request a vote.
>>
>> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
>
> Oh, that has been a while... I believe that this still fits on top,
> although it has conflicts with virtio-spi, but nothing that a bit of
> fiddling can't sort out.
>
> The main problem is that we're currently in a bit of an unfortunate
> situation regarding voting: There's still a twice-postponed migration of
> the OASIS infrastructure coming up, and I don't want to risk the voting
> period being affected by an outage... hopefully we'll get a new schedule
> soon.
>
> In the meanwhile, if anyone could spare a few cycles looking at this,
> it'd be appreciated. Nothing jumped out at me, but I'm not a CAN expert;
> I'd be happy to open voting but for the looming migration issue.
OK, I'll just go ahead and open a vote, no reason to drag this out
further, and hopefully we're done by the time the migration _really_
happens...
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [virtio-dev] [RFC PATCH v3] virtio-can: Device specification.
2023-06-09 14:22 [virtio-dev] [RFC PATCH v3] virtio-can: Device specification Mikhail Golubev-Ciuchea
2024-01-08 17:18 ` [virtio-dev] Re: [virtio-comment] " Mikhail Golubev-Ciuchea
@ 2024-02-13 14:57 ` Cornelia Huck
2024-02-16 11:08 ` Cornelia Huck
2 siblings, 0 replies; 15+ messages in thread
From: Cornelia Huck @ 2024-02-13 14:57 UTC (permalink / raw)
To: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can
Cc: Harald Mommer, Mikhail Golubev-Ciuchea
On Fri, Jun 09 2023, Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com> wrote:
> diff --git a/introduction.tex b/introduction.tex
> index b7155bf..d560c63 100644
> --- a/introduction.tex
> +++ b/introduction.tex
> @@ -101,6 +101,8 @@ \section{Normative References}\label{sec:Normative References}
> \phantomsection\label{intro:SEC1}\textbf{[SEC1]} &
> Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.
> \newline\url{https://www.secg.org/sec1-v2.pdf}\\
> + \phantomsection\label{intro:CAN}\textbf{[CAN]} &
> + ISO 11898-1:2015 Road vehicles -- Controller area network (CAN) -- Part 1: Data link layer and physical signalling\\
Just noticed while massaging this patch to apply on top of the 1.4
branch: This reference does not include an url; I guess
https://www.iso.org/standard/63648.html would be the place to point to?
(This can easily be added via an editorial update on top.)
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [virtio-dev] [RFC PATCH v3] virtio-can: Device specification.
2023-06-09 14:22 [virtio-dev] [RFC PATCH v3] virtio-can: Device specification Mikhail Golubev-Ciuchea
2024-01-08 17:18 ` [virtio-dev] Re: [virtio-comment] " Mikhail Golubev-Ciuchea
2024-02-13 14:57 ` [virtio-dev] " Cornelia Huck
@ 2024-02-16 11:08 ` Cornelia Huck
2 siblings, 0 replies; 15+ messages in thread
From: Cornelia Huck @ 2024-02-16 11:08 UTC (permalink / raw)
To: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can
Cc: Harald Mommer, Mikhail Golubev-Ciuchea
On Fri, Jun 09 2023, Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com> wrote:
> From: Harald Mommer <harald.mommer@opensynergy.com>
>
> virtio-can is a virtual CAN device. It provides a way to give access to
> a CAN controller from a driver guest. The device is aimed to be used by
> driver guests running a HLOS as well as by driver guests running a
> typical RTOS as used in controller environments.
>
> Signed-off-by: Harald Mommer <Harald.Mommer@opensynergy.com>
> Signed-off-by: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
(...)
> diff --git a/device-types/can/device-conformance.tex b/device-types/can/device-conformance.tex
> new file mode 100644
> index 0000000..f944ffd
> --- /dev/null
> +++ b/device-types/can/device-conformance.tex
> @@ -0,0 +1,8 @@
> +\conformance{\subsection}{CAN Device Conformance}\label{sec:Conformance / Device Conformance / CAN Device Conformance}
> +
> +A CAN device MUST conform to the following normative statements:
> +
> +\begin{itemize}
> +\item \ref{devicenormative:Device Types / CAN Device / Feature bits}
I just noticed that this introduces[1] an undefined reference (there's no
device normative section for feature bits.) I'd suggest to just drop
this reference (I can do that as a simple editorial update); if we want
to have an actual normative reference for feature bits, it should be
done via an extra change on top.
> +\item \ref{devicenormative:Device Types / CAN Device / Device Operation / CAN Message Transmission}
> +\end{itemize}
[1] Easy to miss, as the current 1.4 branch has a pre-existing undefined
reference, which will go away once we finally can merge into the main
branch again and have all that craziness go away after we manage to do
the actual 1.3 release :/
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-01-08 17:18 ` [virtio-dev] Re: [virtio-comment] " Mikhail Golubev-Ciuchea
2024-01-15 16:24 ` Cornelia Huck
@ 2024-02-20 12:19 ` Matias Ezequiel Vara Larsen
2024-02-21 15:42 ` Mikhail Golubev-Ciuchea
2024-02-21 10:37 ` Matias Ezequiel Vara Larsen
2 siblings, 1 reply; 15+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-02-20 12:19 UTC (permalink / raw)
To: Mikhail Golubev-Ciuchea
Cc: virtio-comment, virtio-dev, linux-can, Harald Mommer
Hello Mikail,
On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
> Hi all!
>
> I kindly request a vote.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
>
>
> Best wishes,
> Mikhail Golubev-Ciuchea
>
>
>
> On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
> > From: Harald Mommer <harald.mommer@opensynergy.com>
> >
> > virtio-can is a virtual CAN device. It provides a way to give access to
> > a CAN controller from a driver guest. The device is aimed to be used by
> > driver guests running a HLOS as well as by driver guests running a
> > typical RTOS as used in controller environments.
> >
> > Signed-off-by: Harald Mommer <Harald.Mommer@opensynergy.com>
> > Signed-off-by: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
> > ---
> >
> > RFC v3:
> > * Add length fields in CAN RX and TX messages.
> > * Replace bus off indication queue with a config space bit.
> > * Clarify handling of unknown flag bits set in CAN frame.
> > * Remove MISRA C suffixes in constants.
> > * Reserve 16 bits in RX/TX messages for CAN XL priority.
> > * Reserve 8 bits in RX/TX messages for CAN classic DLC.
> > * Rework according to general virtio spec POV.
> > * Implementation:
> > driver: https://lore.kernel.org/all/20230607145613.133203-1-Mikhail.Golubev-Ciuchea@opensynergy.com/
> > QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
> >
> > RFC v2:
> > * Add CAN classic feature flag.
> > * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
> > * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
> > * Reserve 32 bits in RX/TX messages.
> > * Remove priorities of messages.
> >
> > conformance.tex | 12 +-
> > content.tex | 1 +
> > device-types/can/description.tex | 249 ++++++++++++++++++++++++
> > device-types/can/device-conformance.tex | 8 +
> > device-types/can/driver-conformance.tex | 7 +
> > introduction.tex | 2 +
> > 6 files changed, 275 insertions(+), 4 deletions(-)
> > create mode 100644 device-types/can/description.tex
> > create mode 100644 device-types/can/device-conformance.tex
> > create mode 100644 device-types/can/driver-conformance.tex
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 01ccd69..a07ef02 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
> > \ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
> > \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
> > -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
> > -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
> > +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
> > +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
> > +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \ref{sec:Conformance / Device Conformance / Memory Device Conformance},
> > \ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
> > \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
> > -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
> > -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
> > +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
> > +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
> > +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \input{device-types/scmi/driver-conformance.tex}
> > \input{device-types/gpio/driver-conformance.tex}
> > \input{device-types/pmem/driver-conformance.tex}
> > +\input{device-types/can/driver-conformance.tex}
> > \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
> > @@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \input{device-types/scmi/device-conformance.tex}
> > \input{device-types/gpio/device-conformance.tex}
> > \input{device-types/pmem/device-conformance.tex}
> > +\input{device-types/can/device-conformance.tex}
> > \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
> > A conformant implementation MUST be either transitional or
> > diff --git a/content.tex b/content.tex
> > index d2ab9eb..8806b57 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
> > \input{device-types/scmi/description.tex}
> > \input{device-types/gpio/description.tex}
> > \input{device-types/pmem/description.tex}
> > +\input{device-types/can/description.tex}
> > \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> > diff --git a/device-types/can/description.tex b/device-types/can/description.tex
> > new file mode 100644
> > index 0000000..2511d9c
> > --- /dev/null
> > +++ b/device-types/can/description.tex
> > @@ -0,0 +1,249 @@
> > +\section{CAN Device}\label{sec:Device Types / CAN Device}
> > +
> > +virtio-can is a virtio based CAN (Controller Area Network) controller.
> > +It is used to give a virtual machine access to a CAN bus. The CAN bus
> > +might either be a physical CAN bus or a virtual CAN bus between virtual
> > +machines or a combination of both.
> > +
> > +\subsection{Device ID}\label{sec:Device Types / CAN Device / Device ID}
> > +
> > +36
> > +
> > +\subsection{Virtqueues}\label{sec:Device Types / CAN Device / Virtqueues}
> > +
> > +\begin{description}
> > +\item[0] Txq
> > +\item[1] Rxq
> > +\item[2] Controlq
> > +\end{description}
> > +
> > +The \field{Txq} is used to send CAN packets to the CAN bus.
> > +
> > +The \field{Rxq} is used to receive CAN packets from the CAN bus.
> > +
> > +The \field{Controlq} is used to control the state of the CAN controller.
> > +
> > +\subsection{Feature bits}{Device Types / CAN Device / Feature bits}
> > +
> > +Actual CAN controllers support Extended CAN IDs with 29 bits (CAN~2.0B)
> > +as well as Standard CAN IDs with 11 bits (CAN~2.0A). The support of
> > +CAN~2.0B Extended CAN IDs is considered as mandatory for this
> > +specification.
> > +
> > +\begin{description}
> > +
> > +\item[VIRTIO_CAN_F_CAN_CLASSIC (0)]
> > +
> > +The device supports classic CAN frames with a maximum payload size of 8
> > +bytes.
> > +
> > +\item[VIRTIO_CAN_F_CAN_FD (1)]
> > +
> > +The device supports CAN FD frames with a maximum payload size of 64
> > +bytes.
> > +
> > +\item[VIRTIO_CAN_F_RTR_FRAMES (2)]
> > +
> > +The device supports RTR (remote transmission request) frames. RTR frames
> > +are only supported with classic CAN.
> > +
> > +\item[VIRTIO_CAN_F_LATE_TX_ACK (3)]
> > +
> > +The virtio CAN device marks transmission requests from the \field{Txq}
> > +as used after the CAN message has been transmitted on the CAN bus. If
> > +this feature bit has not been negotiated, the device is allowed to mark
> > +transmission requests already as used when the CAN message has been
> > +scheduled for transmission but might not yet have been transmitted on
> > +the CAN bus.
> > +
> > +\end{description}
> > +
> > +\subsubsection{Feature bit requirements}\label{sec:Device Types / CAN Device / Feature bits / Feature bit requirements}
> > +
> > +Some CAN feature bits require other CAN feature bits:
> > +\begin{description}
> > +\item[VIRTIO_CAN_F_RTR_FRAMES] Requires VIRTIO_CAN_F_CAN_CLASSIC.
> > +\end{description}
> > +
> > +It is required that at least one of VIRTIO_CAN_F_CAN_CLASSIC and
> > +VIRTIO_CAN_F_CAN_FD is negotiated.
> > +
> > +\subsection{Device configuration layout}\label{sec:Device Types / CAN Device / Device configuration layout}
> > +
> > +Device configuration fields are listed below, they are read-only for a
> > +driver. The \field{status} always exists. A single read-only bit (for
> > +the driver) is currently defined for \field{status}:
> > +
> > +\begin{lstlisting}
> > +struct virtio_can_config {
> > +#define VIRTIO_CAN_S_CTRL_BUSOFF (1 << 0)
> > + le16 status;
> > +};
> > +\end{lstlisting}
> > +
> > +The bit VIRTIO_CAN_S_CTRL_BUSOFF in \field{status} is used to indicate
> > +the unsolicited CAN controller state change from started to stopped due
> > +to a detected bus off condition.
> > +
> > +\drivernormative{\subsubsection}{Device Initialization}{Device Types / CAN Device / Device Operation / Initialization}
> > +
> > +The driver MUST populate the \field{Rxq} with empty device-writeable
> > +buffers of at least the size of struct virtio_can_rx, see section
> > +\ref{struct virtio_can_rx}.
> > +
> > +\subsection{Device Operation}\label{sec:Device Types / CAN Device / Device Operation}
> > +
> > +A device operation has an outcome which is described by one of the
> > +following values:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CAN_RESULT_OK 0
> > +#define VIRTIO_CAN_RESULT_NOT_OK 1
> > +\end{lstlisting}
> > +
> > +Other values are to be treated like VIRTIO_CAN_RESULT_NOT_OK.
> > +
> > +\subsubsection{Controller Mode}\label{sec:Device Types / CAN Device / Device Operation / Controller Mode}
> > +
> > +The general format of a request in the \field{Controlq} is
> > +
> > +\begin{lstlisting}
> > +struct virtio_can_control_out {
> > +#define VIRTIO_CAN_SET_CTRL_MODE_START 0x0201
> > +#define VIRTIO_CAN_SET_CTRL_MODE_STOP 0x0202
> > + le16 msg_type;
> > +};
> > +\end{lstlisting}
> > +
> > +To participate in bus communication the CAN controller is started by
> > +sending a VIRTIO_CAN_SET_CTRL_MODE_START control message, to stop
> > +participating in bus communication it is stopped by sending a
> > +VIRTIO_CAN_SET_CTRL_MODE_STOP control message. Both requests are
> > +confirmed by the result of the operation.
> > +
> > +\begin{lstlisting}
> > +struct virtio_can_control_in {
> > + u8 result;
> > +};
> > +\end{lstlisting}
> > +
> > +If the transition succeeded the \field{result} is VIRTIO_CAN_RESULT_OK
> > +otherwise it is VIRTIO_CAN_RESULT_NOT_OK. If a status update is
> > +necessary, the device updates the configuration \field{status} before
> > +marking the request used. As the configuration \field{status} change is
> > +caused by a request from the driver the device is allowed to omit the
Is this to indicate that when a driver requests a change, the device can
omit notifying of the change? As I understand the specification, the
device can omit the notification, but the change must still occur? Is it
possible for the device to omit the change as well? What else could have
triggered the status change if it wasn't the driver?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-01-08 17:18 ` [virtio-dev] Re: [virtio-comment] " Mikhail Golubev-Ciuchea
2024-01-15 16:24 ` Cornelia Huck
2024-02-20 12:19 ` Matias Ezequiel Vara Larsen
@ 2024-02-21 10:37 ` Matias Ezequiel Vara Larsen
2024-02-21 12:49 ` Marc Kleine-Budde
2 siblings, 1 reply; 15+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-02-21 10:37 UTC (permalink / raw)
To: Mikhail Golubev-Ciuchea
Cc: virtio-comment, virtio-dev, linux-can, Harald Mommer
On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
> Hi all!
>
> I kindly request a vote.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
>
>
> Best wishes,
> Mikhail Golubev-Ciuchea
>
>
>
> On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
> > From: Harald Mommer <harald.mommer@opensynergy.com>
> >
> > virtio-can is a virtual CAN device. It provides a way to give access to
> > a CAN controller from a driver guest. The device is aimed to be used by
> > driver guests running a HLOS as well as by driver guests running a
> > typical RTOS as used in controller environments.
> >
> > Signed-off-by: Harald Mommer <Harald.Mommer@opensynergy.com>
> > Signed-off-by: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
> > ---
> >
> > RFC v3:
> > * Add length fields in CAN RX and TX messages.
> > * Replace bus off indication queue with a config space bit.
> > * Clarify handling of unknown flag bits set in CAN frame.
> > * Remove MISRA C suffixes in constants.
> > * Reserve 16 bits in RX/TX messages for CAN XL priority.
> > * Reserve 8 bits in RX/TX messages for CAN classic DLC.
> > * Rework according to general virtio spec POV.
> > * Implementation:
> > driver: https://lore.kernel.org/all/20230607145613.133203-1-Mikhail.Golubev-Ciuchea@opensynergy.com/
> > QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
> >
> > RFC v2:
> > * Add CAN classic feature flag.
> > * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
> > * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
> > * Reserve 32 bits in RX/TX messages.
> > * Remove priorities of messages.
> >
> > conformance.tex | 12 +-
> > content.tex | 1 +
> > device-types/can/description.tex | 249 ++++++++++++++++++++++++
> > device-types/can/device-conformance.tex | 8 +
> > device-types/can/driver-conformance.tex | 7 +
> > introduction.tex | 2 +
> > 6 files changed, 275 insertions(+), 4 deletions(-)
> > create mode 100644 device-types/can/description.tex
> > create mode 100644 device-types/can/device-conformance.tex
> > create mode 100644 device-types/can/driver-conformance.tex
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 01ccd69..a07ef02 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
> > \ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
> > \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
> > -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
> > -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
> > +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
> > +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
> > +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \ref{sec:Conformance / Device Conformance / Memory Device Conformance},
> > \ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
> > \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
> > -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
> > -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
> > +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
> > +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
> > +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
> > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> > \end{itemize}
> > @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \input{device-types/scmi/driver-conformance.tex}
> > \input{device-types/gpio/driver-conformance.tex}
> > \input{device-types/pmem/driver-conformance.tex}
> > +\input{device-types/can/driver-conformance.tex}
> > \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
> > @@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > \input{device-types/scmi/device-conformance.tex}
> > \input{device-types/gpio/device-conformance.tex}
> > \input{device-types/pmem/device-conformance.tex}
> > +\input{device-types/can/device-conformance.tex}
> > \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
> > A conformant implementation MUST be either transitional or
> > diff --git a/content.tex b/content.tex
> > index d2ab9eb..8806b57 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
> > \input{device-types/scmi/description.tex}
> > \input{device-types/gpio/description.tex}
> > \input{device-types/pmem/description.tex}
> > +\input{device-types/can/description.tex}
> > \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> > diff --git a/device-types/can/description.tex b/device-types/can/description.tex
> > new file mode 100644
> > index 0000000..2511d9c
> > --- /dev/null
> > +++ b/device-types/can/description.tex
> > @@ -0,0 +1,249 @@
> > +\section{CAN Device}\label{sec:Device Types / CAN Device}
> > +
> > +virtio-can is a virtio based CAN (Controller Area Network) controller.
> > +It is used to give a virtual machine access to a CAN bus. The CAN bus
> > +might either be a physical CAN bus or a virtual CAN bus between virtual
> > +machines or a combination of both.
> > +
> > +\subsection{Device ID}\label{sec:Device Types / CAN Device / Device ID}
> > +
> > +36
> > +
> > +\subsection{Virtqueues}\label{sec:Device Types / CAN Device / Virtqueues}
> > +
> > +\begin{description}
> > +\item[0] Txq
> > +\item[1] Rxq
> > +\item[2] Controlq
> > +\end{description}
> > +
> > +The \field{Txq} is used to send CAN packets to the CAN bus.
> > +
> > +The \field{Rxq} is used to receive CAN packets from the CAN bus.
> > +
> > +The \field{Controlq} is used to control the state of the CAN controller.
> > +
> > +\subsection{Feature bits}{Device Types / CAN Device / Feature bits}
> > +
> > +Actual CAN controllers support Extended CAN IDs with 29 bits (CAN~2.0B)
> > +as well as Standard CAN IDs with 11 bits (CAN~2.0A). The support of
> > +CAN~2.0B Extended CAN IDs is considered as mandatory for this
> > +specification.
> > +
> > +\begin{description}
> > +
> > +\item[VIRTIO_CAN_F_CAN_CLASSIC (0)]
> > +
> > +The device supports classic CAN frames with a maximum payload size of 8
> > +bytes.
> > +
> > +\item[VIRTIO_CAN_F_CAN_FD (1)]
> > +
> > +The device supports CAN FD frames with a maximum payload size of 64
> > +bytes.
> > +
> > +\item[VIRTIO_CAN_F_RTR_FRAMES (2)]
> > +
> > +The device supports RTR (remote transmission request) frames. RTR frames
> > +are only supported with classic CAN.
> > +
> > +\item[VIRTIO_CAN_F_LATE_TX_ACK (3)]
> > +
> > +The virtio CAN device marks transmission requests from the \field{Txq}
> > +as used after the CAN message has been transmitted on the CAN bus. If
> > +this feature bit has not been negotiated, the device is allowed to mark
> > +transmission requests already as used when the CAN message has been
> > +scheduled for transmission but might not yet have been transmitted on
> > +the CAN bus.
> > +
> > +\end{description}
> > +
> > +\subsubsection{Feature bit requirements}\label{sec:Device Types / CAN Device / Feature bits / Feature bit requirements}
> > +
> > +Some CAN feature bits require other CAN feature bits:
> > +\begin{description}
> > +\item[VIRTIO_CAN_F_RTR_FRAMES] Requires VIRTIO_CAN_F_CAN_CLASSIC.
> > +\end{description}
> > +
> > +It is required that at least one of VIRTIO_CAN_F_CAN_CLASSIC and
> > +VIRTIO_CAN_F_CAN_FD is negotiated.
> > +
> > +\subsection{Device configuration layout}\label{sec:Device Types / CAN Device / Device configuration layout}
> > +
> > +Device configuration fields are listed below, they are read-only for a
> > +driver. The \field{status} always exists. A single read-only bit (for
> > +the driver) is currently defined for \field{status}:
> > +
> > +\begin{lstlisting}
> > +struct virtio_can_config {
> > +#define VIRTIO_CAN_S_CTRL_BUSOFF (1 << 0)
> > + le16 status;
> > +};
> > +\end{lstlisting}
> > +
> > +The bit VIRTIO_CAN_S_CTRL_BUSOFF in \field{status} is used to indicate
> > +the unsolicited CAN controller state change from started to stopped due
> > +to a detected bus off condition.
> > +
> > +\drivernormative{\subsubsection}{Device Initialization}{Device Types / CAN Device / Device Operation / Initialization}
> > +
> > +The driver MUST populate the \field{Rxq} with empty device-writeable
> > +buffers of at least the size of struct virtio_can_rx, see section
> > +\ref{struct virtio_can_rx}.
> > +
> > +\subsection{Device Operation}\label{sec:Device Types / CAN Device / Device Operation}
> > +
> > +A device operation has an outcome which is described by one of the
> > +following values:
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_CAN_RESULT_OK 0
> > +#define VIRTIO_CAN_RESULT_NOT_OK 1
> > +\end{lstlisting}
> > +
> > +Other values are to be treated like VIRTIO_CAN_RESULT_NOT_OK.
> > +
> > +\subsubsection{Controller Mode}\label{sec:Device Types / CAN Device / Device Operation / Controller Mode}
> > +
> > +The general format of a request in the \field{Controlq} is
> > +
> > +\begin{lstlisting}
> > +struct virtio_can_control_out {
> > +#define VIRTIO_CAN_SET_CTRL_MODE_START 0x0201
> > +#define VIRTIO_CAN_SET_CTRL_MODE_STOP 0x0202
> > + le16 msg_type;
> > +};
> > +\end{lstlisting}
> > +
> > +To participate in bus communication the CAN controller is started by
> > +sending a VIRTIO_CAN_SET_CTRL_MODE_START control message, to stop
> > +participating in bus communication it is stopped by sending a
> > +VIRTIO_CAN_SET_CTRL_MODE_STOP control message. Both requests are
> > +confirmed by the result of the operation.
> > +
> > +\begin{lstlisting}
> > +struct virtio_can_control_in {
> > + u8 result;
> > +};
> > +\end{lstlisting}
> > +
> > +If the transition succeeded the \field{result} is VIRTIO_CAN_RESULT_OK
> > +otherwise it is VIRTIO_CAN_RESULT_NOT_OK. If a status update is
> > +necessary, the device updates the configuration \field{status} before
> > +marking the request used. As the configuration \field{status} change is
> > +caused by a request from the driver the device is allowed to omit the
> > +configuration change notification here. The device marks the request
> > +used when the CAN controller has finalized the transition to the
> > +requested controller mode.
> > +
> > +On transition to the STOPPED state the device cancels all CAN messages
> > +already pending for transmission and marks them as used with
> > +\field{result} VIRTIO_CAN_RESULT_NOT_OK. In the STOPPED state the
> > +device marks messages received from the
> > +\field{Txq} as used with \field{result} VIRTIO_CAN_RESULT_NOT_OK without
> > +transmitting them to the CAN bus.
> > +
> > +Initially the CAN controller is in the STOPPED state.
> > +
> > +Control queue messages are processed in order.
> > +
> > +\devicenormative{\subsubsection}{CAN Message Transmission}{Device Types / CAN Device / Device Operation / CAN Message Transmission}
> > +
> > +The driver transmits messages by placing outgoing CAN messages in the
> > +\field{Txq} virtqueue.
> > +
> > +\label{struct virtio_can_tx_out}
> > +\begin{lstlisting}
> > +struct virtio_can_tx_out {
> > +#define VIRTIO_CAN_TX 0x0001
> > + le16 msg_type;
> > + le16 length; /* 0..8 CC, 0..64 CAN-FD, 0..2048 CAN-XL, 12 bits */
> > + u8 reserved_classic_dlc; /* If CAN classic length = 8 then DLC can be 8..15 */
> > + u8 padding;
> > + le16 reserved_xl_priority; /* May be needed for CAN XL priority */
> > +#define VIRTIO_CAN_FLAGS_FD 0x4000
> > +#define VIRTIO_CAN_FLAGS_EXTENDED 0x8000
> > +#define VIRTIO_CAN_FLAGS_RTR 0x2000
> > + le32 flags;
> > + le32 can_id;
> > + u8 sdu[];
> > +};
> > +
> > +struct virtio_can_tx_in {
> > + u8 result;
> > +};
> > +\end{lstlisting}
> > +
> > +The length of the \field{sdu} is determined by the \field{length}.
> > +
> > +The type of a CAN message identifier is determined by \field{flags}. The
> > +3 most significant bits of \field{can_id} do not bear the information
> > +about the type of the CAN message identifier and are 0.
> > +
> > +The device MUST reject any CAN frame type for which support has not been
> > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> > +schedule the message for transmission. A CAN frame with an undefined bit
> > +set in \field{flags} is treated like a CAN frame for which support has
> > +not been negotiated.
> > +
> > +The device MUST reject any CAN frame for which \field{can_id} or
> > +\field{sdu} length are out of range or the CAN controller is in an
> > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> > +NOT schedule the message for transmission.
> > +
I am not very familiar with CAN but how does the device figure out that
the can_id is out of range?
Thanks, Matias.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-02-21 10:37 ` Matias Ezequiel Vara Larsen
@ 2024-02-21 12:49 ` Marc Kleine-Budde
2024-02-21 13:16 ` Matias Ezequiel Vara Larsen
0 siblings, 1 reply; 15+ messages in thread
From: Marc Kleine-Budde @ 2024-02-21 12:49 UTC (permalink / raw)
To: Matias Ezequiel Vara Larsen
Cc: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can,
Harald Mommer
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
> > > +The length of the \field{sdu} is determined by the \field{length}.
> > > +
> > > +The type of a CAN message identifier is determined by \field{flags}. The
> > > +3 most significant bits of \field{can_id} do not bear the information
> > > +about the type of the CAN message identifier and are 0.
> > > +
> > > +The device MUST reject any CAN frame type for which support has not been
> > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> > > +schedule the message for transmission. A CAN frame with an undefined bit
> > > +set in \field{flags} is treated like a CAN frame for which support has
> > > +not been negotiated.
> > > +
> > > +The device MUST reject any CAN frame for which \field{can_id} or
> > > +\field{sdu} length are out of range or the CAN controller is in an
> > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> > > +NOT schedule the message for transmission.
> > > +
> I am not very familiar with CAN but how does the device figure out that
> the can_id is out of range?
In classical CAN we have the standard CAN frames, which have an 11 bit
ID, and there are extended CAN frames, which have 29 bits ID. Extended
frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
out of range.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-02-21 12:49 ` Marc Kleine-Budde
@ 2024-02-21 13:16 ` Matias Ezequiel Vara Larsen
2024-02-21 13:28 ` Marc Kleine-Budde
0 siblings, 1 reply; 15+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-02-21 13:16 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can,
Harald Mommer
On Wed, Feb 21, 2024 at 01:49:31PM +0100, Marc Kleine-Budde wrote:
> On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
> > > > +The length of the \field{sdu} is determined by the \field{length}.
> > > > +
> > > > +The type of a CAN message identifier is determined by \field{flags}. The
> > > > +3 most significant bits of \field{can_id} do not bear the information
> > > > +about the type of the CAN message identifier and are 0.
> > > > +
> > > > +The device MUST reject any CAN frame type for which support has not been
> > > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> > > > +schedule the message for transmission. A CAN frame with an undefined bit
> > > > +set in \field{flags} is treated like a CAN frame for which support has
> > > > +not been negotiated.
> > > > +
> > > > +The device MUST reject any CAN frame for which \field{can_id} or
> > > > +\field{sdu} length are out of range or the CAN controller is in an
> > > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> > > > +NOT schedule the message for transmission.
> > > > +
> > I am not very familiar with CAN but how does the device figure out that
> > the can_id is out of range?
>
> In classical CAN we have the standard CAN frames, which have an 11 bit
> ID, and there are extended CAN frames, which have 29 bits ID. Extended
> frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
>
> So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
> out of range.
>
Thanks Marc for the explanation. Do you think that it would be
worthwhile to add that to the spec at some point?
Matias.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-02-21 13:16 ` Matias Ezequiel Vara Larsen
@ 2024-02-21 13:28 ` Marc Kleine-Budde
2024-02-26 12:36 ` Cornelia Huck
0 siblings, 1 reply; 15+ messages in thread
From: Marc Kleine-Budde @ 2024-02-21 13:28 UTC (permalink / raw)
To: Matias Ezequiel Vara Larsen
Cc: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can,
Harald Mommer
[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]
On 21.02.2024 14:16:54, Matias Ezequiel Vara Larsen wrote:
> On Wed, Feb 21, 2024 at 01:49:31PM +0100, Marc Kleine-Budde wrote:
> > On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
> > > > > +The length of the \field{sdu} is determined by the \field{length}.
> > > > > +
> > > > > +The type of a CAN message identifier is determined by \field{flags}. The
> > > > > +3 most significant bits of \field{can_id} do not bear the information
> > > > > +about the type of the CAN message identifier and are 0.
> > > > > +
> > > > > +The device MUST reject any CAN frame type for which support has not been
> > > > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> > > > > +schedule the message for transmission. A CAN frame with an undefined bit
> > > > > +set in \field{flags} is treated like a CAN frame for which support has
> > > > > +not been negotiated.
> > > > > +
> > > > > +The device MUST reject any CAN frame for which \field{can_id} or
> > > > > +\field{sdu} length are out of range or the CAN controller is in an
> > > > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> > > > > +NOT schedule the message for transmission.
> > > > > +
> > > I am not very familiar with CAN but how does the device figure out that
> > > the can_id is out of range?
> >
> > In classical CAN we have the standard CAN frames, which have an 11 bit
> > ID, and there are extended CAN frames, which have 29 bits ID. Extended
> > frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
> >
> > So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
> > out of range.
Another option would be an extended frame (VIRTIO_CAN_FLAGS_EXTENDED
set) and using more than 29 bits.
> Thanks Marc for the explanation. Do you think that it would be
> worthwhile to add that to the spec at some point?
Yes that makes sense as it clarifies what's meant by out of range for
CAN-IDs, for the valid length a reference to
\item[VIRTIO_CAN_F_CAN_CLASSIC (0)] and \item[VIRTIO_CAN_F_CAN_FD (1)]
might be added.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-02-20 12:19 ` Matias Ezequiel Vara Larsen
@ 2024-02-21 15:42 ` Mikhail Golubev-Ciuchea
2024-02-22 11:30 ` Matias Ezequiel Vara Larsen
0 siblings, 1 reply; 15+ messages in thread
From: Mikhail Golubev-Ciuchea @ 2024-02-21 15:42 UTC (permalink / raw)
To: Matias Ezequiel Vara Larsen
Cc: virtio-comment, virtio-dev, linux-can, Harald Mommer
Hi Matias,
On 2/20/24 13:19, Matias Ezequiel Vara Larsen wrote:
> Hello Mikail,
>
> On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
>> Hi all!
>>
>> I kindly request a vote.
>>
>> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
>>
>>
>> Best wishes,
>> Mikhail Golubev-Ciuchea
>>
>>
>>
>> On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
>>> From: Harald Mommer <harald.mommer@opensynergy.com>
>>>
>>> virtio-can is a virtual CAN device. It provides a way to give access to
>>> a CAN controller from a driver guest. The device is aimed to be used by
>>> driver guests running a HLOS as well as by driver guests running a
>>> typical RTOS as used in controller environments.
>>>
>>> Signed-off-by: Harald Mommer <Harald.Mommer@opensynergy.com>
>>> Signed-off-by: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
>>> ---
>>>
>>> RFC v3:
>>> * Add length fields in CAN RX and TX messages.
>>> * Replace bus off indication queue with a config space bit.
>>> * Clarify handling of unknown flag bits set in CAN frame.
>>> * Remove MISRA C suffixes in constants.
>>> * Reserve 16 bits in RX/TX messages for CAN XL priority.
>>> * Reserve 8 bits in RX/TX messages for CAN classic DLC.
>>> * Rework according to general virtio spec POV.
>>> * Implementation:
>>> driver: https://lore.kernel.org/all/20230607145613.133203-1-Mikhail.Golubev-Ciuchea@opensynergy.com/
>>> QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
>>>
>>> RFC v2:
>>> * Add CAN classic feature flag.
>>> * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
>>> * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
>>> * Reserve 32 bits in RX/TX messages.
>>> * Remove priorities of messages.
>>>
>>> conformance.tex | 12 +-
>>> content.tex | 1 +
>>> device-types/can/description.tex | 249 ++++++++++++++++++++++++
>>> device-types/can/device-conformance.tex | 8 +
>>> device-types/can/driver-conformance.tex | 7 +
>>> introduction.tex | 2 +
>>> 6 files changed, 275 insertions(+), 4 deletions(-)
>>> create mode 100644 device-types/can/description.tex
>>> create mode 100644 device-types/can/device-conformance.tex
>>> create mode 100644 device-types/can/driver-conformance.tex
>>>
>>> diff --git a/conformance.tex b/conformance.tex
>>> index 01ccd69..a07ef02 100644
>>> --- a/conformance.tex
>>> +++ b/conformance.tex
>>> @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>>> \ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
>>> \ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
>>> \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
>>> -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
>>> -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
>>> +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
>>> +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
>>> +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
>>> \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
>>> \end{itemize}
>>> @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>>> \ref{sec:Conformance / Device Conformance / Memory Device Conformance},
>>> \ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
>>> \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
>>> -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
>>> -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
>>> +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
>>> +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
>>> +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
>>> \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
>>> \end{itemize}
>>> @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>>> \input{device-types/scmi/driver-conformance.tex}
>>> \input{device-types/gpio/driver-conformance.tex}
>>> \input{device-types/pmem/driver-conformance.tex}
>>> +\input{device-types/can/driver-conformance.tex}
>>> \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
>>> @@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>>> \input{device-types/scmi/device-conformance.tex}
>>> \input{device-types/gpio/device-conformance.tex}
>>> \input{device-types/pmem/device-conformance.tex}
>>> +\input{device-types/can/device-conformance.tex}
>>> \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
>>> A conformant implementation MUST be either transitional or
>>> diff --git a/content.tex b/content.tex
>>> index d2ab9eb..8806b57 100644
>>> --- a/content.tex
>>> +++ b/content.tex
>>> @@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
>>> \input{device-types/scmi/description.tex}
>>> \input{device-types/gpio/description.tex}
>>> \input{device-types/pmem/description.tex}
>>> +\input{device-types/can/description.tex}
>>> \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
>>> diff --git a/device-types/can/description.tex b/device-types/can/description.tex
>>> new file mode 100644
>>> index 0000000..2511d9c
>>> --- /dev/null
>>> +++ b/device-types/can/description.tex
>>> @@ -0,0 +1,249 @@
>>> +\section{CAN Device}\label{sec:Device Types / CAN Device}
>>> +
>>> +virtio-can is a virtio based CAN (Controller Area Network) controller.
>>> +It is used to give a virtual machine access to a CAN bus. The CAN bus
>>> +might either be a physical CAN bus or a virtual CAN bus between virtual
>>> +machines or a combination of both.
>>> +
>>> +\subsection{Device ID}\label{sec:Device Types / CAN Device / Device ID}
>>> +
>>> +36
>>> +
>>> +\subsection{Virtqueues}\label{sec:Device Types / CAN Device / Virtqueues}
>>> +
>>> +\begin{description}
>>> +\item[0] Txq
>>> +\item[1] Rxq
>>> +\item[2] Controlq
>>> +\end{description}
>>> +
>>> +The \field{Txq} is used to send CAN packets to the CAN bus.
>>> +
>>> +The \field{Rxq} is used to receive CAN packets from the CAN bus.
>>> +
>>> +The \field{Controlq} is used to control the state of the CAN controller.
>>> +
>>> +\subsection{Feature bits}{Device Types / CAN Device / Feature bits}
>>> +
>>> +Actual CAN controllers support Extended CAN IDs with 29 bits (CAN~2.0B)
>>> +as well as Standard CAN IDs with 11 bits (CAN~2.0A). The support of
>>> +CAN~2.0B Extended CAN IDs is considered as mandatory for this
>>> +specification.
>>> +
>>> +\begin{description}
>>> +
>>> +\item[VIRTIO_CAN_F_CAN_CLASSIC (0)]
>>> +
>>> +The device supports classic CAN frames with a maximum payload size of 8
>>> +bytes.
>>> +
>>> +\item[VIRTIO_CAN_F_CAN_FD (1)]
>>> +
>>> +The device supports CAN FD frames with a maximum payload size of 64
>>> +bytes.
>>> +
>>> +\item[VIRTIO_CAN_F_RTR_FRAMES (2)]
>>> +
>>> +The device supports RTR (remote transmission request) frames. RTR frames
>>> +are only supported with classic CAN.
>>> +
>>> +\item[VIRTIO_CAN_F_LATE_TX_ACK (3)]
>>> +
>>> +The virtio CAN device marks transmission requests from the \field{Txq}
>>> +as used after the CAN message has been transmitted on the CAN bus. If
>>> +this feature bit has not been negotiated, the device is allowed to mark
>>> +transmission requests already as used when the CAN message has been
>>> +scheduled for transmission but might not yet have been transmitted on
>>> +the CAN bus.
>>> +
>>> +\end{description}
>>> +
>>> +\subsubsection{Feature bit requirements}\label{sec:Device Types / CAN Device / Feature bits / Feature bit requirements}
>>> +
>>> +Some CAN feature bits require other CAN feature bits:
>>> +\begin{description}
>>> +\item[VIRTIO_CAN_F_RTR_FRAMES] Requires VIRTIO_CAN_F_CAN_CLASSIC.
>>> +\end{description}
>>> +
>>> +It is required that at least one of VIRTIO_CAN_F_CAN_CLASSIC and
>>> +VIRTIO_CAN_F_CAN_FD is negotiated.
>>> +
>>> +\subsection{Device configuration layout}\label{sec:Device Types / CAN Device / Device configuration layout}
>>> +
>>> +Device configuration fields are listed below, they are read-only for a
>>> +driver. The \field{status} always exists. A single read-only bit (for
>>> +the driver) is currently defined for \field{status}:
>>> +
>>> +\begin{lstlisting}
>>> +struct virtio_can_config {
>>> +#define VIRTIO_CAN_S_CTRL_BUSOFF (1 << 0)
>>> + le16 status;
>>> +};
>>> +\end{lstlisting}
>>> +
>>> +The bit VIRTIO_CAN_S_CTRL_BUSOFF in \field{status} is used to indicate
>>> +the unsolicited CAN controller state change from started to stopped due
>>> +to a detected bus off condition.
>>> +
>>> +\drivernormative{\subsubsection}{Device Initialization}{Device Types / CAN Device / Device Operation / Initialization}
>>> +
>>> +The driver MUST populate the \field{Rxq} with empty device-writeable
>>> +buffers of at least the size of struct virtio_can_rx, see section
>>> +\ref{struct virtio_can_rx}.
>>> +
>>> +\subsection{Device Operation}\label{sec:Device Types / CAN Device / Device Operation}
>>> +
>>> +A device operation has an outcome which is described by one of the
>>> +following values:
>>> +
>>> +\begin{lstlisting}
>>> +#define VIRTIO_CAN_RESULT_OK 0
>>> +#define VIRTIO_CAN_RESULT_NOT_OK 1
>>> +\end{lstlisting}
>>> +
>>> +Other values are to be treated like VIRTIO_CAN_RESULT_NOT_OK.
>>> +
>>> +\subsubsection{Controller Mode}\label{sec:Device Types / CAN Device / Device Operation / Controller Mode}
>>> +
>>> +The general format of a request in the \field{Controlq} is
>>> +
>>> +\begin{lstlisting}
>>> +struct virtio_can_control_out {
>>> +#define VIRTIO_CAN_SET_CTRL_MODE_START 0x0201
>>> +#define VIRTIO_CAN_SET_CTRL_MODE_STOP 0x0202
>>> + le16 msg_type;
>>> +};
>>> +\end{lstlisting}
>>> +
>>> +To participate in bus communication the CAN controller is started by
>>> +sending a VIRTIO_CAN_SET_CTRL_MODE_START control message, to stop
>>> +participating in bus communication it is stopped by sending a
>>> +VIRTIO_CAN_SET_CTRL_MODE_STOP control message. Both requests are
>>> +confirmed by the result of the operation.
>>> +
>>> +\begin{lstlisting}
>>> +struct virtio_can_control_in {
>>> + u8 result;
>>> +};
>>> +\end{lstlisting}
>>> +
>>> +If the transition succeeded the \field{result} is VIRTIO_CAN_RESULT_OK
>>> +otherwise it is VIRTIO_CAN_RESULT_NOT_OK. If a status update is
>>> +necessary, the device updates the configuration \field{status} before
>>> +marking the request used. As the configuration \field{status} change is
>>> +caused by a request from the driver the device is allowed to omit the
>
> Is this to indicate that when a driver requests a change, the device can
> omit notifying of the change? As I understand the specification, the
> device can omit the notification, but the change must still occur? Is it
> possible for the device to omit the change as well? What else could have
> triggered the status change if it wasn't the driver?
>
> Thanks.
>
The change request notification OK/NOT_OK for every mode transition
request is there in any case. In some cases the device would
additionally notify the driver about the controller status via
'virtio_can_config' in config space (config space change notification
mechanism), e.g. in case of a BusOff event on the device side. Although,
it is possible to omit the config space notification e.g. when
transitioning to stopped mode.
In the previous draft version of the spec a separate asynchronous queue
was used to send BusOff events and the proposal had an issue with races:
it was not possible to distinguish whether a received BusOff event was
meant to be from an old session or is already from the new session.
Hence, the indication queue was removed and a config space status was
added instead.
Best regard,
Mikhail
--
Mikhail Golubev-Ciuchea
OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
Telefon: +49 (30) 60985400
EMail:
mikhail.golubev-ciuchea@opensynergy.com<mailto:mikhail.golubev-ciuchea@opensynergy.com>
www.opensynergy.com
Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Regis Adjamah
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-02-21 15:42 ` Mikhail Golubev-Ciuchea
@ 2024-02-22 11:30 ` Matias Ezequiel Vara Larsen
0 siblings, 0 replies; 15+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-02-22 11:30 UTC (permalink / raw)
To: Mikhail Golubev-Ciuchea
Cc: virtio-comment, virtio-dev, linux-can, Harald Mommer
On Wed, Feb 21, 2024 at 04:42:18PM +0100, Mikhail Golubev-Ciuchea wrote:
> Hi Matias,
>
> On 2/20/24 13:19, Matias Ezequiel Vara Larsen wrote:
> > Hello Mikail,
> >
> > On Mon, Jan 08, 2024 at 06:18:50PM +0100, Mikhail Golubev-Ciuchea wrote:
> > > Hi all!
> > >
> > > I kindly request a vote.
> > >
> > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/186
> > >
> > >
> > > Best wishes,
> > > Mikhail Golubev-Ciuchea
> > >
> > >
> > >
> > > On 6/9/23 16:22, Mikhail Golubev-Ciuchea wrote:
> > > > From: Harald Mommer <harald.mommer@opensynergy.com>
> > > >
> > > > virtio-can is a virtual CAN device. It provides a way to give access to
> > > > a CAN controller from a driver guest. The device is aimed to be used by
> > > > driver guests running a HLOS as well as by driver guests running a
> > > > typical RTOS as used in controller environments.
> > > >
> > > > Signed-off-by: Harald Mommer <Harald.Mommer@opensynergy.com>
> > > > Signed-off-by: Mikhail Golubev-Ciuchea <Mikhail.Golubev-Ciuchea@opensynergy.com>
> > > > ---
> > > >
> > > > RFC v3:
> > > > * Add length fields in CAN RX and TX messages.
> > > > * Replace bus off indication queue with a config space bit.
> > > > * Clarify handling of unknown flag bits set in CAN frame.
> > > > * Remove MISRA C suffixes in constants.
> > > > * Reserve 16 bits in RX/TX messages for CAN XL priority.
> > > > * Reserve 8 bits in RX/TX messages for CAN classic DLC.
> > > > * Rework according to general virtio spec POV.
> > > > * Implementation:
> > > > driver: https://lore.kernel.org/all/20230607145613.133203-1-Mikhail.Golubev-Ciuchea@opensynergy.com/
> > > > QEmu device: https://github.com/OpenSynergy/qemu/tree/virtio-can-spec-rfc-v3
> > > >
> > > > RFC v2:
> > > > * Add CAN classic feature flag.
> > > > * Add feature flag VIRTIO_CAN_F_LATE_TX_ACK.
> > > > * Add feature flag VIRTIO_CAN_F_RTR_FRAMES.
> > > > * Reserve 32 bits in RX/TX messages.
> > > > * Remove priorities of messages.
> > > >
> > > > conformance.tex | 12 +-
> > > > content.tex | 1 +
> > > > device-types/can/description.tex | 249 ++++++++++++++++++++++++
> > > > device-types/can/device-conformance.tex | 8 +
> > > > device-types/can/driver-conformance.tex | 7 +
> > > > introduction.tex | 2 +
> > > > 6 files changed, 275 insertions(+), 4 deletions(-)
> > > > create mode 100644 device-types/can/description.tex
> > > > create mode 100644 device-types/can/device-conformance.tex
> > > > create mode 100644 device-types/can/driver-conformance.tex
> > > >
> > > > diff --git a/conformance.tex b/conformance.tex
> > > > index 01ccd69..a07ef02 100644
> > > > --- a/conformance.tex
> > > > +++ b/conformance.tex
> > > > @@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > > > \ref{sec:Conformance / Driver Conformance / Memory Driver Conformance},
> > > > \ref{sec:Conformance / Driver Conformance / I2C Adapter Driver Conformance},
> > > > \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},
> > > > -\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or
> > > > -\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.
> > > > +\ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance},
> > > > +\ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance} or
> > > > +\ref{sec:Conformance / Driver Conformance / CAN Driver Conformance}.
> > > > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> > > > \end{itemize}
> > > > @@ -59,8 +60,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > > > \ref{sec:Conformance / Device Conformance / Memory Device Conformance},
> > > > \ref{sec:Conformance / Device Conformance / I2C Adapter Device Conformance},
> > > > \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},
> > > > -\ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or
> > > > -\ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.
> > > > +\ref{sec:Conformance / Device Conformance / GPIO Device Conformance},
> > > > +\ref{sec:Conformance / Device Conformance / PMEM Device Conformance} or
> > > > +\ref{sec:Conformance / Device Conformance / CAN Device Conformance}.
> > > > \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
> > > > \end{itemize}
> > > > @@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > > > \input{device-types/scmi/driver-conformance.tex}
> > > > \input{device-types/gpio/driver-conformance.tex}
> > > > \input{device-types/pmem/driver-conformance.tex}
> > > > +\input{device-types/can/driver-conformance.tex}
> > > > \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
> > > > @@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> > > > \input{device-types/scmi/device-conformance.tex}
> > > > \input{device-types/gpio/device-conformance.tex}
> > > > \input{device-types/pmem/device-conformance.tex}
> > > > +\input{device-types/can/device-conformance.tex}
> > > > \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
> > > > A conformant implementation MUST be either transitional or
> > > > diff --git a/content.tex b/content.tex
> > > > index d2ab9eb..8806b57 100644
> > > > --- a/content.tex
> > > > +++ b/content.tex
> > > > @@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}
> > > > \input{device-types/scmi/description.tex}
> > > > \input{device-types/gpio/description.tex}
> > > > \input{device-types/pmem/description.tex}
> > > > +\input{device-types/can/description.tex}
> > > > \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> > > > diff --git a/device-types/can/description.tex b/device-types/can/description.tex
> > > > new file mode 100644
> > > > index 0000000..2511d9c
> > > > --- /dev/null
> > > > +++ b/device-types/can/description.tex
> > > > @@ -0,0 +1,249 @@
> > > > +\section{CAN Device}\label{sec:Device Types / CAN Device}
> > > > +
> > > > +virtio-can is a virtio based CAN (Controller Area Network) controller.
> > > > +It is used to give a virtual machine access to a CAN bus. The CAN bus
> > > > +might either be a physical CAN bus or a virtual CAN bus between virtual
> > > > +machines or a combination of both.
> > > > +
> > > > +\subsection{Device ID}\label{sec:Device Types / CAN Device / Device ID}
> > > > +
> > > > +36
> > > > +
> > > > +\subsection{Virtqueues}\label{sec:Device Types / CAN Device / Virtqueues}
> > > > +
> > > > +\begin{description}
> > > > +\item[0] Txq
> > > > +\item[1] Rxq
> > > > +\item[2] Controlq
> > > > +\end{description}
> > > > +
> > > > +The \field{Txq} is used to send CAN packets to the CAN bus.
> > > > +
> > > > +The \field{Rxq} is used to receive CAN packets from the CAN bus.
> > > > +
> > > > +The \field{Controlq} is used to control the state of the CAN controller.
> > > > +
> > > > +\subsection{Feature bits}{Device Types / CAN Device / Feature bits}
> > > > +
> > > > +Actual CAN controllers support Extended CAN IDs with 29 bits (CAN~2.0B)
> > > > +as well as Standard CAN IDs with 11 bits (CAN~2.0A). The support of
> > > > +CAN~2.0B Extended CAN IDs is considered as mandatory for this
> > > > +specification.
> > > > +
> > > > +\begin{description}
> > > > +
> > > > +\item[VIRTIO_CAN_F_CAN_CLASSIC (0)]
> > > > +
> > > > +The device supports classic CAN frames with a maximum payload size of 8
> > > > +bytes.
> > > > +
> > > > +\item[VIRTIO_CAN_F_CAN_FD (1)]
> > > > +
> > > > +The device supports CAN FD frames with a maximum payload size of 64
> > > > +bytes.
> > > > +
> > > > +\item[VIRTIO_CAN_F_RTR_FRAMES (2)]
> > > > +
> > > > +The device supports RTR (remote transmission request) frames. RTR frames
> > > > +are only supported with classic CAN.
> > > > +
> > > > +\item[VIRTIO_CAN_F_LATE_TX_ACK (3)]
> > > > +
> > > > +The virtio CAN device marks transmission requests from the \field{Txq}
> > > > +as used after the CAN message has been transmitted on the CAN bus. If
> > > > +this feature bit has not been negotiated, the device is allowed to mark
> > > > +transmission requests already as used when the CAN message has been
> > > > +scheduled for transmission but might not yet have been transmitted on
> > > > +the CAN bus.
> > > > +
> > > > +\end{description}
> > > > +
> > > > +\subsubsection{Feature bit requirements}\label{sec:Device Types / CAN Device / Feature bits / Feature bit requirements}
> > > > +
> > > > +Some CAN feature bits require other CAN feature bits:
> > > > +\begin{description}
> > > > +\item[VIRTIO_CAN_F_RTR_FRAMES] Requires VIRTIO_CAN_F_CAN_CLASSIC.
> > > > +\end{description}
> > > > +
> > > > +It is required that at least one of VIRTIO_CAN_F_CAN_CLASSIC and
> > > > +VIRTIO_CAN_F_CAN_FD is negotiated.
> > > > +
> > > > +\subsection{Device configuration layout}\label{sec:Device Types / CAN Device / Device configuration layout}
> > > > +
> > > > +Device configuration fields are listed below, they are read-only for a
> > > > +driver. The \field{status} always exists. A single read-only bit (for
> > > > +the driver) is currently defined for \field{status}:
> > > > +
> > > > +\begin{lstlisting}
> > > > +struct virtio_can_config {
> > > > +#define VIRTIO_CAN_S_CTRL_BUSOFF (1 << 0)
> > > > + le16 status;
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +The bit VIRTIO_CAN_S_CTRL_BUSOFF in \field{status} is used to indicate
> > > > +the unsolicited CAN controller state change from started to stopped due
> > > > +to a detected bus off condition.
> > > > +
> > > > +\drivernormative{\subsubsection}{Device Initialization}{Device Types / CAN Device / Device Operation / Initialization}
> > > > +
> > > > +The driver MUST populate the \field{Rxq} with empty device-writeable
> > > > +buffers of at least the size of struct virtio_can_rx, see section
> > > > +\ref{struct virtio_can_rx}.
> > > > +
> > > > +\subsection{Device Operation}\label{sec:Device Types / CAN Device / Device Operation}
> > > > +
> > > > +A device operation has an outcome which is described by one of the
> > > > +following values:
> > > > +
> > > > +\begin{lstlisting}
> > > > +#define VIRTIO_CAN_RESULT_OK 0
> > > > +#define VIRTIO_CAN_RESULT_NOT_OK 1
> > > > +\end{lstlisting}
> > > > +
> > > > +Other values are to be treated like VIRTIO_CAN_RESULT_NOT_OK.
> > > > +
> > > > +\subsubsection{Controller Mode}\label{sec:Device Types / CAN Device / Device Operation / Controller Mode}
> > > > +
> > > > +The general format of a request in the \field{Controlq} is
> > > > +
> > > > +\begin{lstlisting}
> > > > +struct virtio_can_control_out {
> > > > +#define VIRTIO_CAN_SET_CTRL_MODE_START 0x0201
> > > > +#define VIRTIO_CAN_SET_CTRL_MODE_STOP 0x0202
> > > > + le16 msg_type;
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +To participate in bus communication the CAN controller is started by
> > > > +sending a VIRTIO_CAN_SET_CTRL_MODE_START control message, to stop
> > > > +participating in bus communication it is stopped by sending a
> > > > +VIRTIO_CAN_SET_CTRL_MODE_STOP control message. Both requests are
> > > > +confirmed by the result of the operation.
> > > > +
> > > > +\begin{lstlisting}
> > > > +struct virtio_can_control_in {
> > > > + u8 result;
> > > > +};
> > > > +\end{lstlisting}
> > > > +
> > > > +If the transition succeeded the \field{result} is VIRTIO_CAN_RESULT_OK
> > > > +otherwise it is VIRTIO_CAN_RESULT_NOT_OK. If a status update is
> > > > +necessary, the device updates the configuration \field{status} before
> > > > +marking the request used. As the configuration \field{status} change is
> > > > +caused by a request from the driver the device is allowed to omit the
> >
> > Is this to indicate that when a driver requests a change, the device can
> > omit notifying of the change? As I understand the specification, the
> > device can omit the notification, but the change must still occur? Is it
> > possible for the device to omit the change as well? What else could have
> > triggered the status change if it wasn't the driver?
> >
> > Thanks.
> >
>
> The change request notification OK/NOT_OK for every mode transition request
> is there in any case. In some cases the device would additionally notify the
> driver about the controller status via 'virtio_can_config' in config space
> (config space change notification mechanism), e.g. in case of a BusOff event
> on the device side. Although, it is possible to omit the config space
> notification e.g. when transitioning to stopped mode.
>
Thanks for the clarification. I think I got confused with the following
sentence:
`As the configuration status change is caused by a request from the
driver the device is allowed to omit the configuration change
notification here.`
I think this could be rewritten as follows:
`The device may omit the configuration change notification as the
configuration status change is requested by the driver.`
This change is, however, minor, so feel free to ignore it.
Matias
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-02-21 13:28 ` Marc Kleine-Budde
@ 2024-02-26 12:36 ` Cornelia Huck
2024-02-27 9:02 ` Matias Ezequiel Vara Larsen
0 siblings, 1 reply; 15+ messages in thread
From: Cornelia Huck @ 2024-02-26 12:36 UTC (permalink / raw)
To: Marc Kleine-Budde, Matias Ezequiel Vara Larsen
Cc: Mikhail Golubev-Ciuchea, virtio-comment, virtio-dev, linux-can,
Harald Mommer
On Wed, Feb 21 2024, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 21.02.2024 14:16:54, Matias Ezequiel Vara Larsen wrote:
>> On Wed, Feb 21, 2024 at 01:49:31PM +0100, Marc Kleine-Budde wrote:
>> > On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
>> > > > > +The length of the \field{sdu} is determined by the \field{length}.
>> > > > > +
>> > > > > +The type of a CAN message identifier is determined by \field{flags}. The
>> > > > > +3 most significant bits of \field{can_id} do not bear the information
>> > > > > +about the type of the CAN message identifier and are 0.
>> > > > > +
>> > > > > +The device MUST reject any CAN frame type for which support has not been
>> > > > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
>> > > > > +schedule the message for transmission. A CAN frame with an undefined bit
>> > > > > +set in \field{flags} is treated like a CAN frame for which support has
>> > > > > +not been negotiated.
>> > > > > +
>> > > > > +The device MUST reject any CAN frame for which \field{can_id} or
>> > > > > +\field{sdu} length are out of range or the CAN controller is in an
>> > > > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
>> > > > > +NOT schedule the message for transmission.
>> > > > > +
>> > > I am not very familiar with CAN but how does the device figure out that
>> > > the can_id is out of range?
>> >
>> > In classical CAN we have the standard CAN frames, which have an 11 bit
>> > ID, and there are extended CAN frames, which have 29 bits ID. Extended
>> > frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
>> >
>> > So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
>> > out of range.
>
> Another option would be an extended frame (VIRTIO_CAN_FLAGS_EXTENDED
> set) and using more than 29 bits.
>
>> Thanks Marc for the explanation. Do you think that it would be
>> worthwhile to add that to the spec at some point?
>
> Yes that makes sense as it clarifies what's meant by out of range for
> CAN-IDs, for the valid length a reference to
> \item[VIRTIO_CAN_F_CAN_CLASSIC (0)] and \item[VIRTIO_CAN_F_CAN_FD (1)]
> might be added.
[virtio mailing lists are supposedly down for migration right now, I
hope there's some kind of backfill happening later...]
If the question comes up, it does make sense to add a
clarification... as the virtio-can spec is already voted upon and
merged, we'd need a patch on top. Not sure if it would qualify as an
editorial update or a vote would be needed, best to see it first :)
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [virtio-dev] Re: [virtio-comment] [RFC PATCH v3] virtio-can: Device specification.
2024-02-26 12:36 ` Cornelia Huck
@ 2024-02-27 9:02 ` Matias Ezequiel Vara Larsen
0 siblings, 0 replies; 15+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-02-27 9:02 UTC (permalink / raw)
To: Cornelia Huck
Cc: Marc Kleine-Budde, Mikhail Golubev-Ciuchea, virtio-comment,
virtio-dev, linux-can, Harald Mommer
On Mon, Feb 26, 2024 at 01:36:40PM +0100, Cornelia Huck wrote:
> On Wed, Feb 21 2024, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>
> > On 21.02.2024 14:16:54, Matias Ezequiel Vara Larsen wrote:
> >> On Wed, Feb 21, 2024 at 01:49:31PM +0100, Marc Kleine-Budde wrote:
> >> > On 21.02.2024 11:37:58, Matias Ezequiel Vara Larsen wrote:
> >> > > > > +The length of the \field{sdu} is determined by the \field{length}.
> >> > > > > +
> >> > > > > +The type of a CAN message identifier is determined by \field{flags}. The
> >> > > > > +3 most significant bits of \field{can_id} do not bear the information
> >> > > > > +about the type of the CAN message identifier and are 0.
> >> > > > > +
> >> > > > > +The device MUST reject any CAN frame type for which support has not been
> >> > > > > +negotiated with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST NOT
> >> > > > > +schedule the message for transmission. A CAN frame with an undefined bit
> >> > > > > +set in \field{flags} is treated like a CAN frame for which support has
> >> > > > > +not been negotiated.
> >> > > > > +
> >> > > > > +The device MUST reject any CAN frame for which \field{can_id} or
> >> > > > > +\field{sdu} length are out of range or the CAN controller is in an
> >> > > > > +invalid state with VIRTIO_CAN_RESULT_NOT_OK in \field{result} and MUST
> >> > > > > +NOT schedule the message for transmission.
> >> > > > > +
> >> > > I am not very familiar with CAN but how does the device figure out that
> >> > > the can_id is out of range?
> >> >
> >> > In classical CAN we have the standard CAN frames, which have an 11 bit
> >> > ID, and there are extended CAN frames, which have 29 bits ID. Extended
> >> > frames are signaled with VIRTIO_CAN_FLAGS_EXTENDED set.
> >> >
> >> > So if a standard frame uses more than 11 Bits of CAN-ID, it's considered
> >> > out of range.
> >
> > Another option would be an extended frame (VIRTIO_CAN_FLAGS_EXTENDED
> > set) and using more than 29 bits.
> >
> >> Thanks Marc for the explanation. Do you think that it would be
> >> worthwhile to add that to the spec at some point?
> >
> > Yes that makes sense as it clarifies what's meant by out of range for
> > CAN-IDs, for the valid length a reference to
> > \item[VIRTIO_CAN_F_CAN_CLASSIC (0)] and \item[VIRTIO_CAN_F_CAN_FD (1)]
> > might be added.
>
> [virtio mailing lists are supposedly down for migration right now, I
> hope there's some kind of backfill happening later...]
>
> If the question comes up, it does make sense to add a
> clarification... as the virtio-can spec is already voted upon and
> merged, we'd need a patch on top. Not sure if it would qualify as an
> editorial update or a vote would be needed, best to see it first :)
>
I will submit two patches regarding the changes proposed in this thread.
Matias
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-02-27 9:02 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-09 14:22 [virtio-dev] [RFC PATCH v3] virtio-can: Device specification Mikhail Golubev-Ciuchea
2024-01-08 17:18 ` [virtio-dev] Re: [virtio-comment] " Mikhail Golubev-Ciuchea
2024-01-15 16:24 ` Cornelia Huck
2024-02-02 12:45 ` Cornelia Huck
2024-02-20 12:19 ` Matias Ezequiel Vara Larsen
2024-02-21 15:42 ` Mikhail Golubev-Ciuchea
2024-02-22 11:30 ` Matias Ezequiel Vara Larsen
2024-02-21 10:37 ` Matias Ezequiel Vara Larsen
2024-02-21 12:49 ` Marc Kleine-Budde
2024-02-21 13:16 ` Matias Ezequiel Vara Larsen
2024-02-21 13:28 ` Marc Kleine-Budde
2024-02-26 12:36 ` Cornelia Huck
2024-02-27 9:02 ` Matias Ezequiel Vara Larsen
2024-02-13 14:57 ` [virtio-dev] " Cornelia Huck
2024-02-16 11:08 ` Cornelia Huck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).