summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorcornelia.huck <cornelia.huck@0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652>2013-10-30 15:05:21 +0000
committercornelia.huck <cornelia.huck@0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652>2013-10-30 15:05:21 +0000
commit080656277fe8607d5dd1e76ad4a6434c89be5705 (patch)
treec22de50684e1de72b228ce14bbf14a721cce17d5
parent80f24376d88b3e25496aa2b3a5ee9e0903bb40e7 (diff)
virtio-ccw: clarify some channel I/O concepts
Add the documents where channel I/O is generally described to the normative references and add some further words on command rejects and length checks. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@73 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652
-rw-r--r--virtio-v1.0-wd01-part1-specification.txt21
1 files changed, 21 insertions, 0 deletions
diff --git a/virtio-v1.0-wd01-part1-specification.txt b/virtio-v1.0-wd01-part1-specification.txt
index b9e27ea..ae79444 100644
--- a/virtio-v1.0-wd01-part1-specification.txt
+++ b/virtio-v1.0-wd01-part1-specification.txt
@@ -67,6 +67,10 @@ Driver
[RFC 2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt IETF (Internet Engineering Task Force) RFC 2119, March 1997.
+[S390 PoP] z/Architecture Principles of Operation, IBM Publication SA22-7832
+
+[S390 Common I/O] ESA/390 Common I/O-Device and Self-Description, IBM Publication SA22-7204
+
1.3. Non-Normative References
=========================
@@ -1717,6 +1721,23 @@ virtio:
#define CCW_CMD_WRITE_STATUS 0x31
#define CCW_CMD_READ_VQ_CONF 0x32
+The virtio-ccw device acts like a normal channel device, as specified
+in [S390 PoP] and [S390 Common I/O]. In particular:
+
+- A device must post a unit check with command reject for any command
+ it does not support.
+
+- If a driver did not suppress length checks for a channel command,
+ the device must present a subchannel status as detailed in the
+ architecture when the actual length did not match the expected length.
+
+- If a driver did suppress length checks for a channel command, the
+ device must present a check condition if the transmitted data does
+ not contain enough data to process the command. If the driver submitted
+ a buffer that was too long, the device should accept the command.
+ The driver should attempt to provide the correct length even if it
+ suppresses length checks.
+
2.3.3.2. Device Initialization
------------------------------