similar to: [PATCH] virtio_ring: switch to dma_XX barriers for rpmsg

On Thu, Apr 19, 2018 at 07:39:21PM +0200, Paolo Bonzini wrote: > On 19/04/2018 19:35, Michael S. Tsirkin wrote: > > virtio is using barriers to order memory accesses, thus > > dma_wmb/rmb is a good match. > > > > Build-tested on x86: Before > > > > [mst at tuck linux]$ size drivers/virtio/virtio_ring.o > > text data bss dec hex

On Thu, Apr 19, 2018 at 07:39:21PM +0200, Paolo Bonzini wrote: > On 19/04/2018 19:35, Michael S. Tsirkin wrote: > > virtio is using barriers to order memory accesses, thus > > dma_wmb/rmb is a good match. > > > > Build-tested on x86: Before > > > > [mst at tuck linux]$ size drivers/virtio/virtio_ring.o > > text data bss dec hex

On 19/04/2018 19:35, Michael S. Tsirkin wrote: > virtio is using barriers to order memory accesses, thus > dma_wmb/rmb is a good match. > > Build-tested on x86: Before > > [mst at tuck linux]$ size drivers/virtio/virtio_ring.o > text data bss dec hex filename > 11392 820 0 12212 2fb4 drivers/virtio/virtio_ring.o > > After > mst

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

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. The advantage to this is that these barriers are available to uniprocessor builds as well so the performance should improve under such a configuration. Signed-off-by:

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. The advantage to this is that these barriers are available to uniprocessor builds as well so the performance should improve under such a configuration. Signed-off-by:

From: David Riley <davidriley at chromium.org> virtio_gpu_get_caps_ioctl could return success with invalid data if a second caller to the function occurred after the entry was created in virtio_gpu_cmd_get_capset but prior to the virtio_gpu_cmd_capset_cb callback being called. This could leak contents of memory as well since the caps_cache allocation is done without zeroing.

On Thu, Dec 17, 2015 at 12:22:22PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > Seems to give a speedup on my box but I'm less sure about this one. E.g. as > > xchng faster than mfence on all/most intel CPUs? Anyone has an opinion? > > Would help if you Cc people who would actually know this :-) Good point. Glad

On Thu, Dec 17, 2015 at 12:22:22PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > Seems to give a speedup on my box but I'm less sure about this one. E.g. as > > xchng faster than mfence on all/most intel CPUs? Anyone has an opinion? > > Would help if you Cc people who would actually know this :-) Good point. Glad

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > +static inline void virtio_store_mb(bool weak_barriers, > > + __virtio16 *p, __virtio16 v) > > +{ > > +#ifdef CONFIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif >

On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > +static inline void virtio_store_mb(bool weak_barriers, > > + __virtio16 *p, __virtio16 v) > > +{ > > +#ifdef CONFIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif >

Fixes: 55e49dc43a8 ("virtio_ring: switch to dma_XX barriers for rpmsg") Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- tools/virtio/asm/barrier.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/virtio/asm/barrier.h b/tools/virtio/asm/barrier.h index 0ac3caf90877..d0351f83aebe 100644 --- a/tools/virtio/asm/barrier.h +++

On 19/04/2018 19:46, Michael S. Tsirkin wrote: >> This should be okay, but I wonder if there should be a virtio_wmb(...) >> or an "if (weak_barriers) wmb()" before the "writel" in vm_notify >> (drivers/virtio/virtio_mmio.c). >> >> Thanks, >> >> Paolo > That one uses weak barriers AFAIK. > > IIUC you mean rproc_virtio_notify.

We need a full barrier after writing out event index, using smp_store_mb there seems better than open-coding. As usual, we need a wrapper to account for strong barriers/non smp. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Seems to give a speedup

We need a full barrier after writing out event index, using smp_store_mb there seems better than open-coding. As usual, we need a wrapper to account for strong barriers/non smp. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Seems to give a speedup