xen/blkfront: WRITE_BARRIER and FLUSH_DISKCACHE require barrier

For WRITE_BARRIER and FLUSH_DISKCACHE operation, we don't request any cache
operation. This will result to a panic in _bus_dmamap_sync on ARM because the
operation (op = 0) is not supported.

x86 platform doesn't seem to care about this. I bet this is working fine
because only we only grant memory to the backend. Hence Xen is requiring this
memory to be cacheable. I'm wondering if we could drop the call to
bus_dmasync_map because the cache maintenance slow down the process for no
apparent reason?

For now, WRITE_BARRIER and FLUSH_DISKCACHE are an extension of the WRITE
command so require BUS_DMASYNC_PREWRITE for the cache maintenance operation.

diff --git a/sys/dev/xen/blkfront/blkfront.c b/sys/dev/xen/blkfront/blkfront.c
index 1416c28192ee4e628107f1c9a442db6736d2cb30..630732dd3fad2ac5da7899059d378af954290eb8 100644 (file)
--- a/sys/dev/xen/blkfront/blkfront.c
+++ b/sys/dev/xen/blkfront/blkfront.c
@@ -263,12 +263,19 @@ xbd_queue_cb(void *arg, bus_dma_segment_t *segs, int nsegs, int error)
                    sizeof(grant_ref_t) * sc->xbd_max_request_indirectpages);
        }
 
-       if (cm->cm_operation == BLKIF_OP_READ)
+       switch (cm->cm_operation) {
+       case BLKIF_OP_READ:
                op = BUS_DMASYNC_PREREAD;
-       else if (cm->cm_operation == BLKIF_OP_WRITE)
+               break;
+       case BLKIF_OP_WRITE:
+       case BLKIF_OP_WRITE_BARRIER:
+       case BLKIF_OP_FLUSH_DISKCACHE:
                op = BUS_DMASYNC_PREWRITE;
-       else
+               break;
+       default:
                op = 0;
+       }
+
        bus_dmamap_sync(sc->xbd_io_dmat, cm->cm_map, op);
 
        gnttab_free_grant_references(cm->cm_gref_head);