From ea9c06a66e16a78760446627b163c2a8797f5ebb Mon Sep 17 00:00:00 2001 From: Julien Grall Date: Mon, 2 Jun 2014 00:17:58 +0100 Subject: [PATCH 01/48] 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. --- sys/dev/xen/blkfront/blkfront.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/sys/dev/xen/blkfront/blkfront.c b/sys/dev/xen/blkfront/blkfront.c index 92b5f35..ddd59fd 100644 --- a/sys/dev/xen/blkfront/blkfront.c +++ b/sys/dev/xen/blkfront/blkfront.c @@ -242,12 +242,19 @@ xbd_queue_cb(void *arg, bus_dma_segment_t *segs, int nsegs, int error) last_block_sg = sg + block_segs; } - 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); -- 2.1.0