From: Cornelia Huck <cohuck@redhat.com>
To: virtio@lists.oasis-open.org, virtio-comment@lists.oasis-open.org
Cc: Jason Wang <jasowang@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>
Subject: [PATCH] ccw: clarify device reset
Date: Mon, 11 Oct 2021 13:38:28 +0200 [thread overview]
Message-ID: <20211011113828.309458-1-cohuck@redhat.com> (raw)
Unlike other transports, a reset triggered by the driver is actually
complete once the command has been completed. Make this behaviour
and the requirements more explicit.
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
---
We have discussed this before while talking about reset behaviour,
but I don't remember sending an actual patch.
If this looks good, I'll open an issue.
---
conformance.tex | 2 ++
content.tex | 22 +++++++++++++++++++++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/conformance.tex b/conformance.tex
index c52f1a40be2d..24e862ad217a 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -122,6 +122,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Communicating Status Information}
\item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts}
\item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification}
+\item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
\end{itemize}
\conformance{\subsection}{Network Driver Conformance}\label{sec:Conformance / Driver Conformance / Network Driver Conformance}
@@ -372,6 +373,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting Up Indicators / Setting Up Two-Stage Queue Indicators}
\item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Host->Guest Notification / Notification via Adapter I/O Interrupts}
\item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Guest->Host Notification}
+\item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
\end{itemize}
\conformance{\subsection}{Network Device Conformance}\label{sec:Conformance / Device Conformance / Network Device Conformance}
diff --git a/content.tex b/content.tex
index 5e716721edb3..0410f46f6a78 100644
--- a/content.tex
+++ b/content.tex
@@ -2775,8 +2775,28 @@ \subsubsection{Guest->Host Notification}\label{sec:Virtio Transport Options / Vi
\subsubsection{Resetting Devices}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
In order to reset a device, a driver sends the
-CCW_CMD_VDEV_RESET command.
+CCW_CMD_VDEV_RESET command. This command does not carry any payload.
+The device signals completion of the reset operation by making the subchannel
+status pending to indicate successful completion of the channel command.
+Notably, the command not only triggers the reset operation, but the reset
+operation is already completed when the operation concludes successfully.
+
+\devicenormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
+
+Before making the subchannel status pending to indicate successful completion
+of the reset command, the device MUST reinitialize \field{device status} to
+zero.
+
+The device MUST NOT send notifications or interact with the queues after
+it signaled successful completion of the reset command.
+
+\drivernormative{\paragraph}{Resetting Devices}{Virtio Transport Options / Virtio over channel I/O / Device Operation / Resetting Devices}
+
+The driver MAY consider the reset operation to be complete already after
+successful completion of the channel command, although it MAY also verify
+reset completion by reading \field{device status} via CCW_CMD_READ_STATUS
+afterwards.
\chapter{Device Types}\label{sec:Device Types}
--
2.31.1
next reply other threads:[~2021-10-11 11:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 11:38 Cornelia Huck [this message]
2021-10-12 2:54 ` [PATCH] ccw: clarify device reset Jason Wang
2021-10-12 11:16 ` [virtio] " Cornelia Huck
2021-10-13 6:20 ` Jason Wang
2021-10-13 7:01 ` [virtio] " Cornelia Huck
2021-10-21 16:23 ` Cornelia Huck
2021-10-21 23:35 ` Halil Pasic
2021-10-25 1:29 ` Jason Wang
2021-10-25 7:36 ` Cornelia Huck
2021-10-25 7:34 ` Cornelia Huck
2021-10-27 7:58 ` Halil Pasic
2021-10-27 8:02 ` Jason Wang
2021-10-27 9:16 ` Cornelia Huck
2021-10-27 22:25 ` Halil Pasic
2021-10-28 6:55 ` [virtio-comment] " Cornelia Huck
2021-11-26 12:07 ` Cornelia Huck
2021-11-26 17:11 ` Halil Pasic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211011113828.309458-1-cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=jasowang@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox