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 and Xen is always requiring
memory shared with the backend to be cacheable. I'm wondering if we could drop
the call to bus_dmasync_map because the cache maintainance slows down the
process for no appareant 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 fa8d479331b4fdfc119d56f1d73622f0435cf2dd..6768749c3d39a231c345a9d5a521201ca5f4aa0f 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);