Page MenuHomeFreeBSD

xen/blkfront: WRITE_BARRIER and FLUSH_DISKCACHE require barrier
Needs ReviewPublic

Authored by julien.grall_citrix.com on Oct 5 2015, 5:44 PM.

Details

Reviewers
royger
Summary

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 Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 685
Build 685: arc lint + arc unit

Event Timeline

julien.grall_citrix.com retitled this revision from to xen/blkfront: WRITE_BARRIER and FLUSH_DISKCACHE require barrier.
julien.grall_citrix.com updated this object.
julien.grall_citrix.com edited the test plan for this revision. (Show Details)
julien.grall_citrix.com added a reviewer: royger.

No, we can't avoid the bus_dmamap_sync call, this function performs the bouncing of data if needed.

sys/dev/xen/blkfront/blkfront.c
272

For BLKIF_OP_FLUSH_DISKCACHE you can avoid the call to bus_dmamap_sync, it contains no data. Did you also look at xbd_int? It seems a similar treatment would be needed there in order to avoid calling bus_dmamap_sync with op == 0 for BLKIF_OP_FLUSH_DISKCACHE requests.