search for: 7b21e34fd1c2

...ndif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ > > Hi: > > I believe this depends on Michael's patch of > > "[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg" > > ? > > Thanks We already have below commit and some other related commits in the tree: 7b21e34fd1c2 ("virtio: harsher barriers for rpmsg.") They should have already guaranteed that virtio_Xmb() will be OK for hardware devices when vq->weak_barriers is false. If my understanding is correct, the barriers used in this case are overkill. So Michael's patch is to make the barriers we...

...ndif /* _UAPI_LINUX_VIRTIO_CONFIG_H */ > > Hi: > > I believe this depends on Michael's patch of > > "[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg" > > ? > > Thanks We already have below commit and some other related commits in the tree: 7b21e34fd1c2 ("virtio: harsher barriers for rpmsg.") They should have already guaranteed that virtio_Xmb() will be OK for hardware devices when vq->weak_barriers is false. If my understanding is correct, the barriers used in this case are overkill. So Michael's patch is to make the barriers we...

...#39;s patch of > > > > > > "[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg" > > > > > > ? > > > > > > Thanks > > We already have below commit and some other related commits > > in the tree: > > > > 7b21e34fd1c2 ("virtio: harsher barriers for rpmsg.") > > > > They should have already guaranteed that virtio_Xmb() will > > be OK for hardware devices when vq->weak_barriers is false. > > If my understanding is correct, the barriers used in this > > case are overkill....

...gt; Hi: >> >> I believe this depends on Michael's patch of >> >> "[PATCH] virtio_ring: switch to dma_XX barriers for rpmsg" >> >> ? >> >> Thanks > We already have below commit and some other related commits > in the tree: > > 7b21e34fd1c2 ("virtio: harsher barriers for rpmsg.") > > They should have already guaranteed that virtio_Xmb() will > be OK for hardware devices when vq->weak_barriers is false. > If my understanding is correct, the barriers used in this > case are overkill. So Michael's patch is...

On 04/08/2015 01:42 AM, Michael S. Tsirkin wrote: > On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: >> This change makes it so that instead of using smp_wmb/rmb which varies >> depending on the kernel configuration we can can use dma_wmb/rmb which for >> most architectures should be equal to or slightly more strict than >> smp_wmb/rmb. >> >>

On 04/08/2015 01:42 AM, Michael S. Tsirkin wrote: > On Tue, Apr 07, 2015 at 05:47:42PM -0700, Alexander Duyck wrote: >> This change makes it so that instead of using smp_wmb/rmb which varies >> depending on the kernel configuration we can can use dma_wmb/rmb which for >> most architectures should be equal to or slightly more strict than >> smp_wmb/rmb. >> >>

This patch introduces the support for VIRTIO_F_IO_BARRIER. When this feature is negotiated, driver will use the barriers suitable for hardware devices. Signed-off-by: Tiwei Bie <tiwei.bie at intel.com> --- drivers/virtio/virtio_ring.c | 5 +++++ include/uapi/linux/virtio_config.h | 8 +++++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_ring.c

This patch introduces the support for VIRTIO_F_IO_BARRIER. When this feature is negotiated, driver will use the barriers suitable for hardware devices. Signed-off-by: Tiwei Bie <tiwei.bie at intel.com> --- drivers/virtio/virtio_ring.c | 5 +++++ include/uapi/linux/virtio_config.h | 8 +++++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_ring.c