On Fri, Oct 31, 2014 at 03:26:19PM +0100, Cornelia Huck wrote:
> We want to be able to reject a status (e.g. FEATURES_OK if the device
> can't work with the features negotiated).
I guess the reason it's needed is because ccw doesn't have
READ_STATUS?
> The easiest way to do that
> is to allow the device to fail the WRITE_STATUS command.
>
> VIRTIO-116
>
> Signed-off-by: Cornelia Huck <>
> ---
> conformance.tex |
2 ++
> content.tex
|
15 +++++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/conformance.tex b/conformance.tex
> index b10ce96..aff92f1 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -79,6 +79,7 @@ A Channel I/O driver MUST conform to the following normative statements:
> \begin{itemize}
> \item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Basic Concepts}
> \item \ref{drivernormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting the Virtio Revision}
> +\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}
> \end{itemize}
> @@ -182,6 +183,7 @@ A Channel I/O device MUST conform to the following normative statements:
> \item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Basic Concepts}
> \item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Setting the Virtio Revision}
> \item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Configuring a Virtqueue}
> +\item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Communicating Status Information}
> \item \ref{devicenormative:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Handling Device Features}
> \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}
> diff --git a/content.tex b/content.tex
> index 38ae49e..490823e 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -2627,6 +2627,21 @@ The driver changes the status of a device via the
> CCW_CMD_WRITE_STATUS command, which transmits an 8 bit status
> value.
>
> +The device is allowed to reject a status: For example, it might fail to accept
> +the FEATURES_OK status bit during device initialization.
I kind of dislike it that we are adding this new concept of
"rejecting a status". The generic spec says:
The device SHOULD accept any valid subset
of features the driver accepts, otherwise it MUST fail to set the
FEATURES_OK \field{device status} bit when the driver writes it.
so devices accept features, not status, I think applying concept of
accept/reject to status is confusing.
Let's say that device fails to set status to requested value.
For example:
As described in <cross reference> devices sometimes fail to set
the \field{device status} to value written by the driver.
> +
> +\drivernormative{\paragraph}{Communicating Status Information}{Virtio Transport Options / Virtio over channel I/O / Device Initialization / Communicating Status Information}
> +
> +If the device posts a unit check with command reject in response to the
> +CCW_CMD_WRITE_STATUS command, the driver MUST assume that
add:
setting device failed to set the status and that
> +the status
> +field
> +retained its previous value.
> +
> +\devicenormative{\paragraph}{Communicating Status Information}{Virtio Transport Options / Virtio over channel I/O / Device Initialization / Communicating Status Information}
> +
> +If the driver attempts to set a status that the device does not accept,
instead:
If the device fails to set the \field{device status} field
to the value written by driver
> + the
> +device MUST leave the status field unchanged and MUST post a unit check
> +with command reject.
> +
> \subsubsection{Handling Device Features}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Handling Device Features}
>
> Feature bits are arranged in an array of 32 bit values, making
> --
> 1.7.9.5
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
