aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/virtio_blk.h
diff options
context:
space:
mode:
authorMichael S. Tsirkin <mst@redhat.com>2010-01-28 00:42:23 +0200
committerRusty Russell <rusty@rustcorp.com.au>2010-02-24 14:22:25 +1030
commitd57ed95da483418e8b0433da693c9168dd0a2df6 (patch)
tree0eb215813f3066bf634a395d02cf4aab3ba94fc6 /include/linux/virtio_blk.h
parent97a545ab6ce922a0f868d192718a48a0091ebc5e (diff)
downloadkernel_samsung_smdk4412-d57ed95da483418e8b0433da693c9168dd0a2df6.zip
kernel_samsung_smdk4412-d57ed95da483418e8b0433da693c9168dd0a2df6.tar.gz
kernel_samsung_smdk4412-d57ed95da483418e8b0433da693c9168dd0a2df6.tar.bz2
virtio: use smp_XX barriers on SMP
virtio is communicating with a virtual "device" that actually runs on another host processor. Thus SMP barriers can be used to control memory access ordering. Where possible, we should use SMP barriers which are more lightweight than mandatory barriers, because mandatory barriers also control MMIO effects on accesses through relaxed memory I/O windows (which virtio does not use) (compare specifically smp_rmb and rmb on x86_64). We can't just use smp_mb and friends though, because we must force memory ordering even if guest is UP since host could be running on another CPU, but SMP barriers are defined to barrier() in that configuration. So, for UP fall back to mandatory barriers instead. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Diffstat (limited to 'include/linux/virtio_blk.h')
0 files changed, 0 insertions, 0 deletions