format: remove trailing whitespace

no reason to have it

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

git-svn-id: https://tools.oasis-open.org/version-control/svn/virtio@21 0c8fb4dd-22a2-4bb5-bc14-6c75a5f43652

1 files changed, 883 insertions, 883 deletions

diff --git a/virtio-v1.0-wd01-part1-specification.txt b/virtio-v1.0-wd01-part1-specification.txt
index 5c887f2..a887618 100644
--- a/virtio-v1.0-wd01-part1-specification.txt
+++ b/virtio-v1.0-wd01-part1-specification.txt
@@ -7,9 +7,9 @@ design they are not all that different from physical devices, and this
 document treats them as such. This allows the guest to use standard
 drivers and discovery mechanisms.
 
-The purpose of virtio and this specification is that virtual 
-environments and guests should have a straightforward, efficient, 
-standard and extensible mechanism for virtual devices, rather 
+The purpose of virtio and this specification is that virtual
+environments and guests should have a straightforward, efficient,
+standard and extensible mechanism for virtual devices, rather
 than boutique per-environment or per-OS mechanisms.
 
   Straightforward: Virtio devices use normal bus mechanisms of
@@ -17,9 +17,9 @@ than boutique per-environment or per-OS mechanisms.
   author. There is no exotic page-flipping or COW mechanism: it's just
   a normal device.[1]
 
-  Efficient: Virtio devices consist of rings of descriptors 
-  for input and output, which are neatly separated to avoid cache 
-  effects from both guest and device writing to the same cache 
+  Efficient: Virtio devices consist of rings of descriptors
+  for input and output, which are neatly separated to avoid cache
+  effects from both guest and device writing to the same cache
   lines.
 
   Standard: Virtio makes no assumptions about the environment in which
@@ -27,10 +27,10 @@ than boutique per-environment or per-OS mechanisms.
   devices are implemented over PCI and other buses, and earlier drafts
   been implemented on other buses not included in this spec.[2]
 
-  Extensible: Virtio PCI devices contain feature bits which are 
-  acknowledged by the guest operating system during device setup. 
-  This allows forwards and backwards compatibility: the device 
-  offers all the features it knows about, and the driver 
+  Extensible: Virtio PCI devices contain feature bits which are
+  acknowledged by the guest operating system during device setup.
+  This allows forwards and backwards compatibility: the device
+  offers all the features it knows about, and the driver
   acknowledges those it understands and wishes to use.
 
 1.1.1.  Key words
@@ -90,28 +90,28 @@ o One or more virtqueues
 2.1.1. Device Status Field
 -------------------------
 
-The Device Status field is updated by the guest to indicate its 
-progress. This provides a simple low-level diagnostic: it's most 
-useful to imagine them hooked up to traffic lights on the console 
+The Device Status field is updated by the guest to indicate its
+progress. This provides a simple low-level diagnostic: it's most
+useful to imagine them hooked up to traffic lights on the console
 indicating the status of each device.
 
 This field is 0 upon reset, otherwise at least one bit should be set:
 
-  ACKNOWLEDGE (1) Indicates that the guest OS has found the 
+  ACKNOWLEDGE (1) Indicates that the guest OS has found the
   device and recognized it as a valid virtio device.
 
-  DRIVER (2) Indicates that the guest OS knows how to drive the 
-  device. Under Linux, drivers can be loadable modules so there 
-  may be a significant (or infinite) delay before setting this 
+  DRIVER (2) Indicates that the guest OS knows how to drive the
+  device. Under Linux, drivers can be loadable modules so there
+  may be a significant (or infinite) delay before setting this
   bit.
 
-  DRIVER_OK (4) Indicates that the driver is set up and ready to 
+  DRIVER_OK (4) Indicates that the driver is set up and ready to
   drive the device.
 
-  FAILED (128) Indicates that something went wrong in the guest, 
-  and it has given up on the device. This could be an internal 
-  error, or the driver didn't like the device for some reason, or 
-  even a fatal error during device operation. The device must be 
+  FAILED (128) Indicates that something went wrong in the guest,
+  and it has given up on the device. This could be an internal
+  error, or the driver didn't like the device for some reason, or
+  even a fatal error during device operation. The device must be
   reset before attempting to re-initialize.
 
 2.1.2. Feature Bits
@@ -134,15 +134,15 @@ Feature bits are allocated as follows:
 
   0 to 23: Feature bits for the specific device type
 
-  24 to 31: Feature bits reserved for extensions to the queue and 
+  24 to 31: Feature bits reserved for extensions to the queue and
   feature negotiation mechanisms
 
-For example, feature bit 0 for a network device (i.e. Subsystem 
-Device ID 1) indicates that the device supports checksumming of 
+For example, feature bit 0 for a network device (i.e. Subsystem
+Device ID 1) indicates that the device supports checksumming of
 packets.
 
-In particular, new fields in the device configuration space are 
-indicated by offering a feature bit, so the guest can check 
+In particular, new fields in the device configuration space are
+indicated by offering a feature bit, so the guest can check
 before accessing that part of the configuration space.
 
 2.1.3. Configuration Space
@@ -151,7 +151,7 @@ before accessing that part of the configuration space.
 Configuration space is generally used for rarely-changing or
 initialization-time parameters.
 
-Note that this space is generally the guest's native endian, 
+Note that this space is generally the guest's native endian,
 rather than PCI's little-endian.
 
 2.1.4. Virtqueues
@@ -164,7 +164,7 @@ transmit and one for receive.  Each queue has a 16-bit queue size
 parameter, which sets the number of entries and implies the total size
 of the queue.
 
-Each virtqueue occupies two or more physically-contiguous pages 
+Each virtqueue occupies two or more physically-contiguous pages
 (usually defined as 4096 bytes, but depending on the transport)
 and consists of three parts:
 
@@ -189,10 +189,10 @@ virtqueue layout structure looks like this:
 	struct vring {
 		// The actual descriptors (16 bytes each)
 		struct vring_desc desc[ Queue Size ];
-	
+
 		// A ring of available descriptor heads with free-running index.
 		struct vring_avail avail;
-	
+
 		// Padding to the next PAGE_SIZE boundary.
 		char pad[ Padding ];
 
@@ -200,10 +200,10 @@ virtqueue layout structure looks like this:
 		struct vring_used used;
 	};
 
-When the driver wants to send a buffer to the device, it fills in 
-a slot in the descriptor table (or chains several together), and 
-writes the descriptor index into the available ring.  It then 
-notifies the device. When the device has finished a buffer, it 
+When the driver wants to send a buffer to the device, it fills in
+a slot in the descriptor table (or chains several together), and
+writes the descriptor index into the available ring.  It then
+notifies the device. When the device has finished a buffer, it
 writes the descriptor into the used ring, and sends an interrupt.
 
 2.1.4.1. A Note on Virtqueue Endianness
@@ -240,10 +240,10 @@ dividing a network packet into 1500 single-byte descriptors!
 2.1.4.3. The Virtqueue Descriptor Table
 --------------------------------------
 
-The descriptor table refers to the buffers the guest is using for 
-the device. The addresses are physical addresses, and the buffers 
-can be chained via the next field. Each descriptor describes a 
-buffer which is read-only or write-only, but a chain of 
+The descriptor table refers to the buffers the guest is using for
+the device. The addresses are physical addresses, and the buffers
+can be chained via the next field. Each descriptor describes a
+buffer which is read-only or write-only, but a chain of
 descriptors can contain both read-only and write-only buffers.
 
 No descriptor chain may be more than 2^32 bytes long in total.
@@ -253,13 +253,13 @@ No descriptor chain may be more than 2^32 bytes long in total.
 		u64 addr;
 		/* Length. */
 		u32 len;
-	
+
 	/* This marks a buffer as continuing via the next field. */
 	#define VRING_DESC_F_NEXT   1
 	/* This marks a buffer as write-only (otherwise read-only). */
 	#define VRING_DESC_F_WRITE     2
 	/* This means the buffer contains a list of buffer descriptors. */
-	#define VRING_DESC_F_INDIRECT   4 
+	#define VRING_DESC_F_INDIRECT   4
 		/* The flags as indicated above. */
 		u16 flags;
 		/* Next field if flags & NEXT */
@@ -272,16 +272,16 @@ for this virtqueue.
 2.1.4.3.1. Indirect Descriptors
 ------------------------------
 
-Some devices benefit by concurrently dispatching a large number 
-of large requests. The VIRTIO_RING_F_INDIRECT_DESC feature can be 
-used to allow this (see "2.6. Reserved Feature Bits"). To increase 
-ring capacity it is possible to store a table of indirect 
-descriptors anywhere in memory, and insert a descriptor in main 
-virtqueue (with flags&VRING_DESC_F_INDIRECT on) that refers to memory buffer 
-containing this indirect descriptor table; fields addr and len 
-refer to the indirect table address and length in bytes, 
-respectively. The indirect table layout structure looks like this 
-(len is the length of the descriptor that refers to this table, 
+Some devices benefit by concurrently dispatching a large number
+of large requests. The VIRTIO_RING_F_INDIRECT_DESC feature can be
+used to allow this (see "2.6. Reserved Feature Bits"). To increase
+ring capacity it is possible to store a table of indirect
+descriptors anywhere in memory, and insert a descriptor in main
+virtqueue (with flags&VRING_DESC_F_INDIRECT on) that refers to memory buffer
+containing this indirect descriptor table; fields addr and len
+refer to the indirect table address and length in bytes,
+respectively. The indirect table layout structure looks like this
+(len is the length of the descriptor that refers to this table,
 which is a variable, so this code won't compile):
 
 	struct indirect_descriptor_table {
@@ -289,15 +289,15 @@ which is a variable, so this code won't compile):
 		struct vring_desc desc[len / 16];
 	};
 
-The first indirect descriptor is located at start of the indirect 
-descriptor table (index 0), additional indirect descriptors are 
-chained by next field. An indirect descriptor without next field 
-(with flags&VRING_DESC_F_NEXT off) signals the end of the indirect descriptor 
-table, and transfers control back to the main virtqueue. An 
-indirect descriptor can not refer to another indirect descriptor 
-table (flags&VRING_DESC_F_INDIRECT must be off). A single indirect descriptor 
-table can include both read-only and write-only descriptors; 
-write-only flag (flags&VRING_DESC_F_WRITE) in the descriptor that refers to it 
+The first indirect descriptor is located at start of the indirect
+descriptor table (index 0), additional indirect descriptors are
+chained by next field. An indirect descriptor without next field
+(with flags&VRING_DESC_F_NEXT off) signals the end of the indirect descriptor
+table, and transfers control back to the main virtqueue. An
+indirect descriptor can not refer to another indirect descriptor
+table (flags&VRING_DESC_F_INDIRECT must be off). A single indirect descriptor
+table can include both read-only and write-only descriptors;
+write-only flag (flags&VRING_DESC_F_WRITE) in the descriptor that refers to it
 is ignored.
 
 2.1.4.4. The Virtqueue Available Ring
@@ -315,7 +315,7 @@ the device is controlled by the VIRTIO_RING_F_EVENT_IDX feature bit
 (see "2.6. Reserved Feature Bits"). This interrupt suppression is
 merely an optimization; it may not suppress interrupts entirely.
 
-The “idx” field indicates where we would put the next descriptor 
+The “idx” field indicates where we would put the next descriptor
 entry (modulo the queue size). This starts at 0, and increases.
 
 	struct vring_avail {
@@ -324,29 +324,29 @@ entry (modulo the queue size). This starts at 0, and increases.
 		u16 idx;
 		u16 ring[ /* Queue Size */ ];
 		u16 used_event;	/* Only if VIRTIO_RING_F_EVENT_IDX */
-	}; 
+	};
 
 2.1.4.5. The Virtqueue Used Ring
 -------------------------------
 
-The used ring is where the device returns buffers once it is done 
-with them. The flags field can be used by the device to hint that 
-no notification is necessary when the guest adds to the available 
-ring. Alternatively, the “avail_event” field can be used by the 
-device to hint that no notification is necessary until an entry 
-with an index specified by the “avail_event” is written in the 
-available ring (equivalently, until the idx field in the 
-available ring will reach the value avail_event + 1). The method 
-employed by the device is controlled by the guest through the 
+The used ring is where the device returns buffers once it is done
+with them. The flags field can be used by the device to hint that
+no notification is necessary when the guest adds to the available
+ring. Alternatively, the “avail_event” field can be used by the
+device to hint that no notification is necessary until an entry
+with an index specified by the “avail_event” is written in the
+available ring (equivalently, until the idx field in the
+available ring will reach the value avail_event + 1). The method
+employed by the device is controlled by the guest through the
 VIRTIO_RING_F_EVENT_IDX feature bit (see "2.6. Reserved
 Feature Bits").[7]
 
-Each entry in the ring is a pair: the head entry of the 
-descriptor chain describing the buffer (this matches an entry 
-placed in the available ring by the guest earlier), and the total 
-of bytes written into the buffer. The latter is extremely useful 
-for guests using untrusted buffers: if you do not know exactly 
-how much has been written by the device, you usually have to zero 
+Each entry in the ring is a pair: the head entry of the
+descriptor chain describing the buffer (this matches an entry
+placed in the available ring by the guest earlier), and the total
+of bytes written into the buffer. The latter is extremely useful
+for guests using untrusted buffers: if you do not know exactly
+how much has been written by the device, you usually have to zero
 the buffer to ensure no data leakage occurs.
 
 	/* u32 is used here for ids for padding reasons. */
@@ -358,7 +358,7 @@ the buffer to ensure no data leakage occurs.
 	};
 
 	struct vring_used {
-	#define VRING_USED_F_NO_NOTIFY  1 
+	#define VRING_USED_F_NO_NOTIFY  1
 		u16 flags;
 		u16 idx;
 		struct vring_used_elem ring[ /* Queue Size */];
@@ -368,11 +368,11 @@ the buffer to ensure no data leakage occurs.
 2.1.4.6. Helpers for Operating Virtqueues
 ----------------------------------------
 
-The Linux Kernel Source code contains the definitions above and 
-helper routines in a more usable form, in 
-include/linux/virtio_ring.h. This was explicitly licensed by IBM 
-and Red Hat under the (3-clause) BSD license so that it can be 
-freely used by all other projects, and is reproduced (with slight 
+The Linux Kernel Source code contains the definitions above and
+helper routines in a more usable form, in
+include/linux/virtio_ring.h. This was explicitly licensed by IBM
+and Red Hat under the (3-clause) BSD license so that it can be
+freely used by all other projects, and is reproduced (with slight
 variation to remove Linux assumptions) in *XREF*.
 
 2.2. General Initialization And Device Operation
@@ -392,73 +392,73 @@ how to communicate with the specific device.
 
 3. The DRIVER status bit is set: we know how to drive the device.
 
-4. Device-specific setup, including reading the device feature 
+4. Device-specific setup, including reading the device feature
   bits, discovery of virtqueues for the device, optional per-bus
-  setup, and reading and possibly writing the device's virtio 
+  setup, and reading and possibly writing the device's virtio
   configuration space.
 
-5. The subset of device feature bits understood by the driver is 
+5. The subset of device feature bits understood by the driver is
    written to the device.
 
 6. The DRIVER_OK status bit is set.
 
-7. The device can now be used (ie. buffers added to the 
+7. The device can now be used (ie. buffers added to the
    virtqueues)[4]
 
-If any of these steps go irrecoverably wrong, the guest should 
-set the FAILED status bit to indicate that it has given up on the 
+If any of these steps go irrecoverably wrong, the guest should
+set the FAILED status bit to indicate that it has given up on the
 device (it can reset the device later to restart if desired).
 
 2.2.2. Device Operation
 ----------------------
 
-There are two parts to device operation: supplying new buffers to 
-the device, and processing used buffers from the device. As an 
-example, the simplest virtio network device has two virtqueues: the 
-transmit virtqueue and the receive virtqueue. The driver adds 
-outgoing (read-only) packets to the transmit virtqueue, and then 
-frees them after they are used. Similarly, incoming (write-only) 
-buffers are added to the receive virtqueue, and processed after 
+There are two parts to device operation: supplying new buffers to
+the device, and processing used buffers from the device. As an
+example, the simplest virtio network device has two virtqueues: the
+transmit virtqueue and the receive virtqueue. The driver adds
+outgoing (read-only) packets to the transmit virtqueue, and then
+frees them after they are used. Similarly, incoming (write-only)
+buffers are added to the receive virtqueue, and processed after
 they are used.
 
 2.2.2.1. Supplying Buffers to The Device
 ---------------------------------------
 
-Actual transfer of buffers from the guest OS to the device 
+Actual transfer of buffers from the guest OS to the device
 operates as follows:
 
 1. Place the buffer(s) into free descriptor(s).
 
-  (a) If there are no free descriptors, the guest may choose to 
-    notify the device even if notifications are suppressed (to 
+  (a) If there are no free descriptors, the guest may choose to
+    notify the device even if notifications are suppressed (to
     reduce latency).[8]
 
-2. Place the id of the buffer in the next ring entry of the 
+2. Place the id of the buffer in the next ring entry of the
   available ring.
 
-3. The steps (1) and (2) may be performed repeatedly if batching 
+3. The steps (1) and (2) may be performed repeatedly if batching
   is possible.
 
-4. A memory barrier should be executed to ensure the device sees 
-  the updated descriptor table and available ring before the next 
+4. A memory barrier should be executed to ensure the device sees
+  the updated descriptor table and available ring before the next
   step.
 
-5. The available “idx” field should be increased by the number of 
+5. The available “idx” field should be increased by the number of
   entries added to the available ring.
 
-6. A memory barrier should be executed to ensure that we update 
+6. A memory barrier should be executed to ensure that we update
   the idx field before checking for notification suppression.
 
-7. If notifications are not suppressed, the device should be 
+7. If notifications are not suppressed, the device should be
   notified of the new buffers.
 
-Note that the above code does not take precautions against the 
-available ring buffer wrapping around: this is not possible since 
-the ring buffer is the same size as the descriptor table, so step 
+Note that the above code does not take precautions against the
+available ring buffer wrapping around: this is not possible since
+the ring buffer is the same size as the descriptor table, so step
 (1) will prevent such a condition.
 
-In addition, the maximum queue size is 32768 (it must be a power 
-of 2 which fits in 16 bits), so the 16-bit “idx” value can always 
+In addition, the maximum queue size is 32768 (it must be a power
+of 2 which fits in 16 bits), so the 16-bit “idx” value can always
 distinguish between a full and empty buffer.
 
 Here is a description of each stage in more detail.
@@ -466,9 +466,9 @@ Here is a description of each stage in more detail.
 2.2.2.1.1. Placing Buffers Into The Descriptor Table
 ---------------------------------------------------
 
-A buffer consists of zero or more read-only physically-contiguous 
-elements followed by zero or more physically-contiguous 
-write-only elements (it must have at least one element). This 
+A buffer consists of zero or more read-only physically-contiguous
+elements followed by zero or more physically-contiguous
+write-only elements (it must have at least one element). This
 algorithm maps it into the descriptor table:
 
 for each buffer element, b:
@@ -479,30 +479,30 @@ for each buffer element, b:
 
   (c) Set d.len to the length of b.
 
-  (d) If b is write-only, set d.flags to VRING_DESC_F_WRITE, 
+  (d) If b is write-only, set d.flags to VRING_DESC_F_WRITE,
     otherwise 0.
 
   (e) If there is a buffer element after this:
 
-    i. Set d.next to the index of the next free descriptor 
+    i. Set d.next to the index of the next free descriptor
       element.
 
     ii. Set the VRING_DESC_F_NEXT bit in d.flags.
 
-In practice, the d.next fields are usually used to chain free 
-descriptors, and a separate count kept to check there are enough 
+In practice, the d.next fields are usually used to chain free
+descriptors, and a separate count kept to check there are enough
 free descriptors before beginning the mappings.
 
 2.2.2.1.2. Updating The Available Ring
 -------------------------------------
 
-The head of the buffer we mapped is the first d in the algorithm 
+The head of the buffer we mapped is the first d in the algorithm
 above. A naive implementation would do the following:
 
 	avail->ring[avail->idx % qsz] = head;
 
-However, in general we can add many descriptor chains before we update 
-the “idx” field (at which point they become visible to the 
+However, in general we can add many descriptor chains before we update
+the “idx” field (at which point they become visible to the
 device), so we keep a counter of how many we've added:
 
 	avail->ring[(avail->idx + added++) % qsz] = head;
@@ -510,13 +510,13 @@ device), so we keep a counter of how many we've added:
 2.2.2.1.3. Updating The Index Field
 ----------------------------------
 
-Once the index field of the virtqueue is updated, the device will 
-be able to access the descriptor chains we've created and the 
-memory they refer to. This is why a memory barrier is generally 
-used before the index update, to ensure it sees the most up-to-date 
+Once the index field of the virtqueue is updated, the device will
+be able to access the descriptor chains we've created and the
+memory they refer to. This is why a memory barrier is generally
+used before the index update, to ensure it sees the most up-to-date
 copy.
 
-The index field always increments, and we let it wrap naturally at 
+The index field always increments, and we let it wrap naturally at
 65536:
 
 	avail->idx += added;
@@ -525,21 +525,21 @@ The index field always increments, and we let it wrap naturally at
 ------------------------------
 
 The actual method of device notification is bus-specific, but generally
-it can be expensive.  So the device can suppress such notifications if it 
+it can be expensive.  So the device can suppress such notifications if it
 doesn't need them.  We have to be careful to expose the new index
-value before checking if notifications are suppressed: it's OK to notify 
-gratuitously, but not to omit a required notification. So again, 
-we use a memory barrier here before reading the flags or the 
+value before checking if notifications are suppressed: it's OK to notify
+gratuitously, but not to omit a required notification. So again,
+we use a memory barrier here before reading the flags or the
 avail_event field.
 
 If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated, and if the
 VRING_USED_F_NOTIFY flag is not set, we go ahead and notify the
 device.
 
-If the VIRTIO_F_RING_EVENT_IDX feature is negotiated, we read the 
-avail_event field in the available ring structure. If the 
-available index crossed_the avail_event field value since the 
-last notification, we go ahead and write to the PCI configuration 
+If the VIRTIO_F_RING_EVENT_IDX feature is negotiated, we read the
+avail_event field in the available ring structure. If the
+available index crossed_the avail_event field value since the
+last notification, we go ahead and write to the PCI configuration
 space.  The avail_event field wraps naturally at 65536 as well,
 iving the following algorithm for calculating whether a device needs
 notification:
@@ -549,46 +549,46 @@ notification:
 2.2.2.2. Receiving Used Buffers From The Device
 ----------------------------------------------
 
-Once the device has used a buffer (read from or written to it, or 
-parts of both, depending on the nature of the virtqueue and the 
-device), it sends an interrupt, following an algorithm very 
-similar to the algorithm used for the driver to send the device a 
+Once the device has used a buffer (read from or written to it, or
+parts of both, depending on the nature of the virtqueue and the
+device), it sends an interrupt, following an algorithm very
+similar to the algorithm used for the driver to send the device a
 buffer:
 
-1. Write the head descriptor number to the next field in the used 
+1. Write the head descriptor number to the next field in the used
   ring.
 
 2. Update the used ring index.
 
 3. Deliver an interrupt if necessary:
 
-  (a) If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated: 
-    check if the VRING_AVAIL_F_NO_INTERRUPT flag is not set in 
+  (a) If the VIRTIO_F_RING_EVENT_IDX feature is not negotiated:
+    check if the VRING_AVAIL_F_NO_INTERRUPT flag is not set in
     avail->flags.
 
-  (b) If the VIRTIO_F_RING_EVENT_IDX feature is negotiated: check 
-    whether the used index crossed the used_event field value 
-    since the last update. The used_event field wraps naturally 
+  (b) If the VIRTIO_F_RING_EVENT_IDX feature is negotiated: check
+    whether the used index crossed the used_event field value
+    since the last update. The used_event field wraps naturally
     at 65536 as well:
 	(u16)(new_idx - used_event - 1) < (u16)(new_idx - old_idx)
 
-For each ring, guest should then disable interrupts by writing 
-VRING_AVAIL_F_NO_INTERRUPT flag in avail structure, if required. 
-It can then process used ring entries finally enabling interrupts 
-by clearing the VRING_AVAIL_F_NO_INTERRUPT flag or updating the 
-EVENT_IDX field in the available structure.  The guest should then 
-execute a memory barrier, and then recheck the ring empty 
-condition. This is necessary to handle the case where after the 
-last check and before enabling interrupts, an interrupt has been 
+For each ring, guest should then disable interrupts by writing
+VRING_AVAIL_F_NO_INTERRUPT flag in avail structure, if required.
+It can then process used ring entries finally enabling interrupts
+by clearing the VRING_AVAIL_F_NO_INTERRUPT flag or updating the
+EVENT_IDX field in the available structure.  The guest should then
+execute a memory barrier, and then recheck the ring empty
+condition. This is necessary to handle the case where after the
+last check and before enabling interrupts, an interrupt has been
 suppressed by the device:
 
 	vring_disable_interrupts(vq);
-	
+
 	for (;;) {
 		if (vq->last_seen_used != vring->used.idx) {
 			vring_enable_interrupts(vq);
 			mb();
-	
+
 			if (vq->last_seen_used != vring->used.idx)
 				break;
 		}
@@ -624,16 +624,16 @@ Any PCI device with Vendor ID 0x1AF4, and Device ID 0x1000 through
 0x103F inclusive is a virtio device[3]. The device must also have a
 Revision ID of 0 to match this specification.
 
-The Subsystem Device ID indicates which virtio device is 
-supported by the device. The Subsystem Vendor ID should reflect 
-the PCI Vendor ID of the environment (it's currently only used 
+The Subsystem Device ID indicates which virtio device is
+supported by the device. The Subsystem Vendor ID should reflect
+the PCI Vendor ID of the environment (it's currently only used
 for informational purposes by the guest).
 
 2.4.1.2. PCI Device Layout
 -------------------------
 
-To configure the device, we use the first I/O region of the PCI 
-device. This contains a virtio header followed by a 
+To configure the device, we use the first I/O region of the PCI
+device. This contains a virtio header followed by a
 device-specific region.
 
 There may be different widths of accesses to the I/O region; the
@@ -642,9 +642,9 @@ used (i.e. 32-bit accesses for 32-bit fields, etc), but the
 device-specific region can be accessed using any width accesses, and
 should obtain the same results.
 
-Note that this is possible because while the virtio header is PCI 
-(i.e. little) endian, the device-specific region is encoded in 
-the native endian of the guest (where such distinction is 
+Note that this is possible because while the virtio header is PCI
+(i.e. little) endian, the device-specific region is encoded in
+the native endian of the guest (where such distinction is
 applicable).
 
 2.4.1.2.1. PCI Device Virtio Header
@@ -662,7 +662,7 @@ The virtio header looks as follows:
 +------------++---------------------+---------------------+----------+--------+---------+---------+---------+--------+
 
 
-If MSI-X is enabled for the device, two additional fields 
+If MSI-X is enabled for the device, two additional fields
 immediately follow this header:[5]
 
 
@@ -676,7 +676,7 @@ immediately follow this header:[5]
 | (MSI-X)    || Vector         | Vector |
 +------------++----------------+--------+
 
-Immediately following these general headers, there may be 
+Immediately following these general headers, there may be
 device-specific headers:
 
 +------------++--------------------+
@@ -701,70 +701,70 @@ The page size for a virtqueue on a PCI virtio device is defined as
 2.4.1.3.1.1. Queue Vector Configuration
 --------------------------------------
 
-When MSI-X capability is present and enabled in the device 
-(through standard PCI configuration space) 4 bytes at byte offset 
-20 are used to map configuration change and queue interrupts to 
-MSI-X vectors. In this case, the ISR Status field is unused, and 
-device specific configuration starts at byte offset 24 in virtio 
-header structure. When MSI-X capability is not enabled, device 
+When MSI-X capability is present and enabled in the device
+(through standard PCI configuration space) 4 bytes at byte offset
+20 are used to map configuration change and queue interrupts to
+MSI-X vectors. In this case, the ISR Status field is unused, and
+device specific configuration starts at byte offset 24 in virtio
+header structure. When MSI-X capability is not enabled, device
 specific configuration starts at byte offset 20 in virtio header.
 
-Writing a valid MSI-X Table entry number, 0 to 0x7FF, to one of 
-Configuration/Queue Vector registers, maps interrupts triggered 
-by the configuration change/selected queue events respectively to 
-the corresponding MSI-X vector. To disable interrupts for a 
-specific event type, unmap it by writing a special NO_VECTOR 
+Writing a valid MSI-X Table entry number, 0 to 0x7FF, to one of
+Configuration/Queue Vector registers, maps interrupts triggered
+by the configuration change/selected queue events respectively to
+the corresponding MSI-X vector. To disable interrupts for a
+specific event type, unmap it by writing a special NO_VECTOR
 value:
 
 	/* Vector value used to disable MSI for queue */
-	#define VIRTIO_MSI_NO_VECTOR            0xffff 
+	#define VIRTIO_MSI_NO_VECTOR            0xffff
 
-Reading these registers returns vector mapped to a given event, 
-or NO_VECTOR if unmapped. All queue and configuration change 
+Reading these registers returns vector mapped to a given event,
+or NO_VECTOR if unmapped. All queue and configuration change
 events are unmapped by default.
 
-Note that mapping an event to vector might require allocating 
-internal device resources, and might fail. Devices report such 
-failures by returning the NO_VECTOR value when the relevant 
-Vector field is read. After mapping an event to vector, the 
-driver must verify success by reading the Vector field value: on 
-success, the previously written value is returned, and on 
-failure, NO_VECTOR is returned. If a mapping failure is detected, 
+Note that mapping an event to vector might require allocating
+internal device resources, and might fail. Devices report such
+failures by returning the NO_VECTOR value when the relevant
+Vector field is read. After mapping an event to vector, the
+driver must verify success by reading the Vector field value: on
+success, the previously written value is returned, and on
+failure, NO_VECTOR is returned. If a mapping failure is detected,
 the driver can retry mapping with fewervectors, or disable MSI-X.
 
 2.4.1.3.1.2. Virtqueue Configuration
 -----------------------------------
 
-As a device can have zero or more virtqueues for bulk data 
-transport (for example, the simplest network device has two), the driver 
-needs to configure them as part of the device-specific 
+As a device can have zero or more virtqueues for bulk data
+transport (for example, the simplest network device has two), the driver
+needs to configure them as part of the device-specific
 configuration.
 
 This is done as follows, for each virtqueue a device has:
 
-1. Write the virtqueue index (first queue is 0) to the Queue 
+1. Write the virtqueue index (first queue is 0) to the Queue
   Select field.
 
-2. Read the virtqueue size from the Queue Size field, which is 
-  always a power of 2. This controls how big the virtqueue is 
-  (see "2.1.4. Virtqueues"). If this field is 0, the virtqueue does not exist. 
+2. Read the virtqueue size from the Queue Size field, which is
+  always a power of 2. This controls how big the virtqueue is
+  (see "2.1.4. Virtqueues"). If this field is 0, the virtqueue does not exist.
 
-3. Allocate and zero virtqueue in contiguous physical memory, on 
-  a 4096 byte alignment. Write the physical address, divided by 
+3. Allocate and zero virtqueue in contiguous physical memory, on
+  a 4096 byte alignment. Write the physical address, divided by
   4096 to the Queue Address field.[6]
 
-4. Optionally, if MSI-X capability is present and enabled on the 
-  device, select a vector to use to request interrupts triggered 
-  by virtqueue events. Write the MSI-X Table entry number 
-  corresponding to this vector in Queue Vector field. Read the 
-  Queue Vector field: on success, previously written value is 
+4. Optionally, if MSI-X capability is present and enabled on the
+  device, select a vector to use to request interrupts triggered
+  by virtqueue events. Write the MSI-X Table entry number
+  corresponding to this vector in Queue Vector field. Read the
+  Queue Vector field: on success, previously written value is
   returned; on failure, NO_VECTOR value is returned.
 
 2.4.1.3.2. Notifying The Device
 ------------------------------
 
-Device notification occurs by writing the 16-bit virtqueue index 
-of this virtqueue to the Queue Notify field of the virtio header 
+Device notification occurs by writing the 16-bit virtqueue index
+of this virtqueue to the Queue Notify field of the virtio header
 in the first I/O region of the PCI device.
 
 2.4.1.3.3. Virtqueue Interrupts From The Device
@@ -780,58 +780,58 @@ If an interrupt is necessary:
 
   (b) If MSI-X capability is enabled:
 
-    i. Request the appropriate MSI-X interrupt message for the 
-      device, Queue Vector field sets the MSI-X Table entry 
+    i. Request the appropriate MSI-X interrupt message for the
+      device, Queue Vector field sets the MSI-X Table entry
       number.
 
-    ii. If Queue Vector field value is NO_VECTOR, no interrupt 
+    ii. If Queue Vector field value is NO_VECTOR, no interrupt
       message is requested for this event.
 
 The guest interrupt handler should:
 
-1. If MSI-X capability is disabled: read the ISR Status field, 
-  which will reset it to zero. If the lower bit is zero, the 
-  interrupt was not for this device. Otherwise, the guest driver 
-  should look through the used rings of each virtqueue for the 
-  device, to see if any progress has been made by the device 
+1. If MSI-X capability is disabled: read the ISR Status field,
+  which will reset it to zero. If the lower bit is zero, the
+  interrupt was not for this device. Otherwise, the guest driver
+  should look through the used rings of each virtqueue for the
+  device, to see if any progress has been made by the device
   which requires servicing.
 
-2. If MSI-X capability is enabled: look through the used rings of 
-  each virtqueue mapped to the specific MSI-X vector for the 
-  device, to see if any progress has been made by the device 
+2. If MSI-X capability is enabled: look through the used rings of
+  each virtqueue mapped to the specific MSI-X vector for the
+  device, to see if any progress has been made by the device
   which requires servicing.
 
 2.4.1.3.4. Notification of Device Configuration Changes
 ------------------------------------------------------
 
-Some virtio PCI devices can change the device configuration 
-state, as reflected in the virtio header in the PCI configuration 
+Some virtio PCI devices can change the device configuration
+state, as reflected in the virtio header in the PCI configuration
 space. In this case:
 
-1. If MSI-X capability is disabled: an interrupt is delivered and 
-  the second highest bit is set in the ISR Status field to 
-  indicate that the driver should re-examine the configuration 
-  space.  Note that a single interrupt can indicate both that one 
-  or more virtqueue has been used and that the configuration 
-  space has changed: even if the config bit is set, virtqueues 
+1. If MSI-X capability is disabled: an interrupt is delivered and
+  the second highest bit is set in the ISR Status field to
+  indicate that the driver should re-examine the configuration
+  space.  Note that a single interrupt can indicate both that one
+  or more virtqueue has been used and that the configuration
+  space has changed: even if the config bit is set, virtqueues
   must be scanned.
 
-2. If MSI-X capability is enabled: an interrupt message is 
-  requested. The Configuration Vector field sets the MSI-X Table 
-  entry number to use. If Configuration Vector field value is 
+2. If MSI-X capability is enabled: an interrupt message is
+  requested. The Configuration Vector field sets the MSI-X Table
+  entry number to use. If Configuration Vector field value is
   NO_VECTOR, no interrupt message is requested for this event.
 
 2.4.2. Virtio Over MMIO
 ----------------------
 
-Virtual environments without PCI support (a common situation in 
+Virtual environments without PCI support (a common situation in
 embedded devices models) might use simple memory mapped device (“
 virtio-mmio”) instead of the PCI device.
 
-The memory mapped virtio device behaviour is based on the PCI 
-device specification. Therefore most of operations like device 
-initialization, queues configuration and buffer transfers are 
-nearly identical. Existing differences are described in the 
+The memory mapped virtio device behaviour is based on the PCI
+device specification. Therefore most of operations like device
+initialization, queues configuration and buffer transfers are
+nearly identical. Existing differences are described in the
 following sections.
 
 2.4.2.1. MMIO Device Discovery
@@ -849,154 +849,154 @@ a device-tree such as Linux's dtc or Open Firmware, the suggested format is:
 2.4.2.2. MMIO Device Layout
 --------------------------
 
-MMIO virtio devices provides a set of memory mapped control 
-registers, all 32 bits wide, followed by device-specific 
+MMIO virtio devices provides a set of memory mapped control
+registers, all 32 bits wide, followed by device-specific
 configuration space. The following list presents their layout:
 
-• Offset from the device base address | Direction | Name 
- Description 
+• Offset from the device base address | Direction | Name
+ Description
 
-• 0x000 | R | MagicValue 
- “virt” string. 
+• 0x000 | R | MagicValue
+ “virt” string.
 
-• 0x004 | R | Version 
- Device version number. Currently must be 1. 
+• 0x004 | R | Version
+ Device version number. Currently must be 1.
 
-• 0x008 | R | DeviceID 
- Virtio Subsystem Device ID (ie. 1 for network card). 
+• 0x008 | R | DeviceID
+ Virtio Subsystem Device ID (ie. 1 for network card).
 
-• 0x00c | R | VendorID 
- Virtio Subsystem Vendor ID. 
+• 0x00c | R | VendorID
+ Virtio Subsystem Vendor ID.
 
-• 0x010 | R | HostFeatures 
+• 0x010 | R | HostFeatures
  Flags representing features the device supports.
- Reading from this register returns 32 consecutive flag bits, 
-  first bit depending on the last value written to 
+ Reading from this register returns 32 consecutive flag bits,
+  first bit depending on the last value written to
   HostFeaturesSel register. Access to this register returns bits HostFeaturesSel*32
 
-   to (HostFeaturesSel*32)+31, eg. feature bits 0 to 31 if 
-  HostFeaturesSel is set to 0 and features bits 32 to 63 if 
+   to (HostFeaturesSel*32)+31, eg. feature bits 0 to 31 if
+  HostFeaturesSel is set to 0 and features bits 32 to 63 if
   HostFeaturesSel is set to 1. Also see [sub:Feature-Bits]
 
-• 0x014 | W | HostFeaturesSel 
+• 0x014 | W | HostFeaturesSel
  Device (Host) features word selection.
- Writing to this register selects a set of 32 device feature bits 
-  accessible by reading from HostFeatures register. Device driver 
-  must write a value to the HostFeaturesSel register before 
-  reading from the HostFeatures register. 
+ Writing to this register selects a set of 32 device feature bits
+  accessible by reading from HostFeatures register. Device driver
+  must write a value to the HostFeaturesSel register before
+  reading from the HostFeatures register.
 
-• 0x020 | W | GuestFeatures 
- Flags representing device features understood and activated by 
+• 0x020 | W | GuestFeatures
+ Flags representing device features understood and activated by
   the driver.
- Writing to this register sets 32 consecutive flag bits, first 
-  bit depending on the last value written to GuestFeaturesSel 
+ Writing to this register sets 32 consecutive flag bits, first
+  bit depending on the last value written to GuestFeaturesSel
   register. Access to this register sets bits GuestFeaturesSel*32
-  to (GuestFeaturesSel*32)+31, eg. feature bits 0 to 31 if 
-  GuestFeaturesSel is set to 0 and features bits 32 to 63 if 
+  to (GuestFeaturesSel*32)+31, eg. feature bits 0 to 31 if
+  GuestFeaturesSel is set to 0 and features bits 32 to 63 if
   GuestFeaturesSel is set to 1. Also see [sub:Feature-Bits]
 
-• 0x024 | W | GuestFeaturesSel 
+• 0x024 | W | GuestFeaturesSel
  Activated (Guest) features word selection.
- Writing to this register selects a set of 32 activated feature 
-  bits accessible by writing to the GuestFeatures register. 
-  Device driver must write a value to the GuestFeaturesSel 
-  register before writing to the GuestFeatures register. 
+ Writing to this register selects a set of 32 activated feature
+  bits accessible by writing to the GuestFeatures register.
+  Device driver must write a value to the GuestFeaturesSel
+  register before writing to the GuestFeatures register.
 
-• 0x028 | W | GuestPageSize 
+• 0x028 | W | GuestPageSize
  Guest page size.
- Device driver must write the guest page size in bytes to the 
-  register during initialization, before any queues are used. 
-  This value must be a power of 2 and is used by the Host to 
-  calculate Guest address of the first queue page (see QueuePFN). 
+ Device driver must write the guest page size in bytes to the
+  register during initialization, before any queues are used.
+  This value must be a power of 2 and is used by the Host to
+  calculate Guest address of the first queue page (see QueuePFN).
 
-• 0x030 | W | QueueSel 
+• 0x030 | W | QueueSel
  Virtual queue index (first queue is 0).
- Writing to this register selects the virtual queue that the 
-  following operations on QueueNum, QueueAlign and QueuePFN apply 
-  to. 
-
-• 0x034 | R | QueueNumMax 
- Maximum virtual queue size. 
- Reading from the register returns the maximum size of the queue 
-  the Host is ready to process or zero (0x0) if the queue is not 
-  available. This applies to the queue selected by writing to 
-  QueueSel and is allowed only when QueuePFN is set to zero 
-  (0x0), so when the queue is not actively used. 
-
-• 0x038 | W | QueueNum 
+ Writing to this register selects the virtual queue that the
+  following operations on QueueNum, QueueAlign and QueuePFN apply
+  to.
+
+• 0x034 | R | QueueNumMax
+ Maximum virtual queue size.
+ Reading from the register returns the maximum size of the queue
+  the Host is ready to process or zero (0x0) if the queue is not
+  available. This applies to the queue selected by writing to
+  QueueSel and is allowed only when QueuePFN is set to zero
+  (0x0), so when the queue is not actively used.
+
+• 0x038 | W | QueueNum
  Virtual queue size.
- Queue size is the number of elements in the queue, therefore size 
+ Queue size is the number of elements in the queue, therefore size
   of the descriptor table and both available and used rings.
- Writing to this register notifies the Host what size of the 
-  queue the Guest will use. This applies to the queue selected by 
-  writing to QueueSel. 
+ Writing to this register notifies the Host what size of the
+  queue the Guest will use. This applies to the queue selected by
+  writing to QueueSel.
 
-• 0x03c | W | QueueAlign 
+• 0x03c | W | QueueAlign
  Used Ring alignment in the virtual queue.
- Writing to this register notifies the Host about alignment 
-  boundary of the Used Ring in bytes. This value must be a power 
-  of 2 and applies to the queue selected by writing to QueueSel. 
+ Writing to this register notifies the Host about alignment
+  boundary of the Used Ring in bytes. This value must be a power
+  of 2 and applies to the queue selected by writing to QueueSel.
 
-• 0x040 | RW | QueuePFN 
+• 0x040 | RW | QueuePFN
  Guest physical page number of the virtual queue.
- Writing to this register notifies the host about location of the 
-  virtual queue in the Guest's physical address space. This value 
-  is the index number of a page starting with the queue 
-  Descriptor Table. Value zero (0x0) means physical address zero 
-  (0x00000000) and is illegal. When the Guest stops using the 
+ Writing to this register notifies the host about location of the
+  virtual queue in the Guest's physical address space. This value
+  is the index number of a page starting with the queue
+  Descriptor Table. Value zero (0x0) means physical address zero
+  (0x00000000) and is illegal. When the Guest stops using the
   queue it must write zero (0x0) to this register.
- Reading from this register returns the currently used page 
-  number of the queue, therefore a value other than zero (0x0) 
+ Reading from this register returns the currently used page
+  number of the queue, therefore a value other than zero (0x0)
   means that the queue is in use.
- Both read and write accesses apply to the queue selected by 
-  writing to QueueSel. 
+ Both read and write accesses apply to the queue selected by
+  writing to QueueSel.
 
-• 0x050 | W | QueueNotify 
+• 0x050 | W | QueueNotify
  Queue notifier.
- Writing a queue index to this register notifies the Host that 
-  there are new buffers to process in the queue. 
+ Writing a queue index to this register notifies the Host that
+  there are new buffers to process in the queue.
 
 • 0x60 | R | InterruptStatus
 Interrupt status.
-Reading from this register returns a bit mask of interrupts 
-  asserted by the device. An interrupt is asserted if the 
+Reading from this register returns a bit mask of interrupts
+  asserted by the device. An interrupt is asserted if the
   corresponding bit is set, ie. equals one (1).
 
   – Bit 0 | Used Ring Update
-	This interrupt is asserted when the Host has updated the Used 
+	This interrupt is asserted when the Host has updated the Used
     Ring in at least one of the active virtual queues.
 
   – Bit 1 | Configuration change
-	This interrupt is asserted when configuration of the device has 
+	This interrupt is asserted when configuration of the device has
     changed.
 
-• 0x064 | W | InterruptACK 
- Interrupt acknowledge. 
- Writing to this register notifies the Host that the Guest 
-  finished handling interrupts. Set bits in the value clear the 
-  corresponding bits of the InterruptStatus register. 
-
-• 0x070 | RW | Status 
- Device status. 
- Reading from this register returns the current device status 
-  flags. 
- Writing non-zero values to this register sets the status flags, 
-  indicating the Guest progress. Writing zero (0x0) to this 
-  register triggers a device reset. 
+• 0x064 | W | InterruptACK
+ Interrupt acknowledge.
+ Writing to this register notifies the Host that the Guest
+  finished handling interrupts. Set bits in the value clear the
+  corresponding bits of the InterruptStatus register.
+
+• 0x070 | RW | Status
+ Device status.
+ Reading from this register returns the current device status
+  flags.
+ Writing non-zero values to this register sets the status flags,
+  indicating the Guest progress. Writing zero (0x0) to this
+  register triggers a device reset.
  Also see [sub:Device-Initialization-Sequence]
 
-• 0x100+ | RW | Config 
- Device-specific configuration space starts at an offset 0x100 
-  and is accessed with byte alignment. Its meaning and size 
-  depends on the device and the driver. 
+• 0x100+ | RW | Config
+ Device-specific configuration space starts at an offset 0x100
+  and is accessed with byte alignment. Its meaning and size
+  depends on the device and the driver.
 
-Virtual queue size is the number of elements in the queue, 
-therefore size of the descriptor table and both available and 
+Virtual queue size is the number of elements in the queue,
+therefore size of the descriptor table and both available and
 used rings.
 
-The endianness of the registers follows the native endianness of 
-the Guest. Writing to registers described as “R” and reading from 
-registers described as “W” is not permitted and can cause 
+The endianness of the registers follows the native endianness of
+the Guest. Writing to registers described as “R” and reading from
+registers described as “W” is not permitted and can cause
 undefined behavior.
 
 2.4.2.3. MMIO-specific Initialization And Device Operation
@@ -1012,29 +1012,29 @@ done before the virtqueues are configured.
 2.4.2.3.1.1. Virtqueue Configuration
 -----------------------------------
 
-1. Select the queue writing its index (first queue is 0) to the 
-  QueueSel register. 
+1. Select the queue writing its index (first queue is 0) to the
+  QueueSel register.
 
-2. Check if the queue is not already in use: read QueuePFN 
-  register, returned value should be zero (0x0). 
+2. Check if the queue is not already in use: read QueuePFN
+  register, returned value should be zero (0x0).
 
-3. Read maximum queue size (number of elements) from the 
-  QueueNumMax register. If the returned value is zero (0x0) the 
-  queue is not available. 
+3. Read maximum queue size (number of elements) from the
+  QueueNumMax register. If the returned value is zero (0x0) the
+  queue is not available.
 
-4. Allocate and zero the queue pages in contiguous virtual 
-  memory, aligning the Used Ring to an optimal boundary (usually 
-  page size). Size of the allocated queue may be smaller than or 
-  equal to the maximum size returned by the Host. 
+4. Allocate and zero the queue pages in contiguous virtual
+  memory, aligning the Used Ring to an optimal boundary (usually
+  page size). Size of the allocated queue may be smaller than or
+  equal to the maximum size returned by the Host.
 
-5. Notify the Host about the queue size by writing the size to 
-  QueueNum register. 
+5. Notify the Host about the queue size by writing the size to
+  QueueNum register.
 
-6. Notify the Host about the used alignment by writing its value 
-  in bytes to QueueAlign register. 
+6. Notify the Host about the used alignment by writing its value
+  in bytes to QueueAlign register.
 
-7. Write the physical number of the first page of the queue to 
-  the QueuePFN register. 
+7. Write the physical number of the first page of the queue to
+  the QueuePFN register.
 
 2.4.2.3.2. Notifying The Device
 ------------------------------
@@ -1045,14 +1045,14 @@ writing the queue index to register QueueNum.
 2.4.2.3.3. Receiving Used Buffers From The Device
 ------------------------------------------------
 
-The memory mapped virtio device is using single, dedicated 
-interrupt signal, which is raised when at least one of the 
-interrupts described in the InterruptStatus register 
-description is asserted. After receiving an interrupt, the 
-driver must read the InterruptStatus register to check what 
-caused the interrupt (see the register description). After the 
-interrupt is handled, the driver must acknowledge it by writing 
-a bit mask corresponding to the serviced interrupt to the 
+The memory mapped virtio device is using single, dedicated
+interrupt signal, which is raised when at least one of the
+interrupts described in the InterruptStatus register
+description is asserted. After receiving an interrupt, the
+driver must read the InterruptStatus register to check what
+caused the interrupt (see the register description). After the
+interrupt is handled, the driver must acknowledge it by writing
+a bit mask corresponding to the serviced interrupt to the
 InterruptACK register.
 
 2.4.2.4.4. Notification of Device Configuration Changes
@@ -1105,13 +1105,13 @@ Discovering what devices are available and their type is bus-dependent.
 2.5.1. Network Device
 ====================
 
-The virtio network device is a virtual ethernet card, and is the 
-most complex of the devices supported so far by virtio. It has 
-enhanced rapidly and demonstrates clearly how support for new 
-features should be added to an existing device. Empty buffers are 
-placed in one virtqueue for receiving packets, and outgoing 
-packets are enqueued into another for transmission in that order. 
-A third command queue is used to control advanced filtering 
+The virtio network device is a virtual ethernet card, and is the
+most complex of the devices supported so far by virtio. It has
+enhanced rapidly and demonstrates clearly how support for new
+features should be added to an existing device. Empty buffers are
+placed in one virtqueue for receiving packets, and outgoing
+packets are enqueued into another for transmission in that order.
+A third command queue is used to control advanced filtering
 features.
 
 2.5.1.1. Device ID
@@ -1126,7 +1126,7 @@ features.
 
  Virtqueue 2 only exists if VIRTIO_NET_F_CTRL_VQ set.
 
-2.5.1.3. Feature bits 
+2.5.1.3. Feature bits
 --------------------
 
   VIRTIO_NET_F_CSUM (0) Device handles packets with partial checksum
@@ -1138,8 +1138,8 @@ features.
 
   VIRTIO_NET_F_MAC (5) Device has given MAC address.
 
-  VIRTIO_NET_F_GSO (6) (Deprecated) device handles packets with 
-    any GSO type.[13] 
+  VIRTIO_NET_F_GSO (6) (Deprecated) device handles packets with
+    any GSO type.[13]
 
   VIRTIO_NET_F_GUEST_TSO4 (7) Guest can receive TSOv4.
 
@@ -1159,7 +1159,7 @@ features.
 
   VIRTIO_NET_F_MRG_RXBUF (15) Guest can merge receive buffers.
 
-  VIRTIO_NET_F_STATUS (16) Configuration status field is 
+  VIRTIO_NET_F_STATUS (16) Configuration status field is
     available.
 
   VIRTIO_NET_F_CTRL_VQ (17) Control channel is available.
@@ -1168,14 +1168,14 @@ features.
 
   VIRTIO_NET_F_CTRL_VLAN (19) Control channel VLAN filtering.
 
-  VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous 
+  VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous
     packets.
 
-  Device configuration layout Two configuration fields are 
-  currently defined. The mac address field always exists (though 
-  is only valid if VIRTIO_NET_F_MAC is set), and the status field 
-  only exists if VIRTIO_NET_F_STATUS is set. Two read-only bits 
-  are currently defined for the status field: 
+  Device configuration layout Two configuration fields are
+  currently defined. The mac address field always exists (though
+  is only valid if VIRTIO_NET_F_MAC is set), and the status field
+  only exists if VIRTIO_NET_F_STATUS is set. Two read-only bits
+  are currently defined for the status field:
   VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE.
 
 	#define VIRTIO_NET_S_LINK_UP	1
@@ -1189,27 +1189,27 @@ features.
 2.5.1.4. Device Initialization
 -----------------------------
 
-1. The initialization routine should identify the receive and 
+1. The initialization routine should identify the receive and
   transmission virtqueues.
 
-2. If the VIRTIO_NET_F_MAC feature bit is set, the configuration 
-  space “mac” entry indicates the “physical” address of the the 
-  network card, otherwise a private MAC address should be 
-  assigned. All guests are expected to negotiate this feature if 
+2. If the VIRTIO_NET_F_MAC feature bit is set, the configuration
+  space “mac” entry indicates the “physical” address of the the
+  network card, otherwise a private MAC address should be
+  assigned. All guests are expected to negotiate this feature if
   it is set.
 
-3. If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated, 
+3. If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated,
   identify the control virtqueue.
 
-4. If the VIRTIO_NET_F_STATUS feature bit is negotiated, the link 
-  status can be read from the bottom bit of the “status” config 
+4. If the VIRTIO_NET_F_STATUS feature bit is negotiated, the link
+  status can be read from the bottom bit of the “status” config
   field. Otherwise, the link should be assumed active.
 
-5. The receive virtqueue should be filled with receive buffers. 
-  This is described in detail below in “Setting Up Receive 
+5. The receive virtqueue should be filled with receive buffers.
+  This is described in detail below in “Setting Up Receive
   Buffers”.
 
-6. A driver can indicate that it will generate checksumless 
+6. A driver can indicate that it will generate checksumless
   packets by negotating the VIRTIO_NET_F_CSUM feature. This “
   checksum offload” is a common feature on modern network cards.
 
@@ -1221,20 +1221,20 @@ features.
   Notification bit set, unless the VIRTIO_NET_F_HOST_ECN feature is
   negotiated.[15]
 
-8. The converse features are also available: a driver can save 
+8. The converse features are also available: a driver can save
   the virtual device some work by negotiating these features.[16]
-   The VIRTIO_NET_F_GUEST_CSUM feature indicates that partially 
-  checksummed packets can be received, and if it can do that then 
-  the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6, 
-  VIRTIO_NET_F_GUEST_UFO and VIRTIO_NET_F_GUEST_ECN are the input 
-  equivalents of the features described above. See “Receiving 
+   The VIRTIO_NET_F_GUEST_CSUM feature indicates that partially
+  checksummed packets can be received, and if it can do that then
+  the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6,
+  VIRTIO_NET_F_GUEST_UFO and VIRTIO_NET_F_GUEST_ECN are the input
+  equivalents of the features described above. See “Receiving
   Packets” below.
 
 2.5.1.5. Device Operation
 ------------------------
 
-Packets are transmitted by placing them in the transmitq, and 
-buffers for incoming packets are placed in the receiveq. In each 
+Packets are transmitted by placing them in the transmitq, and
+buffers for incoming packets are placed in the receiveq. In each
 case, the packet itself is preceeded by a header:
 
 	struct virtio_net_hdr {
@@ -1254,18 +1254,18 @@ case, the packet itself is preceeded by a header:
 		u16 num_buffers;
 	};
 
-The controlq is used to control device features such as 
+The controlq is used to control device features such as
 filtering.
 
 2.5.1.5.1. Packet Transmission
 -----------------------------
 
-Transmitting a single packet is simple, but varies depending on 
+Transmitting a single packet is simple, but varies depending on
 the different features the driver negotiated.
 
-1. If the driver negotiated VIRTIO_NET_F_CSUM, and the packet has 
-  not been fully checksummed, then the virtio_net_hdr's fields 
-  are set as follows. Otherwise, the packet must be fully 
+1. If the driver negotiated VIRTIO_NET_F_CSUM, and the packet has
+  not been fully checksummed, then the virtio_net_hdr's fields
+  are set as follows. Otherwise, the packet must be fully
   checksummed, and flags is zero.
 
   • flags has the VIRTIO_NET_HDR_F_NEEDS_CSUM set,
@@ -1273,30 +1273,30 @@ the different features the driver negotiated.
   • csum_start is set to the offset within the packet to begin checksumming,
     and
 
-  • csum_offset indicates how many bytes after the csum_start the 
+  • csum_offset indicates how many bytes after the csum_start the
     new (16 bit ones' complement) checksum should be placed.[17]
 
-2. If the driver negotiated 
-  VIRTIO_NET_F_HOST_TSO4, TSO6 or UFO, and the packet requires 
-  TCP segmentation or UDP fragmentation, then the “gso_type” 
-  field is set to VIRTIO_NET_HDR_GSO_TCPV4, TCPV6 or UDP. 
-  (Otherwise, it is set to VIRTIO_NET_HDR_GSO_NONE). In this 
-  case, packets larger than 1514 bytes can be transmitted: the 
-  metadata indicates how to replicate the packet header to cut it 
+2. If the driver negotiated
+  VIRTIO_NET_F_HOST_TSO4, TSO6 or UFO, and the packet requires
+  TCP segmentation or UDP fragmentation, then the “gso_type”
+  field is set to VIRTIO_NET_HDR_GSO_TCPV4, TCPV6 or UDP.
+  (Otherwise, it is set to VIRTIO_NET_HDR_GSO_NONE). In this
+  case, packets larger than 1514 bytes can be transmitted: the
+  metadata indicates how to replicate the packet header to cut it
   into smaller packets. The other gso fields are set:
 
-  • hdr_len is a hint to the device as to how much of the header 
-    needs to be kept to copy into each packet, usually set to the 
+  • hdr_len is a hint to the device as to how much of the header
+    needs to be kept to copy into each packet, usually set to the
     length of the headers, including the transport header.[18]
 
-  • gso_size is the maximum size of each packet beyond that 
+  • gso_size is the maximum size of each packet beyond that
     header (ie. MSS).
 
-  • If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature, 
-    the VIRTIO_NET_HDR_GSO_ECN bit may be set in “gso_type” as 
+  • If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature,
+    the VIRTIO_NET_HDR_GSO_ECN bit may be set in “gso_type” as
     well, indicating that the TCP packet has the ECN bit set.[19]
 
-3. If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature, 
+3. If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
   the num_buffers field is set to zero.
 
 4. The header and packet are added as one output buffer to the
@@ -1309,71 +1309,71 @@ the different features the driver negotiated.
 Often a driver will suppress transmission interrupts using the
 VRING_AVAIL_F_NO_INTERRUPT flag (see "2.4.2. Receiving Used Buffers From
 The Device") and check for used packets in the transmit path of following
-packets. However, it will still receive interrupts if the 
-VIRTIO_F_NOTIFY_ON_EMPTY feature is negotiated, indicating that 
+packets. However, it will still receive interrupts if the
+VIRTIO_F_NOTIFY_ON_EMPTY feature is negotiated, indicating that
 the transmission queue is completely emptied.
 
-The normal behavior in this interrupt handler is to retrieve and 
-new descriptors from the used ring and free the corresponding 
+The normal behavior in this interrupt handler is to retrieve and
+new descriptors from the used ring and free the corresponding
 headers and packets.
 
 2.5.1.5.2. Setting Up Receive Buffers
 
-It is generally a good idea to keep the receive virtqueue as 
-fully populated as possible: if it runs out, network performance 
+It is generally a good idea to keep the receive virtqueue as
+fully populated as possible: if it runs out, network performance
 will suffer.
 
-If the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or 
-VIRTIO_NET_F_GUEST_UFO features are used, the Guest will need to 
-accept packets of up to 65550 bytes long (the maximum size of a 
-TCP or UDP packet, plus the 14 byte ethernet header), otherwise 
-1514. bytes. So unless VIRTIO_NET_F_MRG_RXBUF is negotiated, every 
+If the VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6 or
+VIRTIO_NET_F_GUEST_UFO features are used, the Guest will need to
+accept packets of up to 65550 bytes long (the maximum size of a
+TCP or UDP packet, plus the 14 byte ethernet header), otherwise
+1514. bytes. So unless VIRTIO_NET_F_MRG_RXBUF is negotiated, every
 buffer in the receive queue needs to be at least this length [20a]
 
-If VIRTIO_NET_F_MRG_RXBUF is negotiated, each buffer must be at 
+If VIRTIO_NET_F_MRG_RXBUF is negotiated, each buffer must be at
 least the size of the struct virtio_net_hdr.
 
 2.5.1.5.2.1. Packet Receive Interrupt
 ------------------------------------
 
-When a packet is copied into a buffer in the receiveq, the 
-optimal path is to disable further interrupts for the receiveq 
-(see [sub:Receiving-Used-Buffers]) and process packets until no 
+When a packet is copied into a buffer in the receiveq, the
+optimal path is to disable further interrupts for the receiveq
+(see [sub:Receiving-Used-Buffers]) and process packets until no
 more are found, then re-enable them.
 
 Processing packet involves:
 
-1. If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature, 
-  then the “num_buffers” field indicates how many descriptors 
-  this packet is spread over (including this one). This allows 
-  receipt of large packets without having to allocate large 
-  buffers. In this case, there will be at least “num_buffers” in 
-  the used ring, and they should be chained together to form a 
-  single packet. The other buffers will not begin with a struct 
+1. If the driver negotiated the VIRTIO_NET_F_MRG_RXBUF feature,
+  then the “num_buffers” field indicates how many descriptors
+  this packet is spread over (including this one). This allows
+  receipt of large packets without having to allocate large
+  buffers. In this case, there will be at least “num_buffers” in
+  the used ring, and they should be chained together to form a
+  single packet. The other buffers will not begin with a struct
   virtio_net_hdr.
 
-2. If the VIRTIO_NET_F_MRG_RXBUF feature was not negotiated, or 
-  the “num_buffers” field is one, then the entire packet will be 
-  contained within this buffer, immediately following the struct 
+2. If the VIRTIO_NET_F_MRG_RXBUF feature was not negotiated, or
+  the “num_buffers” field is one, then the entire packet will be
+  contained within this buffer, immediately following the struct
   virtio_net_hdr.
 
-3. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the 
-  VIRTIO_NET_HDR_F_NEEDS_CSUM bit in the “flags” field may be 
+3. If the VIRTIO_NET_F_GUEST_CSUM feature was negotiated, the
+  VIRTIO_NET_HDR_F_NEEDS_CSUM bit in the “flags” field may be
   set: if so, the checksum on the packet is incomplete and the “
-  csum_start” and “csum_offset” fields indicate how to calculate 
+  csum_start” and “csum_offset” fields indicate how to calculate
   it (see Packet Transmission point 1).
 
-4. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were 
-  negotiated, then the “gso_type” may be something other than 
-  VIRTIO_NET_HDR_GSO_NONE, and the “gso_size” field indicates the 
+4. If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were
+  negotiated, then the “gso_type” may be something other than
+  VIRTIO_NET_HDR_GSO_NONE, and the “gso_size” field indicates the
   desired MSS (see Packet Transmission point 2).
 
 2.5.1.5.3. Control Virtqueue
 ---------------------------
 
-The driver uses the control virtqueue (if VIRTIO_NET_F_VTRL_VQ is 
-negotiated) to send commands to manipulate various features of 
-the device which would not easily map into the configuration 
+The driver uses the control virtqueue (if VIRTIO_NET_F_VTRL_VQ is
+negotiated) to send commands to manipulate various features of
+the device which would not easily map into the configuration
 space.
 
 All commands are of the following form:
@@ -1387,33 +1387,33 @@ All commands are of the following form:
 
 	/* ack values */
 	#define VIRTIO_NET_OK     0
-	#define VIRTIO_NET_ERR    1 
+	#define VIRTIO_NET_ERR    1
 
-The class, command and command-specific-data are set by the 
-driver, and the device sets the ack byte. There is little it can 
-do except issue a diagnostic if the ack byte is not 
+The class, command and command-specific-data are set by the
+driver, and the device sets the ack byte. There is little it can
+do except issue a diagnostic if the ack byte is not
 VIRTIO_NET_OK.
 
 2.5.1.5.3.1. Packet Receive Filtering
 ------------------------------------
 
-If the VIRTIO_NET_F_CTRL_RX feature is negotiated, the driver can 
-send control commands for promiscuous mode, multicast receiving, 
+If the VIRTIO_NET_F_CTRL_RX feature is negotiated, the driver can
+send control commands for promiscuous mode, multicast receiving,
 and filtering of MAC addresses.
 
-Note that in general, these commands are best-effort: unwanted 
-packets may still arrive. 
+Note that in general, these commands are best-effort: unwanted
+packets may still arrive.
 
 Setting Promiscuous Mode
 
 	#define VIRTIO_NET_CTRL_RX    0
 	 #define VIRTIO_NET_CTRL_RX_PROMISC      0
-	 #define VIRTIO_NET_CTRL_RX_ALLMULTI     1 
+	 #define VIRTIO_NET_CTRL_RX_ALLMULTI     1
 
-The class VIRTIO_NET_CTRL_RX has two commands: 
-VIRTIO_NET_CTRL_RX_PROMISC turns promiscuous mode on and off, and 
-VIRTIO_NET_CTRL_RX_ALLMULTI turns all-multicast receive on and 
-off. The command-specific-data is one byte containing 0 (off) or 
+The class VIRTIO_NET_CTRL_RX has two commands:
+VIRTIO_NET_CTRL_RX_PROMISC turns promiscuous mode on and off, and
+VIRTIO_NET_CTRL_RX_ALLMULTI turns all-multicast receive on and
+off. The command-specific-data is one byte containing 0 (off) or
 1 (on).
 
 2.5.1.5.3.2. Setting MAC Address Filtering
@@ -1425,7 +1425,7 @@ off. The command-specific-data is one byte containing 0 (off) or
 	};
 
 	#define VIRTIO_NET_CTRL_MAC    1
-	 #define VIRTIO_NET_CTRL_MAC_TABLE_SET        0 
+	 #define VIRTIO_NET_CTRL_MAC_TABLE_SET        0
 
 The device can filter incoming packets by any number of destination
 MAC addresses.[21] This table is set using the class
@@ -1437,45 +1437,45 @@ contains multicast addresses.
 2.5.1.5.3.3. VLAN Filtering
 --------------------------
 
-If the driver negotiates the VIRTION_NET_F_CTRL_VLAN feature, it 
+If the driver negotiates the VIRTION_NET_F_CTRL_VLAN feature, it
 can control a VLAN filter table in the device.
 
 	#define VIRTIO_NET_CTRL_VLAN       2
 	 #define VIRTIO_NET_CTRL_VLAN_ADD             0
-	 #define VIRTIO_NET_CTRL_VLAN_DEL             1 
+	 #define VIRTIO_NET_CTRL_VLAN_DEL             1
 
-Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL 
+Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL
 command take a 16-bit VLAN id as the command-specific-data.
 
 2.5.1.5.3.4. Gratuitous Packet Sending
 -------------------------------------
 
-If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE (depends 
-on VIRTIO_NET_F_CTRL_VQ), it can ask the guest to send gratuitous 
-packets; this is usually done after the guest has been physically 
-migrated, and needs to announce its presence on the new network 
-links. (As hypervisor does not have the knowledge of guest 
-network configuration (eg. tagged vlan) it is simplest to prod 
+If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE (depends
+on VIRTIO_NET_F_CTRL_VQ), it can ask the guest to send gratuitous
+packets; this is usually done after the guest has been physically
+migrated, and needs to announce its presence on the new network
+links. (As hypervisor does not have the knowledge of guest
+network configuration (eg. tagged vlan) it is simplest to prod
 the guest in this way).
 
 	#define VIRTIO_NET_CTRL_ANNOUNCE       3
 	 #define VIRTIO_NET_CTRL_ANNOUNCE_ACK             0
 
-The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status 
-field when it notices the changes of device configuration. The 
-command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that 
-driver has recevied the notification and device would clear the 
-VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received 
+The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status
+field when it notices the changes of device configuration. The
+command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that
+driver has recevied the notification and device would clear the
+VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received
 this command.
 
 Processing this notification involves:
 
-1. Sending the gratuitous packets or marking there are pending 
-  gratuitous packets to be sent and letting deferred routine to 
+1. Sending the gratuitous packets or marking there are pending
+  gratuitous packets to be sent and letting deferred routine to
   send them.
 
-2. Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control 
-  vq. 
+2. Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control
+  vq.
 
 2.5.1.5.3.4. Offloads State Configuration
 -------------------------------------
@@ -1514,9 +1514,9 @@ change of specific offload state.
 2.5.2. Block Device
 ==================
 
-The virtio block device is a simple virtual block device (ie. 
-disk). Read and write requests (and other exotic requests) are 
-placed in the queue, and serviced (probably out of order) by the 
+The virtio block device is a simple virtual block device (ie.
+disk). Read and write requests (and other exotic requests) are
+placed in the queue, and serviced (probably out of order) by the
 device except where noted.
 
 2.5.2.1. Device ID
@@ -1532,10 +1532,10 @@ device except where noted.
 
   VIRTIO_BLK_F_BARRIER (0) Host supports request barriers.
 
-  VIRTIO_BLK_F_SIZE_MAX (1) Maximum size of any single segment is 
+  VIRTIO_BLK_F_SIZE_MAX (1) Maximum size of any single segment is
     in “size_max”.
 
-  VIRTIO_BLK_F_SEG_MAX (2) Maximum number of segments in a 
+  VIRTIO_BLK_F_SEG_MAX (2) Maximum number of segments in a
     request is in “seg_max”.
 
   VIRTIO_BLK_F_GEOMETRY (4) Disk-style geometry specified in “
@@ -1549,9 +1549,9 @@ device except where noted.
 
   VIRTIO_BLK_F_FLUSH (9) Cache flush command support.
 
-  Device configuration layout The capacity of the device 
-  (expressed in 512-byte sectors) is always present. The 
-  availability of the others all depend on various feature bits 
+  Device configuration layout The capacity of the device
+  (expressed in 512-byte sectors) is always present. The
+  availability of the others all depend on various feature bits
   as indicated above.
 
 	struct virtio_blk_config {
@@ -1569,23 +1569,23 @@ device except where noted.
 2.5.2.4. Device Initialization
 -----------------------------
 
-1. The device size should be read from the “capacity” 
-  configuration field. No requests should be submitted which goes 
+1. The device size should be read from the “capacity”
+  configuration field. No requests should be submitted which goes
   beyond this limit.
 
-2. If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated, the 
-  blk_size field can be read to determine the optimal sector size 
-  for the driver to use. This does not effect the units used in 
-  the protocol (always 512 bytes), but awareness of the correct 
+2. If the VIRTIO_BLK_F_BLK_SIZE feature is negotiated, the
+  blk_size field can be read to determine the optimal sector size
+  for the driver to use. This does not effect the units used in
+  the protocol (always 512 bytes), but awareness of the correct
   value can effect performance.
 
-3. If the VIRTIO_BLK_F_RO feature is set by the device, any write 
+3. If the VIRTIO_BLK_F_RO feature is set by the device, any write
   requests will fail.
 
 2.5.2.5. Device Operation
 ------------------------
 
-The driver queues requests to the virtqueue, and they are used by 
+The driver queues requests to the virtqueue, and they are used by
 the device (not necessarily in order). Each request is of form:
 
 	struct virtio_blk_req {
@@ -1596,7 +1596,7 @@ the device (not necessarily in order). Each request is of form:
 		u8 status;
 	};
 
-If the device has VIRTIO_BLK_F_SCSI feature, it can also support 
+If the device has VIRTIO_BLK_F_SCSI feature, it can also support
 scsi packet command requests, each of these requests is of form:
 
 	struct virtio_scsi_pc_req {
@@ -1634,71 +1634,71 @@ flush the host cache.
 	#define VIRTIO_BLK_T_FLUSH_OUT    5
 	#define VIRTIO_BLK_T_BARRIER	 0x80000000
 
-The ioprio field is a hint about the relative priorities of 
-requests to the device: higher numbers indicate more important 
+The ioprio field is a hint about the relative priorities of
+requests to the device: higher numbers indicate more important
 requests.
 
-The sector number indicates the offset (multiplied by 512) where 
-the read or write is to occur. This field is unused and set to 0 
+The sector number indicates the offset (multiplied by 512) where
+the read or write is to occur. This field is unused and set to 0
 for scsi packet commands and for flush commands.
 
-The cmd field is only present for scsi packet command requests, 
-and indicates the command to perform. This field must reside in a 
-single, separate read-only buffer; command length can be derived 
-from the length of this buffer. 
+The cmd field is only present for scsi packet command requests,
+and indicates the command to perform. This field must reside in a
+single, separate read-only buffer; command length can be derived
+from the length of this buffer.
 
-Note that these first three (four for scsi packet commands) 
-fields are always read-only: the data field is either read-only 
-or write-only, depending on the request. The size of the read or 
+Note that these first three (four for scsi packet commands)
+fields are always read-only: the data field is either read-only
+or write-only, depending on the request. The size of the read or
 write can be derived from the total size of the request buffers.
 
-The sense field is only present for scsi packet command requests, 
+The sense field is only present for scsi packet command requests,
 and indicates the buffer for scsi sense data.
 
-The data_len field is only present for scsi packet command 
-requests, this field is deprecated, and should be ignored by the 
+The data_len field is only present for scsi packet command
+requests, this field is deprecated, and should be ignored by the
 driver. Historically, devices copied data length there.
 
-The sense_len field is only present for scsi packet command 
-requests and indicates the number of bytes actually written to 
+The sense_len field is only present for scsi packet command
+requests and indicates the number of bytes actually written to
 the sense buffer.
 
-The residual field is only present for scsi packet command 
-requests and indicates the residual size, calculated as data 
+The residual field is only present for scsi packet command
+requests and indicates the residual size, calculated as data
 length - number of bytes actually transferred.
 
-The final status byte is written by the device: either 
-VIRTIO_BLK_S_OK for success, VIRTIO_BLK_S_IOERR for host or guest 
+The final status byte is written by the device: either
+VIRTIO_BLK_S_OK for success, VIRTIO_BLK_S_IOERR for host or guest
 error or VIRTIO_BLK_S_UNSUPP for a request unsupported by host:
 
 	#define VIRTIO_BLK_S_OK        0
 	#define VIRTIO_BLK_S_IOERR     1
 	#define VIRTIO_BLK_S_UNSUPP    2
 
-Historically, devices assumed that the fields type, ioprio and 
-sector reside in a single, separate read-only buffer; the fields 
-errors, data_len, sense_len and residual reside in a single, 
-separate write-only buffer; the sense field in a separate 
-write-only buffer of size 96 bytes, by itself; the fields errors, 
-data_len, sense_len and residual in a single write-only buffer; 
-and the status field is a separate read-only buffer of size 1 
+Historically, devices assumed that the fields type, ioprio and
+sector reside in a single, separate read-only buffer; the fields
+errors, data_len, sense_len and residual reside in a single,
+separate write-only buffer; the sense field in a separate
+write-only buffer of size 96 bytes, by itself; the fields errors,
+data_len, sense_len and residual in a single write-only buffer;
+and the status field is a separate read-only buffer of size 1
 byte, by itself.
 
 
 2.5.3. Console Device
 ====================
 
-The virtio console device is a simple device for data input and 
-output. A device may have one or more ports. Each port has a pair 
-of input and output virtqueues. Moreover, a device has a pair of 
-control IO virtqueues. The control virtqueues are used to 
-communicate information between the device and the driver about 
-ports being opened and closed on either side of the connection, 
-indication from the host about whether a particular port is a 
-console port, adding new ports, port hot-plug/unplug, etc., and 
-indication from the guest about whether a port or a device was 
-successfully added, port open/close, etc.. For data IO, one or 
-more empty buffers are placed in the receive queue for incoming 
+The virtio console device is a simple device for data input and
+output. A device may have one or more ports. Each port has a pair
+of input and output virtqueues. Moreover, a device has a pair of
+control IO virtqueues. The control virtqueues are used to
+communicate information between the device and the driver about
+ports being opened and closed on either side of the connection,
+indication from the host about whether a particular port is a
+console port, adding new ports, port hot-plug/unplug, etc., and
+indication from the guest about whether a port or a device was
+successfully added, port open/close, etc.. For data IO, one or
+more empty buffers are placed in the receive queue for incoming
 data and outgoing characters are placed in the transmit queue.
 
 2.5.3.1. Device ID
@@ -1709,7 +1709,7 @@ data and outgoing characters are placed in the transmit queue.
 2.5.3.2. Virtqueues
 ------------------
 
-   0:receiveq(port0). 1:transmitq(port0), 2:control receiveq, 3:control transmitq, 4:receiveq(port1), 5:transmitq(port1), 
+   0:receiveq(port0). 1:transmitq(port0), 2:control receiveq, 3:control transmitq, 4:receiveq(port1), 5:transmitq(port1),
   ...
 
   Ports 2 onwards only exist if VIRTIO_CONSOLE_F_MULTIPORT is set.
@@ -1717,20 +1717,20 @@ data and outgoing characters are placed in the transmit queue.
 2.5.3.3. Feature bits
 --------------------
 
-  VIRTIO_CONSOLE_F_SIZE (0) Configuration cols and rows fields 
+  VIRTIO_CONSOLE_F_SIZE (0) Configuration cols and rows fields
     are valid.
 
-  VIRTIO_CONSOLE_F_MULTIPORT(1) Device has support for multiple 
-    ports; configuration fields nr_ports and max_nr_ports are 
+  VIRTIO_CONSOLE_F_MULTIPORT(1) Device has support for multiple
+    ports; configuration fields nr_ports and max_nr_ports are
     valid and control virtqueues will be used.
 
 2.5.3.4. Device configuration layout
 -----------------------------------
 
-  The size of the console is supplied 
-  in the configuration space if the VIRTIO_CONSOLE_F_SIZE feature 
-  is set. Furthermore, if the VIRTIO_CONSOLE_F_MULTIPORT feature 
-  is set, the maximum number of ports supported by the device can 
+  The size of the console is supplied
+  in the configuration space if the VIRTIO_CONSOLE_F_SIZE feature
+  is set. Furthermore, if the VIRTIO_CONSOLE_F_MULTIPORT feature
+  is set, the maximum number of ports supported by the device can
   be fetched.
 
 	struct virtio_console_config {
@@ -1742,52 +1742,52 @@ data and outgoing characters are placed in the transmit queue.
 2.5.3.5. Device Initialization
 -----------------------------
 
-1. If the VIRTIO_CONSOLE_F_SIZE feature is negotiated, the driver 
+1. If the VIRTIO_CONSOLE_F_SIZE feature is negotiated, the driver
   can read the console dimensions from the configuration fields.
 
-2. If the VIRTIO_CONSOLE_F_MULTIPORT feature is negotiated, the 
-  driver can spawn multiple ports, not all of which may be 
-  attached to a console. Some could be generic ports. In this 
-  case, the control virtqueues are enabled and according to the 
-  max_nr_ports configuration-space value, the appropriate number 
-  of virtqueues are created. A control message indicating the 
-  driver is ready is sent to the host. The host can then send 
-  control messages for adding new ports to the device. After 
-  creating and initializing each port, a 
-  VIRTIO_CONSOLE_PORT_READY control message is sent to the host 
-  for that port so the host can let us know of any additional 
+2. If the VIRTIO_CONSOLE_F_MULTIPORT feature is negotiated, the
+  driver can spawn multiple ports, not all of which may be
+  attached to a console. Some could be generic ports. In this
+  case, the control virtqueues are enabled and according to the
+  max_nr_ports configuration-space value, the appropriate number
+  of virtqueues are created. A control message indicating the
+  driver is ready is sent to the host. The host can then send
+  control messages for adding new ports to the device. After
+  creating and initializing each port, a
+  VIRTIO_CONSOLE_PORT_READY control message is sent to the host
+  for that port so the host can let us know of any additional
   configuration options set for that port.
 
-3. The receiveq for each port is populated with one or more 
+3. The receiveq for each port is populated with one or more
   receive buffers.
 
 2.5.3.6. Device Operation
 ------------------------
 
-1. For output, a buffer containing the characters is placed in 
+1. For output, a buffer containing the characters is placed in
   the port's transmitq.[25]
 
-2. When a buffer is used in the receiveq (signalled by an 
-  interrupt), the contents is the input to the port associated 
+2. When a buffer is used in the receiveq (signalled by an
+  interrupt), the contents is the input to the port associated
   with the virtqueue for which the notification was received.
 
-3. If the driver negotiated the VIRTIO_CONSOLE_F_SIZE feature, a 
-  configuration change interrupt may occur. The updated size can 
+3. If the driver negotiated the VIRTIO_CONSOLE_F_SIZE feature, a
+  configuration change interrupt may occur. The updated size can
   be read from the configuration fields.
 
-4. If the driver negotiated the VIRTIO_CONSOLE_F_MULTIPORT 
-  feature, active ports are announced by the host using the 
-  VIRTIO_CONSOLE_PORT_ADD control message. The same message is 
+4. If the driver negotiated the VIRTIO_CONSOLE_F_MULTIPORT
+  feature, active ports are announced by the host using the
+  VIRTIO_CONSOLE_PORT_ADD control message. The same message is
   used for port hot-plug as well.
 
-5. If the host specified a port `name', a sysfs attribute is 
-  created with the name filled in, so that udev rules can be 
-  written that can create a symlink from the port's name to the 
+5. If the host specified a port `name', a sysfs attribute is
+  created with the name filled in, so that udev rules can be
+  written that can create a symlink from the port's name to the
   char device for port discovery by applications in the guest.
 
-6. Changes to ports' state are effected by control messages. 
-  Appropriate action is taken on the port indicated in the 
-  control message. The layout of the structure of the control 
+6. Changes to ports' state are effected by control messages.
+  Appropriate action is taken on the port indicated in the
+  control message. The layout of the structure of the control
   buffer and the events associated are:
 
 	struct virtio_console_control {
@@ -1809,7 +1809,7 @@ data and outgoing characters are placed in the transmit queue.
 2.5.4. Entropy Device
 ====================
 
-The virtio entropy device supplies high-quality randomness for 
+The virtio entropy device supplies high-quality randomness for
 guest use.
 
 2.5.4.1. Device ID
@@ -1836,19 +1836,19 @@ guest use.
 2.5.4.6. Device Operation
 ------------------------
 
-When the driver requires random bytes, it places the descriptor 
-of one or more buffers in the queue. It will be completely filled 
+When the driver requires random bytes, it places the descriptor
+of one or more buffers in the queue. It will be completely filled
 by random data by the device.
 
 2.5.5. Memory Balloon Device
 ===========================
 
-The virtio memory balloon device is a primitive device for 
-managing guest memory: the device asks for a certain amount of 
-memory, and the guest supplies it (or withdraws it, if the device 
-has more than it asks for). This allows the guest to adapt to 
-changes in allowance of underlying physical memory. If the 
-feature is negotiated, the device can also be used to communicate 
+The virtio memory balloon device is a primitive device for
+managing guest memory: the device asks for a certain amount of
+memory, and the guest supplies it (or withdraws it, if the device
+has more than it asks for). This allows the guest to adapt to
+changes in allowance of underlying physical memory. If the
+feature is negotiated, the device can also be used to communicate
 guest memory statistics to the host.
 
 2.5.5.1. Device ID
@@ -1863,16 +1863,16 @@ guest memory statistics to the host.
 
 2.5.5.3. Feature bits
 --------------------
-  VIRTIO_BALLOON_F_MUST_TELL_HOST (0) Host must be told before 
+  VIRTIO_BALLOON_F_MUST_TELL_HOST (0) Host must be told before
     pages from the balloon are used.
 
-  VIRTIO_BALLOON_F_STATS_VQ (1) A virtqueue for reporting guest 
+  VIRTIO_BALLOON_F_STATS_VQ (1) A virtqueue for reporting guest
     memory statistics is present.
 
 2.5.5.4. Device configuration layout
 -----------------------------------
-  Both fields of this configuration 
-  are always available. Note that they are little endian, despite 
+  Both fields of this configuration
+  are always available. Note that they are little endian, despite
   convention that device fields are guest endian:
 
 	struct virtio_balloon_config {
@@ -1889,7 +1889,7 @@ guest memory statistics to the host.
 
   (a) Identify the stats virtqueue.
 
-  (b) Add one empty buffer to the stats virtqueue and notify the 
+  (b) Add one empty buffer to the stats virtqueue and notify the
     host.
 
 Device operation begins immediately.
@@ -1897,13 +1897,13 @@ Device operation begins immediately.
 2.5.5.6. Device Operation
 ------------------------
 
-Memory Ballooning The device is driven by the receipt of a 
+Memory Ballooning The device is driven by the receipt of a
 configuration change interrupt.
 
-1. The “num_pages” configuration field is examined. If this is 
-  greater than the “actual” number of pages, memory must be given 
-  to the balloon. If it is less than the “actual” number of 
-  pages, memory may be taken back from the balloon for general 
+1. The “num_pages” configuration field is examined. If this is
+  greater than the “actual” number of pages, memory must be given
+  to the balloon. If it is less than the “actual” number of
+  pages, memory may be taken back from the balloon for general
   use.
 
 2. To supply memory to the balloon (aka. inflate):
@@ -1914,49 +1914,49 @@ configuration change interrupt.
 
 3. To remove memory from the balloon (aka. deflate):
 
-  (a) The driver constructs an array of addresses of memory pages 
-    it has previously given to the balloon, as described above. 
+  (a) The driver constructs an array of addresses of memory pages
+    it has previously given to the balloon, as described above.
     This descriptor is added to the deflateq.
 
-  (b) If the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is negotiated, the 
-    guest may not use these requested pages until that descriptor 
+  (b) If the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is negotiated, the
+    guest may not use these requested pages until that descriptor
     in the deflateq has been used by the device.
 
-  (c) Otherwise, the guest may begin to re-use pages previously 
-    given to the balloon before the device has acknowledged their 
-    withdrawl. [28] 
+  (c) Otherwise, the guest may begin to re-use pages previously
+    given to the balloon before the device has acknowledged their
+    withdrawl. [28]
 
-4. In either case, once the device has completed the inflation or 
-  deflation, the “actual” field of the configuration should be 
+4. In either case, once the device has completed the inflation or
+  deflation, the “actual” field of the configuration should be
   updated to reflect the new number of pages in the balloon.[29]
 
 2.5.5.6.1. Memory Statistics
 ---------------------------
 
-The stats virtqueue is atypical because communication is driven 
-by the device (not the driver). The channel becomes active at 
-driver initialization time when the driver adds an empty buffer 
-and notifies the device. A request for memory statistics proceeds 
+The stats virtqueue is atypical because communication is driven
+by the device (not the driver). The channel becomes active at
+driver initialization time when the driver adds an empty buffer
+and notifies the device. A request for memory statistics proceeds
 as follows:
 
-1. The device pushes the buffer onto the used ring and sends an 
+1. The device pushes the buffer onto the used ring and sends an
   interrupt.
 
 2. The driver pops the used buffer and discards it.
 
-3. The driver collects memory statistics and writes them into a 
+3. The driver collects memory statistics and writes them into a
   new buffer.
 
-4. The driver adds the buffer to the virtqueue and notifies the 
+4. The driver adds the buffer to the virtqueue and notifies the
   device.
 
-5. The device pops the buffer (retaining it to initiate a 
+5. The device pops the buffer (retaining it to initiate a
   subsequent request) and consumes the statistics.
 
-  Memory Statistics Format Each statistic consists of a 16 bit 
-  tag and a 64 bit value. Both quantities are represented in the 
-  native endian of the guest. All statistics are optional and the 
-  driver may choose which ones to supply. To guarantee backwards 
+  Memory Statistics Format Each statistic consists of a 16 bit
+  tag and a 64 bit value. Both quantities are represented in the
+  native endian of the guest. All statistics are optional and the
+  driver may choose which ones to supply. To guarantee backwards
   compatibility, unsupported statistics should be omitted.
 
 	struct virtio_balloon_stat {
@@ -1973,46 +1973,46 @@ as follows:
 2.5.5.6.2. Memory Statistics Tags
 --------------------------------
 
-  VIRTIO_BALLOON_S_SWAP_IN The amount of memory that has been 
+  VIRTIO_BALLOON_S_SWAP_IN The amount of memory that has been
   swapped in (in bytes).
 
-  VIRTIO_BALLOON_S_SWAP_OUT The amount of memory that has been 
+  VIRTIO_BALLOON_S_SWAP_OUT The amount of memory that has been
   swapped out to disk (in bytes).
 
-  VIRTIO_BALLOON_S_MAJFLT The number of major page faults that 
+  VIRTIO_BALLOON_S_MAJFLT The number of major page faults that
   have occurred.
 
-  VIRTIO_BALLOON_S_MINFLT The number of minor page faults that 
+  VIRTIO_BALLOON_S_MINFLT The number of minor page faults that
   have occurred.
 
-  VIRTIO_BALLOON_S_MEMFREE The amount of memory not being used 
+  VIRTIO_BALLOON_S_MEMFREE The amount of memory not being used
   for any purpose (in bytes).
 
-  VIRTIO_BALLOON_S_MEMTOT The total amount of memory available 
+  VIRTIO_BALLOON_S_MEMTOT The total amount of memory available
   (in bytes).
 
 
 2.5.6. SCSI Host Device
 ======================
 
-The virtio SCSI host device groups together one or more virtual 
-logical units (such as disks), and allows communicating to them 
-using the SCSI protocol. An instance of the device represents a 
+The virtio SCSI host device groups together one or more virtual
+logical units (such as disks), and allows communicating to them
+using the SCSI protocol. An instance of the device represents a
 SCSI host to which many targets and LUNs are attached.
 
 The virtio SCSI device services two kinds of requests:
 
 • command requests for a logical unit;
 
-• task management functions related to a logical unit, target or 
+• task management functions related to a logical unit, target or
   command.
 
-The device is also able to send out notifications about added and 
-removed logical units. Together, these capabilities provide a 
-SCSI transport protocol that uses virtqueues as the transfer 
-medium. In the transport protocol, the virtio driver acts as the 
-initiator, while the virtio SCSI host provides one or more 
-targets that receive and process the requests. 
+The device is also able to send out notifications about added and
+removed logical units. Together, these capabilities provide a
+SCSI transport protocol that uses virtqueues as the transfer
+medium. In the transport protocol, the virtio driver acts as the
+initiator, while the virtio SCSI host provides one or more
+targets that receive and process the requests.
 
 2.5.6.1. Device ID
 -----------------
@@ -2025,10 +2025,10 @@ targets that receive and process the requests.
 2.5.6.3. Feature bits
 --------------------
 
-  VIRTIO_SCSI_F_INOUT (0) A single request can include both 
+  VIRTIO_SCSI_F_INOUT (0) A single request can include both
     read-only and write-only data buffers.
 
-  VIRTIO_SCSI_F_HOTPLUG (1) The host should enable 
+  VIRTIO_SCSI_F_HOTPLUG (1) The host should enable
     hot-plug/hot-unplug of new LUNs and targets on the SCSI bus.
 
 2.5.6.4. Device configuration layout
@@ -2050,54 +2050,54 @@ targets that receive and process the requests.
 		u32 max_lun;
 	};
 
-  num_queues is the total number of request virtqueues exposed by 
-    the device. The driver is free to use only one request queue, 
+  num_queues is the total number of request virtqueues exposed by
+    the device. The driver is free to use only one request queue,
     or it can use more to achieve better performance.
 
-  seg_max is the maximum number of segments that can be in a 
-    command. A bidirectional command can include seg_max input 
+  seg_max is the maximum number of segments that can be in a
+    command. A bidirectional command can include seg_max input
     segments and seg_max output segments.
 
-  max_sectors is a hint to the guest about the maximum transfer 
+  max_sectors is a hint to the guest about the maximum transfer
     size it should use.
 
-  cmd_per_lun is a hint to the guest about the maximum number of 
-    linked commands it should send to one LUN. The actual value 
-    to be used is the minimum of cmd_per_lun and the virtqueue 
+  cmd_per_lun is a hint to the guest about the maximum number of
+    linked commands it should send to one LUN. The actual value
+    to be used is the minimum of cmd_per_lun and the virtqueue
     size.
 
-  event_info_size is the maximum size that the device will fill 
-    for buffers that the driver places in the eventq. The driver 
-    should always put buffers at least of this size. It is 
-    written by the device depending on the set of negotated 
+  event_info_size is the maximum size that the device will fill
+    for buffers that the driver places in the eventq. The driver
+    should always put buffers at least of this size. It is
+    written by the device depending on the set of negotated
     features.
 
-  sense_size is the maximum size of the sense data that the 
-    device will write. The default value is written by the device 
-    and will always be 96, but the driver can modify it. It is 
+  sense_size is the maximum size of the sense data that the
+    device will write. The default value is written by the device
+    and will always be 96, but the driver can modify it. It is
     restored to the default when the device is reset.
 
-  cdb_size is the maximum size of the CDB that the driver will 
-    write. The default value is written by the device and will 
-    always be 32, but the driver can likewise modify it. It is 
+  cdb_size is the maximum size of the CDB that the driver will
+    write. The default value is written by the device and will
+    always be 32, but the driver can likewise modify it. It is
     restored to the default when the device is reset.
 
-  max_channel, max_target and max_lun can be used by the driver 
-    as hints to constrain scanning the logical units on the 
+  max_channel, max_target and max_lun can be used by the driver
+    as hints to constrain scanning the logical units on the
     host.h
 
 2.5.6.5. Device Initialization
 -----------------------------
 
-The initialization routine should first of all discover the 
+The initialization routine should first of all discover the
 device's virtqueues.
 
-If the driver uses the eventq, it should then place at least a 
+If the driver uses the eventq, it should then place at least a
 buffer in the eventq.
 
-The driver can immediately issue requests (for example, INQUIRY 
-or REPORT LUNS) or task management functions (for example, I_T 
-RESET). 
+The driver can immediately issue requests (for example, INQUIRY
+or REPORT LUNS) or task management functions (for example, I_T
+RESET).
 
 2.5.6.6. Device Operation
 ------------------------
@@ -2108,13 +2108,13 @@ queue and the event queue.
 2.5.6.6.1. Device Operation: Request Queues
 ------------------------------------------
 
-The driver queues requests to an arbitrary request queue, and 
-they are used by the device on that same queue. It is the 
-responsibility of the driver to ensure strict request ordering 
-for commands placed on different queues, because they will be 
+The driver queues requests to an arbitrary request queue, and
+they are used by the device on that same queue. It is the
+responsibility of the driver to ensure strict request ordering
+for commands placed on different queues, because they will be
 consumed with no order constraints.
 
-Requests have the following format: 
+Requests have the following format:
 
 	struct virtio_scsi_req_cmd {
 		// Read-only
@@ -2154,84 +2154,84 @@ Requests have the following format:
 	#define VIRTIO_SCSI_S_HEAD              2
 	#define VIRTIO_SCSI_S_ACA               3
 
-The lun field addresses a target and logical unit in the 
-virtio-scsi device's SCSI domain. The only supported format for 
-the LUN field is: first byte set to 1, second byte set to target, 
-third and fourth byte representing a single level LUN structure, 
-followed by four zero bytes. With this representation, a 
-virtio-scsi device can serve up to 256 targets and 16384 LUNs per 
+The lun field addresses a target and logical unit in the
+virtio-scsi device's SCSI domain. The only supported format for
+the LUN field is: first byte set to 1, second byte set to target,
+third and fourth byte representing a single level LUN structure,
+followed by four zero bytes. With this representation, a
+virtio-scsi device can serve up to 256 targets and 16384 LUNs per
 target.
 
 The id field is the command identifier (“tag”).
 
-task_attr, prio and crn should be left to zero. task_attr defines 
-the task attribute as in the table above, but all task attributes 
-may be mapped to SIMPLE by the device; crn may also be provided 
-by clients, but is generally expected to be 0. The maximum CRN 
-value defined by the protocol is 255, since CRN is stored in an 
+task_attr, prio and crn should be left to zero. task_attr defines
+the task attribute as in the table above, but all task attributes
+may be mapped to SIMPLE by the device; crn may also be provided
+by clients, but is generally expected to be 0. The maximum CRN
+value defined by the protocol is 255, since CRN is stored in an
 8-bit integer.
 
-All of these fields are defined in SAM. They are always 
-read-only, as are the cdb and dataout field. The cdb_size is 
+All of these fields are defined in SAM. They are always
+read-only, as are the cdb and dataout field. The cdb_size is
 taken from the configuration space.
 
-sense and subsequent fields are always write-only. The sense_len 
-field indicates the number of bytes actually written to the sense 
-buffer. The residual field indicates the residual size, 
-calculated as “data_length - number_of_transferred_bytes”, for 
-read or write operations. For bidirectional commands, the 
-number_of_transferred_bytes includes both read and written bytes. 
-A residual field that is less than the size of datain means that 
-the dataout field was processed entirely. A residual field that 
-exceeds the size of datain means that the dataout field was 
-processed partially and the datain field was not processed at 
+sense and subsequent fields are always write-only. The sense_len
+field indicates the number of bytes actually written to the sense
+buffer. The residual field indicates the residual size,
+calculated as “data_length - number_of_transferred_bytes”, for
+read or write operations. For bidirectional commands, the
+number_of_transferred_bytes includes both read and written bytes.
+A residual field that is less than the size of datain means that
+the dataout field was processed entirely. A residual field that
+exceeds the size of datain means that the dataout field was
+processed partially and the datain field was not processed at
 all.
 
-The status byte is written by the device to be the status code as 
+The status byte is written by the device to be the status code as
 defined in SAM.
 
-The response byte is written by the device to be one of the 
+The response byte is written by the device to be one of the
 following:
 
-  VIRTIO_SCSI_S_OK when the request was completed and the status 
-  byte is filled with a SCSI status code (not necessarily 
+  VIRTIO_SCSI_S_OK when the request was completed and the status
+  byte is filled with a SCSI status code (not necessarily
   "GOOD").
 
-  VIRTIO_SCSI_S_OVERRUN if the content of the CDB requires 
+  VIRTIO_SCSI_S_OVERRUN if the content of the CDB requires
   transferring more data than is available in the data buffers.
 
-  VIRTIO_SCSI_S_ABORTED if the request was cancelled due to an 
+  VIRTIO_SCSI_S_ABORTED if the request was cancelled due to an
   ABORT TASK or ABORT TASK SET task management function.
 
-  VIRTIO_SCSI_S_BAD_TARGET if the request was never processed 
+  VIRTIO_SCSI_S_BAD_TARGET if the request was never processed
   because the target indicated by the lun field does not exist.
 
-  VIRTIO_SCSI_S_RESET if the request was cancelled due to a bus 
+  VIRTIO_SCSI_S_RESET if the request was cancelled due to a bus
   or device reset (including a task management function).
 
-  VIRTIO_SCSI_S_TRANSPORT_FAILURE if the request failed due to a 
-  problem in the connection between the host and the target 
+  VIRTIO_SCSI_S_TRANSPORT_FAILURE if the request failed due to a
+  problem in the connection between the host and the target
   (severed link).
 
-  VIRTIO_SCSI_S_TARGET_FAILURE if the target is suffering a 
+  VIRTIO_SCSI_S_TARGET_FAILURE if the target is suffering a
   failure and the guest should not retry on other paths.
 
-  VIRTIO_SCSI_S_NEXUS_FAILURE if the nexus is suffering a failure 
+  VIRTIO_SCSI_S_NEXUS_FAILURE if the nexus is suffering a failure
   but retrying on other paths might yield a different result.
 
-  VIRTIO_SCSI_S_BUSY if the request failed but retrying on the 
+  VIRTIO_SCSI_S_BUSY if the request failed but retrying on the
   same path should work.
 
-  VIRTIO_SCSI_S_FAILURE for other host or guest error. In 
-  particular, if neither dataout nor datain is empty, and the 
-  VIRTIO_SCSI_F_INOUT feature has not been negotiated, the 
-  request will be immediately returned with a response equal to 
-  VIRTIO_SCSI_S_FAILURE. 
+  VIRTIO_SCSI_S_FAILURE for other host or guest error. In
+  particular, if neither dataout nor datain is empty, and the
+  VIRTIO_SCSI_F_INOUT feature has not been negotiated, the
+  request will be immediately returned with a response equal to
+  VIRTIO_SCSI_S_FAILURE.
 
 2.5.6.6.2. Device Operation: controlq
 ------------------------------------
 
-The controlq is used for other SCSI transport operations. 
+The controlq is used for other SCSI transport operations.
 Requests have the following format:
 
 	struct virtio_scsi_ctrl {
@@ -2254,7 +2254,7 @@ The type identifies the remaining fields.
 
 The following commands are defined:
 
-  Task management function  
+  Task management function
 	#define VIRTIO_SCSI_T_TMF                      0
 
 	#define VIRTIO_SCSI_T_TMF_ABORT_TASK           0
@@ -2282,23 +2282,23 @@ The following commands are defined:
 	#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED       10
 	#define VIRTIO_SCSI_S_FUNCTION_REJECTED        11
 
-  The type is VIRTIO_SCSI_T_TMF; the subtype field defines. All 
-  fields except response are filled by the driver. The subtype 
-  field must always be specified and identifies the requested 
+  The type is VIRTIO_SCSI_T_TMF; the subtype field defines. All
+  fields except response are filled by the driver. The subtype
+  field must always be specified and identifies the requested
   task management function.
 
-  Other fields may be irrelevant for the requested TMF; if so, 
-  they are ignored but they should still be present. The lun 
-  field is in the same format specified for request queues; the 
-  single level LUN is ignored when the task management function 
-  addresses a whole I_T nexus. When relevant, the value of the id 
+  Other fields may be irrelevant for the requested TMF; if so,
+  they are ignored but they should still be present. The lun
+  field is in the same format specified for request queues; the
+  single level LUN is ignored when the task management function
+  addresses a whole I_T nexus. When relevant, the value of the id
   field is matched against the id values passed on the requestq.
 
-  The outcome of the task management function is written by the 
-  device in the response field. The command-specific response 
+  The outcome of the task management function is written by the
+  device in the response field. The command-specific response
   values map 1-to-1 with those defined in SAM.
 
-  Asynchronous notification query  
+  Asynchronous notification query
 
 	#define VIRTIO_SCSI_T_AN_QUERY                    1
 
@@ -2319,20 +2319,20 @@ The following commands are defined:
 	#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST          32
 	#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY         64
 
-  By sending this command, the driver asks the device which 
-  events the given LUN can report, as described in paragraphs 6.6 
-  and A.6 of the SCSI MMC specification. The driver writes the 
-  events it is interested in into the event_requested; the device 
-  responds by writing the events that it supports into 
+  By sending this command, the driver asks the device which
+  events the given LUN can report, as described in paragraphs 6.6
+  and A.6 of the SCSI MMC specification. The driver writes the
+  events it is interested in into the event_requested; the device
+  responds by writing the events that it supports into
   event_actual.
 
-  The type is VIRTIO_SCSI_T_AN_QUERY. The lun and event_requested 
-  fields are written by the driver. The event_actual and response 
+  The type is VIRTIO_SCSI_T_AN_QUERY. The lun and event_requested
+  fields are written by the driver. The event_actual and response
   fields are written by the device.
 
   No command-specific values are defined for the response byte.
 
-  Asynchronous notification subscription  
+  Asynchronous notification subscription
 	#define VIRTIO_SCSI_T_AN_SUBSCRIBE                2
 
 	struct virtio_scsi_ctrl_an {
@@ -2345,17 +2345,17 @@ The following commands are defined:
 		u8  response;
 	}
 
-  By sending this command, the driver asks the specified LUN to 
-  report events for its physical interface, again as described in 
-  the SCSI MMC specification. The driver writes the events it is 
-  interested in into the event_requested; the device responds by 
+  By sending this command, the driver asks the specified LUN to
+  report events for its physical interface, again as described in
+  the SCSI MMC specification. The driver writes the events it is
+  interested in into the event_requested; the device responds by
   writing the events that it supports into event_actual.
 
-  Event types are the same as for the asynchronous notification 
+  Event types are the same as for the asynchronous notification
   query message.
 
-  The type is VIRTIO_SCSI_T_AN_SUBSCRIBE. The lun and 
-  event_requested fields are written by the driver. The 
+  The type is VIRTIO_SCSI_T_AN_SUBSCRIBE. The lun and
+  event_requested fields are written by the driver. The
   event_actual and response fields are written by the device.
 
   No command-specific values are defined for the response byte.
@@ -2363,25 +2363,25 @@ The following commands are defined:
 2.5.6.6.3. Device Operation: eventq
 ----------------------------------
 
-The eventq is used by the device to report information on logical 
-units that are attached to it. The driver should always leave a 
-few buffers ready in the eventq. In general, the device will not 
-queue events to cope with an empty eventq, and will end up 
-dropping events if it finds no buffer ready. However, when 
-reporting events for many LUNs (e.g. when a whole target 
-disappears), the device can throttle events to avoid dropping 
-them. For this reason, placing 10-15 buffers on the event queue 
+The eventq is used by the device to report information on logical
+units that are attached to it. The driver should always leave a
+few buffers ready in the eventq. In general, the device will not
+queue events to cope with an empty eventq, and will end up
+dropping events if it finds no buffer ready. However, when
+reporting events for many LUNs (e.g. when a whole target
+disappears), the device can throttle events to avoid dropping
+them. For this reason, placing 10-15 buffers on the event queue
 should be enough.
 
-Buffers are placed in the eventq and filled by the device when 
-interesting events occur. The buffers should be strictly 
-write-only (device-filled) and the size of the buffers should be 
-at least the value given in the device's configuration 
+Buffers are placed in the eventq and filled by the device when
+interesting events occur. The buffers should be strictly
+write-only (device-filled) and the size of the buffers should be
+at least the value given in the device's configuration
 information.
 
-Buffers returned by the device on the eventq will be referred to 
-as "events" in the rest of this section. Events have the 
-following format: 
+Buffers returned by the device on the eventq will be referred to
+as "events" in the rest of this section. Events have the
+following format:
 
 	#define VIRTIO_SCSI_T_EVENTS_MISSED   0x80000000
 
@@ -2391,33 +2391,33 @@ following format:
 		...
 	}
 
-If bit 31 is set in the event field, the device failed to report 
-an event due to missing buffers. In this case, the driver should 
-poll the logical units for unit attention conditions, and/or do 
-whatever form of bus scan is appropriate for the guest operating 
+If bit 31 is set in the event field, the device failed to report
+an event due to missing buffers. In this case, the driver should
+poll the logical units for unit attention conditions, and/or do
+whatever form of bus scan is appropriate for the guest operating
 system.
 
-Other data that the device writes to the buffer depends on the 
+Other data that the device writes to the buffer depends on the
 contents of the event field. The following events are defined:
 
-  No event  
+  No event
 	#define VIRTIO_SCSI_T_NO_EVENT         0
 
-  This event is fired in the following cases: 
+  This event is fired in the following cases:
 
-  • When the device detects in the eventq a buffer that is 
-    shorter than what is indicated in the configuration field, it 
-    might use it immediately and put this dummy value in the 
-    event field. A well-written driver will never observe this 
+  • When the device detects in the eventq a buffer that is
+    shorter than what is indicated in the configuration field, it
+    might use it immediately and put this dummy value in the
+    event field. A well-written driver will never observe this
     situation.
 
-  • When events are dropped, the device may signal this event as 
-    soon as the drivers makes a buffer available, in order to 
-    request action from the driver. In this case, of course, this 
-    event will be reported with the VIRTIO_SCSI_T_EVENTS_MISSED 
-    flag. 
+  • When events are dropped, the device may signal this event as
+    soon as the drivers makes a buffer available, in order to
+    request action from the driver. In this case, of course, this
+    event will be reported with the VIRTIO_SCSI_T_EVENTS_MISSED
+    flag.
 
-  Transport reset  
+  Transport reset
 	#define VIRTIO_SCSI_T_TRANSPORT_RESET  1
 
 	struct virtio_scsi_event_reset {
@@ -2431,58 +2431,58 @@ contents of the event field. The following events are defined:
 	#define VIRTIO_SCSI_EVT_RESET_RESCAN       1
 	#define VIRTIO_SCSI_EVT_RESET_REMOVED      2
 
-  By sending this event, the device signals that a logical unit 
-  on a target has been reset, including the case of a new device 
-  appearing or disappearing on the bus.The device fills in all 
-  fields. The event field is set to 
-  VIRTIO_SCSI_T_TRANSPORT_RESET. The lun field addresses a 
+  By sending this event, the device signals that a logical unit
+  on a target has been reset, including the case of a new device
+  appearing or disappearing on the bus.The device fills in all
+  fields. The event field is set to
+  VIRTIO_SCSI_T_TRANSPORT_RESET. The lun field addresses a
   logical unit in the SCSI host.
 
-  The reason value is one of the three #define values appearing 
+  The reason value is one of the three #define values appearing
   above:
 
-  • VIRTIO_SCSI_EVT_RESET_REMOVED (“LUN/target removed”) is used 
-    if the target or logical unit is no longer able to receive 
+  • VIRTIO_SCSI_EVT_RESET_REMOVED (“LUN/target removed”) is used
+    if the target or logical unit is no longer able to receive
     commands.
 
-  • VIRTIO_SCSI_EVT_RESET_HARD (“LUN hard reset”) is used if the 
+  • VIRTIO_SCSI_EVT_RESET_HARD (“LUN hard reset”) is used if the
     logical unit has been reset, but is still present.
 
-  • VIRTIO_SCSI_EVT_RESET_RESCAN (“rescan LUN/target”) is used if 
+  • VIRTIO_SCSI_EVT_RESET_RESCAN (“rescan LUN/target”) is used if
     a target or logical unit has just appeared on the device.
 
-  The “removed” and “rescan” events, when sent for LUN 0, may 
-  apply to the entire target. After receiving them the driver 
-  should ask the initiator to rescan the target, in order to 
-  detect the case when an entire target has appeared or 
-  disappeared. These two events will never be reported unless the 
-  VIRTIO_SCSI_F_HOTPLUG feature was negotiated between the host 
+  The “removed” and “rescan” events, when sent for LUN 0, may
+  apply to the entire target. After receiving them the driver
+  should ask the initiator to rescan the target, in order to
+  detect the case when an entire target has appeared or
+  disappeared. These two events will never be reported unless the
+  VIRTIO_SCSI_F_HOTPLUG feature was negotiated between the host
   and the guest.
 
-  Events will also be reported via sense codes (this obviously 
-  does not apply to newly appeared buses or targets, since the 
+  Events will also be reported via sense codes (this obviously
+  does not apply to newly appeared buses or targets, since the
   application has never discovered them):
 
-  • “LUN/target removed” maps to sense key ILLEGAL REQUEST, asc 
+  • “LUN/target removed” maps to sense key ILLEGAL REQUEST, asc
     0x25, ascq 0x00 (LOGICAL UNIT NOT SUPPORTED)
 
-  • “LUN hard reset” maps to sense key UNIT ATTENTION, asc 0x29 
+  • “LUN hard reset” maps to sense key UNIT ATTENTION, asc 0x29
     (POWER ON, RESET OR BUS DEVICE RESET OCCURRED)
 
-  • “rescan LUN/target” maps to sense key UNIT ATTENTION, asc 
+  • “rescan LUN/target” maps to sense key UNIT ATTENTION, asc
     0x3f, ascq 0x0e (REPORTED LUNS DATA HAS CHANGED)
 
-  The preferred way to detect transport reset is always to use 
-  events, because sense codes are only seen by the driver when it 
-  sends a SCSI command to the logical unit or target. However, in 
-  case events are dropped, the initiator will still be able to 
-  synchronize with the actual state of the controller if the 
-  driver asks the initiator to rescan of the SCSI bus. During the 
-  rescan, the initiator will be able to observe the above sense 
-  codes, and it will process them as if it the driver had 
-  received the equivalent event. 
-
-  Asynchronous notification  
+  The preferred way to detect transport reset is always to use
+  events, because sense codes are only seen by the driver when it
+  sends a SCSI command to the logical unit or target. However, in
+  case events are dropped, the initiator will still be able to
+  synchronize with the actual state of the controller if the
+  driver asks the initiator to rescan of the SCSI bus. During the
+  rescan, the initiator will be able to observe the above sense
+  codes, and it will process them as if it the driver had
+  received the equivalent event.
+
+  Asynchronous notification
 	#define VIRTIO_SCSI_T_ASYNC_NOTIFY     2
 
 	struct virtio_scsi_event_an {
@@ -2492,16 +2492,16 @@ contents of the event field. The following events are defined:
 		u32 reason;
 	}
 
-  By sending this event, the device signals that an asynchronous 
+  By sending this event, the device signals that an asynchronous
   event was fired from a physical interface.
 
-  All fields are written by the device. The event field is set to 
-  VIRTIO_SCSI_T_ASYNC_NOTIFY. The lun field addresses a logical 
-  unit in the SCSI host. The reason field is a subset of the 
-  events that the driver has subscribed to via the "Asynchronous 
+  All fields are written by the device. The event field is set to
+  VIRTIO_SCSI_T_ASYNC_NOTIFY. The lun field addresses a logical
+  unit in the SCSI host. The reason field is a subset of the
+  events that the driver has subscribed to via the "Asynchronous
   notification subscription" command.
 
-  When dropped events are reported, the driver should poll for 
+  When dropped events are reported, the driver should poll for
   asynchronous events manually using SCSI commands.
 
 
@@ -2510,15 +2510,15 @@ contents of the event field. The following events are defined:
 
 Currently there are four device-independent feature bits defined:
 
-  VIRTIO_F_NOTIFY_ON_EMPTY (24) Negotiating this feature 
-  indicates that the driver wants an interrupt if the device runs 
-  out of available descriptors on a virtqueue, even though 
-  interrupts are suppressed using the VRING_AVAIL_F_NO_INTERRUPT 
-  flag or the used_event field. An example of this is the 
-  networking driver: it doesn't need to know every time a packet 
-  is transmitted, but it does need to free the transmitted 
-  packets a finite time after they are transmitted. It can avoid 
-  using a timer if the device interrupts it when all the packets 
+  VIRTIO_F_NOTIFY_ON_EMPTY (24) Negotiating this feature
+  indicates that the driver wants an interrupt if the device runs
+  out of available descriptors on a virtqueue, even though
+  interrupts are suppressed using the VRING_AVAIL_F_NO_INTERRUPT
+  flag or the used_event field. An example of this is the
+  networking driver: it doesn't need to know every time a packet
+  is transmitted, but it does need to free the transmitted
+  packets a finite time after they are transmitted. It can avoid
+  using a timer if the device interrupts it when all the packets
   are transmitted.
 
   VIRTIO_F_ANY_LAYOUT (27) This feature indicates that the device accepts arbitrary
@@ -2528,15 +2528,15 @@ Currently there are four device-independent feature bits defined:
   that the driver can use descriptors with the VRING_DESC_F_INDIRECT
   flag set, as described in "2.3.3. Indirect Descriptors".
 
-  VIRTIO_F_RING_EVENT_IDX(29) This feature enables the used_event 
-  and the avail_event fields. If set, it indicates that the 
-  device should ignore the flags field in the available ring 
-  structure. Instead, the used_event field in this structure is 
-  used by guest to suppress device interrupts. Further, the 
-  driver should ignore the flags field in the used ring 
-  structure. Instead, the avail_event field in this structure is 
-  used by the device to suppress notifications. If unset, the 
-  driver should ignore the used_event field; the device should 
+  VIRTIO_F_RING_EVENT_IDX(29) This feature enables the used_event
+  and the avail_event fields. If set, it indicates that the
+  device should ignore the flags field in the available ring
+  structure. Instead, the used_event field in this structure is
+  used by guest to suppress device interrupts. Further, the
+  driver should ignore the flags field in the used ring
+  structure. Instead, the avail_event field in this structure is
+  used by the device to suppress notifications. If unset, the
+  driver should ignore the used_event field; the device should
   ignore the avail_event field; the flags field is used
 
 
@@ -2695,7 +2695,7 @@ static inline unsigned vring_size(unsigned int num, unsigned long align)
 
 static inline int vring_need_event(uint16_t event_idx, uint16_t new_idx, uint16_t old_idx)
 {
-         return (uint16_t)(new_idx - event_idx - 1) < (uint16_t)(new_idx - old_idx); 
+         return (uint16_t)(new_idx - event_idx - 1) < (uint16_t)(new_idx - old_idx);
 }
 
 /* Get location of event indices (only with VIRTIO_RING_F_EVENT_IDX) */
@@ -2717,18 +2717,18 @@ static inline uint16_t *vring_avail_event(struct vring *vr)
 2.10. Creating New Device Types
 ==============================
 
-Various considerations are necessary when creating a new device 
+Various considerations are necessary when creating a new device
 type.
- 
+
 2.10.1. How Many Virtqueues?
 ---------------------------
 
-It is possible that a very simple device will operate entirely 
-through its configuration space, but most will need at least one 
-virtqueue in which it will place requests. A device with both 
-input and output (eg. console and network devices described here) 
-need two queues: one which the driver fills with buffers to 
-receive input, and one which the driver places buffers to 
+It is possible that a very simple device will operate entirely
+through its configuration space, but most will need at least one
+virtqueue in which it will place requests. A device with both
+input and output (eg. console and network devices described here)
+need two queues: one which the driver fills with buffers to
+receive input, and one which the driver places buffers to
 transmit output.
 
 2.10.2. What Configuration Space Layout?
@@ -2736,16 +2736,16 @@ transmit output.
 
 Configuration space should only be used for initialization-time
 parameters.  It is a limited resource with no synchronization, so for
-most uses it is better to use a virtqueue to update configuration 
-information (the network device does this for filtering, 
-otherwise the table in the config space could potentially be very 
+most uses it is better to use a virtqueue to update configuration
+information (the network device does this for filtering,
+otherwise the table in the config space could potentially be very
 large).
 
 2.10.3. What Device Number?
 --------------------------
 
-Currently device numbers are assigned quite freely: a simple 
-request mail to the author of this document or the Linux 
+Currently device numbers are assigned quite freely: a simple
+request mail to the author of this document or the Linux
 virtualization mailing list[9] will be sufficient to secure a unique one.
 
 Meanwhile for experimental drivers, use 65535 and work backwards.
@@ -2753,67 +2753,67 @@ Meanwhile for experimental drivers, use 65535 and work backwards.
 2.10.4. How many MSI-X vectors?  (for PCI)
 -----------------------------------------
 
-Using the optional MSI-X capability devices can speed up 
-interrupt processing by removing the need to read ISR Status 
-register by guest driver (which might be an expensive operation), 
-reducing interrupt sharing between devices and queues within the 
-device, and handling interrupts from multiple CPUs. However, some 
-systems impose a limit (which might be as low as 256) on the 
-total number of MSI-X vectors that can be allocated to all 
-devices. Devices and/or device drivers should take this into 
-account, limiting the number of vectors used unless the device is 
-expected to cause a high volume of interrupts. Devices can 
-control the number of vectors used by limiting the MSI-X Table 
-Size or not presenting MSI-X capability in PCI configuration 
-space. Drivers can control this by mapping events to as small 
-number of vectors as possible, or disabling MSI-X capability 
+Using the optional MSI-X capability devices can speed up
+interrupt processing by removing the need to read ISR Status
+register by guest driver (which might be an expensive operation),
+reducing interrupt sharing between devices and queues within the
+device, and handling interrupts from multiple CPUs. However, some
+systems impose a limit (which might be as low as 256) on the
+total number of MSI-X vectors that can be allocated to all
+devices. Devices and/or device drivers should take this into
+account, limiting the number of vectors used unless the device is
+expected to cause a high volume of interrupts. Devices can
+control the number of vectors used by limiting the MSI-X Table
+Size or not presenting MSI-X capability in PCI configuration
+space. Drivers can control this by mapping events to as small
+number of vectors as possible, or disabling MSI-X capability
 altogether.
 
 2.10.5. Device Improvements
 --------------------------
 
-Any change to configuration space, or new virtqueues, or 
-behavioural changes, should be indicated by negotiation of a new 
+Any change to configuration space, or new virtqueues, or
+behavioural changes, should be indicated by negotiation of a new
 feature bit. This establishes clarity[11] and avoids future expansion problems.
 
-Clusters of functionality which are always implemented together 
-can use a single bit, but if one feature makes sense without the 
-others they should not be gratuitously grouped together to 
-conserve feature bits. We can always extend the spec when the 
+Clusters of functionality which are always implemented together
+can use a single bit, but if one feature makes sense without the
+others they should not be gratuitously grouped together to
+conserve feature bits. We can always extend the spec when the
 first person needs more than 24 feature bits for their device.
 
 
 FOOTNOTES:
 ==========
 
-[1] This lack of page-sharing implies that the implementation of the 
-device (e.g. the hypervisor or host) needs full access to the 
-guest memory. Communication with untrusted parties (i.e. 
+[1] This lack of page-sharing implies that the implementation of the
+device (e.g. the hypervisor or host) needs full access to the
+guest memory. Communication with untrusted parties (i.e.
 inter-guest communication) requires copying.
 
-[2] The Linux implementation further separates the PCI virtio code 
-from the specific virtio drivers: these drivers are shared with 
+[2] The Linux implementation further separates the PCI virtio code
+from the specific virtio drivers: these drivers are shared with
 the non-PCI implementations (currently lguest and S/390).
 
 [3] The actual value within this range is ignored
 
-[4] Historically, drivers have used the device before steps 5 and 6. 
-This is only allowed if the driver does not use any features 
+[4] Historically, drivers have used the device before steps 5 and 6.
+This is only allowed if the driver does not use any features
 which would alter this early use of the device.
 
-[5] ie. once you enable MSI-X on the device, the other fields move. 
+[5] ie. once you enable MSI-X on the device, the other fields move.
 If you turn it off again, they move back!
 
-[6] The 4096 is based on the x86 page size, but it's also large 
-enough to ensure that the separate parts of the virtqueue are on 
+[6] The 4096 is based on the x86 page size, but it's also large
+enough to ensure that the separate parts of the virtqueue are on
 separate cache lines.
 
-[7] These fields are kept here because this is the only part of the 
+[7] These fields are kept here because this is the only part of the
 virtqueue written by the device
 
-[8] The Linux drivers do this only for read-only buffers: for 
-write-only buffers, it is assumed that the driver is merely 
-trying to keep the receive buffer ring full, and no notification 
+[8] The Linux drivers do this only for read-only buffers: for
+write-only buffers, it is assumed that the driver is merely
+trying to keep the receive buffer ring full, and no notification
 of this expected condition is necessary.
 
 [9] https://lists.linux-foundation.org/mailman/listinfo/virtualization
@@ -2824,19 +2824,19 @@ devices assumed it.
 In addition, the specifications for virtio_blk and virtio_scsi require
 intuiting field lengths from frame boundaries.
 
-[11] Even if it does mean documenting design or implementation 
+[11] Even if it does mean documenting design or implementation
 mistakes!
 
 
-[13] It was supposed to indicate segmentation offload support, but 
-upon further investigation it became clear that multiple bits 
+[13] It was supposed to indicate segmentation offload support, but
+upon further investigation it became clear that multiple bits
 were required.
 
-[14] ie. VIRTIO_NET_F_HOST_TSO* and VIRTIO_NET_F_HOST_UFO are 
-dependent on VIRTIO_NET_F_CSUM; a dvice which offers the offload 
-features must offer the checksum feature, and a driver which 
-accepts the offload features must accept the checksum feature. 
-Similar logic applies to the VIRTIO_NET_F_GUEST_TSO4 features 
+[14] ie. VIRTIO_NET_F_HOST_TSO* and VIRTIO_NET_F_HOST_UFO are
+dependent on VIRTIO_NET_F_CSUM; a dvice which offers the offload
+features must offer the checksum feature, and a driver which
+accepts the offload features must accept the checksum feature.
+Similar logic applies to the VIRTIO_NET_F_GUEST_TSO4 features
 depending on VIRTIO_NET_F_GUEST_CSUM.
 
 [15] This is a common restriction in real, older network cards.
@@ -2845,44 +2845,44 @@ depending on VIRTIO_NET_F_GUEST_CSUM.
 the same system may not require checksumming at all, nor segmentation,
 if both guests are amenable.
 
-[17] For example, consider a partially checksummed TCP (IPv4) packet. 
-It will have a 14 byte ethernet header and 20 byte IP header 
-followed by the TCP header (with the TCP checksum field 16 bytes 
-into that header). csum_start will be 14+20 = 34 (the TCP 
-checksum includes the header), and csum_offset will be 16. The 
-value in the TCP checksum field should be initialized to the sum 
-of the TCP pseudo header, so that replacing it by the ones' 
-complement checksum of the TCP header and body will give the 
+[17] For example, consider a partially checksummed TCP (IPv4) packet.
+It will have a 14 byte ethernet header and 20 byte IP header
+followed by the TCP header (with the TCP checksum field 16 bytes
+into that header). csum_start will be 14+20 = 34 (the TCP
+checksum includes the header), and csum_offset will be 16. The
+value in the TCP checksum field should be initialized to the sum
+of the TCP pseudo header, so that replacing it by the ones'
+complement checksum of the TCP header and body will give the
 correct result.
 
-[18] Due to various bugs in implementations, this field is not useful 
+[18] Due to various bugs in implementations, this field is not useful
 as a guarantee of the transport header size.
 
-[19] This case is not handled by some older hardware, so is called out 
+[19] This case is not handled by some older hardware, so is called out
 specifically in the protocol.
 
-[20] Note that the header will be two bytes longer for the 
+[20] Note that the header will be two bytes longer for the
 VIRTIO_NET_F_MRG_RXBUF case.
 
-[20a] Obviously each one can be split across multiple descriptor 
+[20a] Obviously each one can be split across multiple descriptor
 elements.
 
 [21] Since there are no guarentees, it can use a hash filter or
 silently switch to allmulti or promiscuous mode if it is given too
 many addresses.
 
-[22] The SCSI_CMD and SCSI_CMD_OUT types are equivalent, the device 
+[22] The SCSI_CMD and SCSI_CMD_OUT types are equivalent, the device
 does not distinguish between them.
 
 [23] The FLUSH and FLUSH_OUT types are equivalent, the device does not
 distinguish between them
 
-[25] Because this is high importance and low bandwidth, the current 
-Linux implementation polls for the buffer to be used, rather than 
-waiting for an interrupt, simplifying the implementation 
-significantly. However, for generic serial ports with the 
-O_NONBLOCK flag set, the polling limitation is relaxed and the 
-consumed buffers are freed upon the next write or poll call or 
+[25] Because this is high importance and low bandwidth, the current
+Linux implementation polls for the buffer to be used, rather than
+waiting for an interrupt, simplifying the implementation
+significantly. However, for generic serial ports with the
+O_NONBLOCK flag set, the polling limitation is relaxed and the
+consumed buffers are freed upon the next write or poll call or
 when a port is closed or hot-unplugged.
 
 [27] This is historical, and independent of the guest page size