[PATCH RFC] Clarify FAILED status handling

[Cornelia Huck <cornelia.huck@de.ibm.com>]

We did not give any guidance before what the device is supposed to
do if the driver set the FAILED status bit. Instruct the device to
leave the driver alone and to ignore any driver actions other than
reset.

As we did not specify that before, formulate this as SHOULD so that
existing implementations stay compliant.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---

I noticed that we don't really say what the FAILED status bit
should effect (it's currently basically driver-only, and e.g.
qemu does not do anything with it). It is probably more useful
if it actually has consequences for device operation -- although
we certainly don't want to break existing implementations.

---
 content.tex | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/content.tex b/content.tex
index 222b78e..4011c5a 100644
--- a/content.tex
+++ b/content.tex
@@ -78,6 +78,12 @@ The device MUST NOT consume buffers or notify the driver before DRIVER_OK.
 that a reset is needed.  If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET, the device
 MUST send a device configuration change notification to the driver.
 
+The device SHOULD NOT notify the driver if FAILED has been set. It MAY set
+DEVICE_NEEDS_RESET in that case.
+
+The device SHOULD NOT process any driver actions like notifications if
+FAILED has been set, with the exception of the driver resetting the device.
+
 \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature Bits}
 
 Each virtio device offers all the features it understands.  During
-- 
2.10.2