blkif interface: Add BLKIF_OP_FLUSH_DISKCACHE.

This disk operation, implemented on Solaris only so far, asks a
backend to flush the disk caches of the underlying storage if
possible, and is contigent upon the 'feature-flush-cache' xenstore
flag (although currently Solaris will always attempt to flush
anyway).

Signed-off-by: John Levon <john.levon@sun.com>

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 548ba95299a55d6143ab69e795d322c7197ca416..2380066b8cb53aa8b106fb8bbe2176c644d49a19 100644 (file)
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -54,7 +54,7 @@
 #define BLKIF_OP_WRITE             1
 /*
  * Recognised only if "feature-barrier" is present in backend xenbus info.
- * The "feature_barrier" node contains a boolean indicating whether barrier
+ * The "feature-barrier" node contains a boolean indicating whether barrier
  * requests are likely to succeed or fail. Either way, a barrier request
  * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
  * the underlying block-device hardware. The boolean simply indicates whether
@@ -63,6 +63,19 @@
  * create the "feature-barrier" node!
  */
 #define BLKIF_OP_WRITE_BARRIER     2
+/*
+ * Recognised if "feature-flush-cache" is present in backend xenbus
+ * info.  A flush will ask the underlying storage hardware to flush its
+ * non-volatile caches as appropriate.  The "feature-flush-cache" node
+ * contains a boolean indicating whether flush requests are likely to
+ * succeed or fail. Either way, a flush request may fail at any time
+ * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying
+ * block-device hardware. The boolean simply indicates whether or not it
+ * is worthwhile for the frontend to attempt flushes.  If a backend does
+ * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the
+ * "feature-flush-cache" node!
+ */
+#define BLKIF_OP_FLUSH_DISKCACHE   3
 
 /*
  * Maximum scatter/gather segments per request.