summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authormstsirkin <mstsirkin@0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652>2014-03-02 21:36:07 +0000
committermstsirkin <mstsirkin@0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652>2014-03-02 21:36:07 +0000
commitb4072ed1d8b1b04ccd232ac6c54f37b612154d92 (patch)
treeb0cccd9c5e1589e5533ead60c8334af4b85b4cd9
parent53b9bba9fc087489b4ffdd0aa37eb802a6c22693 (diff)
legacy device initialization: confirmance statements
Change accepted on VIRTIO TC Meeting, 3 December 2013 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@299 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
-rw-r--r--content.tex40
1 files changed, 35 insertions, 5 deletions
diff --git a/content.tex b/content.tex
index 75e80b5..c91dd69 100644
--- a/content.tex
+++ b/content.tex
@@ -672,7 +672,8 @@ The driver MUST follow this sequence to initialize a device:
\item Set the DRIVER status bit: the guest OS knows how to drive the device.
-\item Read device feature bits, and write the subset of feature bits
+\item\label{itm:General Initialization And Device Operation /
+Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits
understood by the OS and driver to the device. During this step the
driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it.
@@ -706,12 +707,41 @@ feature negotiation, which meant that devices finalized features on
first-use, and no features could be introduced which radically changed
the initial operation of the device.
-Legacy device implementations often used the device before setting the
-DRIVER_OK bit.
-
-The result was the steps \ref{itm:General Initialization And Device Operation / Device Initialization / Set FEATURES-OK} and \ref{itm:General Initialization And Device Operation / Device Initialization / Re-read FEATURES-OK} were omitted, and steps \ref{itm:General Initialization And Device Operation / Device Initialization / Device-specific Setup} and \ref{itm:General Initialization And Device Operation / Device Initialization / Set DRIVER-OK}
+Legacy driver implementations often used the device before setting the
+DRIVER_OK bit, and sometimes even before writing the feature bits
+to the device.
+
+The result was the steps \ref{itm:General Initialization And
+Device Operation / Device Initialization / Set FEATURES-OK} and
+\ref{itm:General Initialization And Device Operation / Device
+Initialization / Re-read FEATURES-OK} were omitted, and steps
+\ref{itm:General Initialization And Device Operation /
+Device Initialization / Read feature bits},
+\ref{itm:General Initialization And Device Operation / Device Initialization / Device-specific Setup} and \ref{itm:General Initialization And Device Operation / Device Initialization / Set DRIVER-OK}
were conflated.
+Therefore, when using the legacy interface:
+\begin{itemize}
+\item
+The transitional driver MUST execute the initialization
+sequence as described in \ref{sec:General Initialization And Device
+Operation / Device Initialization}
+but omitting the steps \ref{itm:General Initialization And Device
+Operation / Device Initialization / Set FEATURES-OK} and
+\ref{itm:General Initialization And Device Operation / Device
+Initialization / Re-read FEATURES-OK}.
+
+\item
+The transitional device MUST support the driver
+writing device configuration fields
+before the step \ref{itm:General Initialization And Device Operation /
+Device Initialization / Read feature bits}.
+\item
+The transitional device MUST support the driver
+using the device before the step \ref{itm:General Initialization
+And Device Operation / Device Initialization / Set DRIVER-OK}.
+\end{itemize}
+
\section{Device Operation}\label{sec:General Initialization And Device Operation / Device Operation}
There are two parts to device operation: supplying new buffers to