Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1299746 > unrolled thread

[PATCH v2 00/34] arch: barrier cleanup + barriers for virt

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 00/34] arch: barrier cleanup + barriers for virt "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
    [PATCH v2 08/32] arm: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
      Re: [PATCH v2 08/32] arm: reuse asm-generic/barrier.h Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-01-02 12:30 +0100
    [PATCH v2 27/32] x86: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
    [PATCH v2 04/32] ia64: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
    [PATCH v2 22/32] s390: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
      Re: [PATCH v2 22/32] s390: define __smp_xxx Peter Zijlstra <peterz@infradead.org> - 2016-01-04 14:50 +0100
        Re: [PATCH v2 22/32] s390: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-04 21:20 +0100
          Re: [PATCH v2 22/32] s390: define __smp_xxx Martin Schwidefsky <schwidefsky@de.ibm.com> - 2016-01-05 09:20 +0100
            Re: [PATCH v2 22/32] s390: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-05 10:40 +0100
              Re: [PATCH v2 22/32] s390: define __smp_xxx Martin Schwidefsky <schwidefsky@de.ibm.com> - 2016-01-05 13:10 +0100
                Re: [PATCH v2 22/32] s390: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-05 14:10 +0100
                  Re: [PATCH v2 22/32] s390: define __smp_xxx Martin Schwidefsky <schwidefsky@de.ibm.com> - 2016-01-05 15:30 +0100
              Re: [PATCH v2 22/32] s390: define __smp_xxx Christian Borntraeger <borntraeger@de.ibm.com> - 2016-01-05 16:50 +0100
                Re: [PATCH v2 22/32] s390: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-05 17:10 +0100
    [PATCH v2 15/32] powerpc: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
      Re: [PATCH v2 15/32] powerpc: define __smp_xxx Boqun Feng <boqun.feng@gmail.com> - 2016-01-05 02:40 +0100
        Re: [PATCH v2 15/32] powerpc: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-05 10:00 +0100
          Re: [PATCH v2 15/32] powerpc: define __smp_xxx Boqun Feng <boqun.feng@gmail.com> - 2016-01-05 11:00 +0100
            Re: [PATCH v2 15/32] powerpc: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-05 17:20 +0100
              Re: [PATCH v2 15/32] powerpc: define __smp_xxx Boqun Feng <boqun.feng@gmail.com> - 2016-01-06 03:00 +0100
                Re: [PATCH v2 15/32] powerpc: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-06 21:30 +0100
                  Re: [PATCH v2 15/32] powerpc: define __smp_xxx Boqun Feng <boqun.feng@gmail.com> - 2016-01-07 01:50 +0100
    [PATCH v2 12/32] x86/um: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
      Re: [PATCH v2 12/32] x86/um: reuse asm-generic/barrier.h Richard Weinberger <richard@nod.at> - 2016-01-06 00:20 +0100
    [PATCH v2 10/32] metag: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
      Re: [PATCH v2 10/32] metag: reuse asm-generic/barrier.h James Hogan <james.hogan@imgtec.com> - 2016-01-05 00:30 +0100
    [PATCH v2 16/32] arm64: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
    [PATCH v2 03/32] ia64: rename nop->iosapic_nop "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
    [PATCH v2 06/32] s390: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:10 +0100
      Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-04 14:30 +0100
        Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h Martin Schwidefsky <schwidefsky@de.ibm.com> - 2016-01-04 16:10 +0100
          Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-04 21:50 +0100
            Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h Martin Schwidefsky <schwidefsky@de.ibm.com> - 2016-01-05 09:10 +0100
        Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-04 21:40 +0100
    [PATCH v2 21/32] mips: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
    [PATCH v2 09/32] arm64: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
    [PATCH v2 32/32] virtio_ring: use virt_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
      Re: [PATCH v2 32/32] virtio_ring: use virt_store_mb Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> - 2016-01-01 18:30 +0100
        Re: [PATCH v2 32/32] virtio_ring: use virt_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-03 10:10 +0100
    [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
      Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2016-01-04 15:10 +0100
      Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rich Felker <dalias@libc.org> - 2016-01-06 00:40 +0100
        Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-06 12:20 +0100
          Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2016-01-06 12:50 +0100
            Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-06 13:00 +0100
              Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2016-01-06 15:40 +0100
                Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rob Landley <rob@landley.net> - 2016-01-06 16:50 +0100
                  Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2016-01-06 18:00 +0100
                    Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rob Landley <rob@landley.net> - 2016-01-06 21:30 +0100
                  Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Geert Uytterhoeven <geert@linux-m68k.org> - 2016-01-06 20:00 +0100
                Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rich Felker <dalias@libc.org> - 2016-01-06 19:30 +0100
                  Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-06 21:30 +0100
                    Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rich Felker <dalias@libc.org> - 2016-01-07 01:00 +0100
                      Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Peter Zijlstra <peterz@infradead.org> - 2016-01-07 14:40 +0100
                        Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rich Felker <dalias@libc.org> - 2016-01-07 20:10 +0100
                      Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-07 17:00 +0100
                      Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-07 18:50 +0100
                        Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rich Felker <dalias@libc.org> - 2016-01-07 20:20 +0100
                          Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-07 23:50 +0100
                            Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb Rich Felker <dalias@libc.org> - 2016-01-08 05:30 +0100
                              Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-08 08:30 +0100
                  Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-06 23:20 +0100
    [PATCH v2 33/34] xenbus: use virt_xxx barriers "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
      Re: [Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers David Vrabel <david.vrabel@citrix.com> - 2016-01-04 12:40 +0100
      Re: [PATCH v2 33/34] xenbus: use virt_xxx barriers Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2016-01-04 13:10 +0100
      Re: [PATCH v2 33/34] xenbus: use virt_xxx barriers Peter Zijlstra <peterz@infradead.org> - 2016-01-04 15:20 +0100
    [PATCH v2 26/32] xtensa: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
    [PATCH v2 34/34] xen/io: use virt_xxx barriers "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
      Re: [Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers David Vrabel <david.vrabel@citrix.com> - 2016-01-04 12:40 +0100
      Re: [PATCH v2 34/34] xen/io: use virt_xxx barriers Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2016-01-04 13:10 +0100
    [PATCH v2 02/32] asm-generic: guard smp_store_release/load_acquire "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-31 20:20 +0100
    [PATCH v2 30/32] virtio_ring: update weak barriers to use __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-01 10:40 +0100
      Re: [PATCH v2 30/32] virtio_ring: update weak barriers to use  __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-01 11:30 +0100

Page 4 of 4 — ← Prev page 1 2 3 [4]

#1304165 — Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb

On Fri, Jan 08, 2016 at 12:41:35AM +0200, Michael S. Tsirkin wrote:
> > > > It would be nice to have these in asm-generic for archs which don't
> > > > define their own versions rather than having cruft like this repeated
> > > > per-arch. Strictly speaking, the volatile u32 used to access the
> > > > 32-bit word containing the u8 or u16 should be
> > > > __attribute__((__may_alias__)) too. Is there an existing kernel type
> > > > for a "may_alias u32" or should it perhaps be added?
> > > > 
> > > > Rich
> > > 
> > > BTW this seems suboptimal for grb and irq variants which apparently
> > > can do things correctly.
> > 
> > In principle I agree, but u8/u16 xchg is mostly unused (completely
> > unused in my builds) and unlikely to matter to performance. Also, the
> > irq variant is only for the original sh2 which is not even produced
> > anymore afaik. Our reimplementation of the sh2 ISA, the J2, has a
> > cas.l instruction that will be used instead because it supports SMP
> > where interrupt masking is insufficient to achieve atomicity.
> > 
> > Rich
> 
> Since it looks like there will soon be active maintainers
> for this arch, I think it's best if I make the minimal possible
> changes and then you guys can rewrite it any way you like,
> drop irq variant or whatever.
> 
> The minimal change is probably the below code but
> the grb variant is just copy paste from xchg_u8
> with a minor tweak -
> can you pls confirm it looks right?

I haven't had a chance to test it, but I don't see anything obviously
wrong with it.

> I tested the llsc code on ppc and x86 and since it's
> portable I know the logic is correct there.

Sounds good. Since it will also be needed for the cas.l variant I'd
rather have this in the main asm/cmpxchg.h where it can be shared if
you see an easy way to do that now, but if not I can take care of it
later when merging cmpxchg-cas.h. Perhaps just putting __xchg_cmpxchg
in the main asm/cmpxchg.h would suffice so that only the thin wrappers
need to be duplicated. Ideally it could even be moved outside of the
arch asm headers, but then there might be annoying header ordering
issues to deal with.

> Will post v3 with this included but would appreciate
> your input first.

Go ahead. Thanks!

Rich

[toc] | [prev] | [next] | [standalone]

#1304233 — Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb

On Thu, Jan 07, 2016 at 11:25:05PM -0500, Rich Felker wrote:
> On Fri, Jan 08, 2016 at 12:41:35AM +0200, Michael S. Tsirkin wrote:
> > > > > It would be nice to have these in asm-generic for archs which don't
> > > > > define their own versions rather than having cruft like this repeated
> > > > > per-arch. Strictly speaking, the volatile u32 used to access the
> > > > > 32-bit word containing the u8 or u16 should be
> > > > > __attribute__((__may_alias__)) too. Is there an existing kernel type
> > > > > for a "may_alias u32" or should it perhaps be added?
> > > > > 
> > > > > Rich
> > > > 
> > > > BTW this seems suboptimal for grb and irq variants which apparently
> > > > can do things correctly.
> > > 
> > > In principle I agree, but u8/u16 xchg is mostly unused (completely
> > > unused in my builds) and unlikely to matter to performance. Also, the
> > > irq variant is only for the original sh2 which is not even produced
> > > anymore afaik. Our reimplementation of the sh2 ISA, the J2, has a
> > > cas.l instruction that will be used instead because it supports SMP
> > > where interrupt masking is insufficient to achieve atomicity.
> > > 
> > > Rich
> > 
> > Since it looks like there will soon be active maintainers
> > for this arch, I think it's best if I make the minimal possible
> > changes and then you guys can rewrite it any way you like,
> > drop irq variant or whatever.
> > 
> > The minimal change is probably the below code but
> > the grb variant is just copy paste from xchg_u8
> > with a minor tweak -
> > can you pls confirm it looks right?
> 
> I haven't had a chance to test it, but I don't see anything obviously
> wrong with it.
> 
> > I tested the llsc code on ppc and x86 and since it's
> > portable I know the logic is correct there.
> 
> Sounds good. Since it will also be needed for the cas.l variant I'd
> rather have this in the main asm/cmpxchg.h where it can be shared if
> you see an easy way to do that now, but if not I can take care of it
> later when merging cmpxchg-cas.h. Perhaps just putting __xchg_cmpxchg
> in the main asm/cmpxchg.h would suffice so that only the thin wrappers
> need to be duplicated.
> Ideally it could even be moved outside of the
> arch asm headers, but then there might be annoying header ordering
> issues to deal with.

Well it isn't possible to put it in cmpxchg.h because you get into
annoying ordering issues: __cmpxchg_u32 is needed
so it has to come after the headers, but the wrappers must
come before the headers.

I put it in a header by itself. This way it's easy to reuse,
and even the thin wrappers won't have to be duplicated.

> 
> > Will post v3 with this included but would appreciate
> > your input first.
> 
> Go ahead. Thanks!
> 
> Rich

[toc] | [prev] | [next] | [standalone]

#1303101 — Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb

On Wed, Jan 06, 2016 at 01:23:50PM -0500, Rich Felker wrote:
> On Wed, Jan 06, 2016 at 03:32:18PM +0100, Peter Zijlstra wrote:
> > On Wed, Jan 06, 2016 at 01:52:17PM +0200, Michael S. Tsirkin wrote:
> > > > > Peter, what do you think? How about I leave this patch as is for now?
> > > > 
> > > > No, and I object to removing the single byte implementation too. Either
> > > > remove the full arch or fix xchg() to conform. xchg() should work on all
> > > > native word sizes, for SH that would be 1,2 and 4 bytes.
> > > 
> > > Rick, maybe you could explain how is current 1 byte xchg on llsc wrong?
> > 
> > It doesn't seem to preserve the 3 other bytes in the word.
> > 
> > > It does use 4 byte accesses but IIUC that is all that exists on
> > > this architecture.
> > 
> > Right, that's not a problem, look at arch/alpha/include/asm/xchg.h for
> > example. A store to another portion of the word should make the
> > store-conditional fail and we'll retry the loop.
> > 
> > The short versions should however preserve the other bytes in the word.
> 
> Indeed. Also, accesses must be aligned, so the asm needs to round down
> to an aligned address and perform a correct read-modify-write on it,
> placing the new byte in the correct offset in the word.
> 
> Alternatively (my preference) this logic can be impemented in C as a
> wrapper around the 32-bit cmpxchg. I think this is less error-prone
> and it can be shared between the multiple sh cmpxchg back-ends,
> including the new cas.l one we need for J2.

Sounds much more reasonable.

> > SH's cmpxchg() is equally incomplete and does not provide 1 and 2 byte
> > versions.
> > 
> > In any case, I'm all for rm -rf arch/sh/, one less arch to worry about
> > is always good, but ISTR some people wanting to resurrect SH:
> > 
> >   http://old.lwn.net/Articles/647636/
> > 
> > Rob, Jeff, Sato-san, might I suggest you send a MAINTAINERS patch and
> > take up an active interest in SH lest someone 'accidentally' nukes it?
> 
> We're in the process of preparing such a proposal right now. That
> current intent is that Sato-san and I will co-maintain arch/sh. We'll
> include more details about motivation, proposed development direction,
> existing work to be merged, etc. in that proposal.
> 
> Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299761 — [PATCH v2 33/34] xenbus: use virt_xxx barriers

drivers/xen/xenbus/xenbus_comms.c uses
full memory barriers to communicate with the other side.

For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
would be sufficient, so mb() and wmb() here are only needed if
a non-SMP guest runs on an SMP host.

Switch to virt_xxx barriers which serve this exact purpose.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 drivers/xen/xenbus/xenbus_comms.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index fdb0f33..ecdecce 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len)
 			avail = len;
 
 		/* Must write data /after/ reading the consumer index. */
-		mb();
+		virt_mb();
 
 		memcpy(dst, data, avail);
 		data += avail;
 		len -= avail;
 
 		/* Other side must not see new producer until data is there. */
-		wmb();
+		virt_wmb();
 		intf->req_prod += avail;
 
 		/* Implies mb(): other side will see the updated producer. */
@@ -180,14 +180,14 @@ int xb_read(void *data, unsigned len)
 			avail = len;
 
 		/* Must read data /after/ reading the producer index. */
-		rmb();
+		virt_rmb();
 
 		memcpy(data, src, avail);
 		data += avail;
 		len -= avail;
 
 		/* Other side must not see free space until we've copied out */
-		mb();
+		virt_mb();
 		intf->rsp_cons += avail;
 
 		pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);
-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300655 — Re: [Xen-devel] [PATCH v2 33/34] xenbus: use virt_xxx barriers

On 31/12/15 19:10, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.

Acked-by: David Vrabel <david.vrabel@citrix.com>

If you're feeling particularly keen there's a rmb() consume_one_event()
in drivers/xen/events/events_fifo.c that can be converted to virt_rmb()
as well.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300689 — Re: [PATCH v2 33/34] xenbus: use virt_xxx barriers

On Thu, 31 Dec 2015, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Are you also going to take care of

drivers/xen/grant-table.c
drivers/xen/evtchn.c
drivers/xen/events/events_fifo.c
drivers/xen/xen-scsiback.c
drivers/xen/tmem.c
drivers/xen/xen-pciback/pci_stub.c
drivers/xen/xen-pciback/pciback_ops.c

?


>  drivers/xen/xenbus/xenbus_comms.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index fdb0f33..ecdecce 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len)
>  			avail = len;
>  
>  		/* Must write data /after/ reading the consumer index. */
> -		mb();
> +		virt_mb();
>  
>  		memcpy(dst, data, avail);
>  		data += avail;
>  		len -= avail;
>  
>  		/* Other side must not see new producer until data is there. */
> -		wmb();
> +		virt_wmb();
>  		intf->req_prod += avail;
>  
>  		/* Implies mb(): other side will see the updated producer. */
> @@ -180,14 +180,14 @@ int xb_read(void *data, unsigned len)
>  			avail = len;
>  
>  		/* Must read data /after/ reading the producer index. */
> -		rmb();
> +		virt_rmb();
>  
>  		memcpy(data, src, avail);
>  		data += avail;
>  		len -= avail;
>  
>  		/* Other side must not see free space until we've copied out */
> -		mb();
> +		virt_mb();
>  		intf->rsp_cons += avail;
>  
>  		pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);
> -- 
> MST
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300765 — Re: [PATCH v2 33/34] xenbus: use virt_xxx barriers

On Thu, Dec 31, 2015 at 09:10:01PM +0200, Michael S. Tsirkin wrote:
> drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>  drivers/xen/xenbus/xenbus_comms.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index fdb0f33..ecdecce 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -123,14 +123,14 @@ int xb_write(const void *data, unsigned len)
>  			avail = len;
>  
>  		/* Must write data /after/ reading the consumer index. */
> -		mb();
> +		virt_mb();
>  

So its possible to remove this barrier entirely, see the "CONTROL
DEPENDNCIES" chunk of memory-barrier.txt.

But do that in a separate patch series and only if you really really
need the performance.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299762 — [PATCH v2 26/32] xtensa: define __smp_xxx

This defines __smp_xxx barriers for xtensa,
for use by virtualization.

smp_xxx barriers are removed as they are
defined correctly by asm-generic/barriers.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/xtensa/include/asm/barrier.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/xtensa/include/asm/barrier.h b/arch/xtensa/include/asm/barrier.h
index 5b88774..956596e 100644
--- a/arch/xtensa/include/asm/barrier.h
+++ b/arch/xtensa/include/asm/barrier.h
@@ -13,8 +13,8 @@
 #define rmb() barrier()
 #define wmb() mb()
 
-#define smp_mb__before_atomic()		barrier()
-#define smp_mb__after_atomic()		barrier()
+#define __smp_mb__before_atomic()		barrier()
+#define __smp_mb__after_atomic()		barrier()
 
 #include <asm-generic/barrier.h>
 
-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299763 — [PATCH v2 34/34] xen/io: use virt_xxx barriers

include/xen/interface/io/ring.h uses
full memory barriers to communicate with the other side.

For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
would be sufficient, so mb() and wmb() here are only needed if
a non-SMP guest runs on an SMP host.

Switch to virt_xxx barriers which serve this exact purpose.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/xen/interface/io/ring.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index 7dc685b..21f4fbd 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h
@@ -208,12 +208,12 @@ struct __name##_back_ring {						\
 
 
 #define RING_PUSH_REQUESTS(_r) do {					\
-    wmb(); /* back sees requests /before/ updated producer index */	\
+    virt_wmb(); /* back sees requests /before/ updated producer index */	\
     (_r)->sring->req_prod = (_r)->req_prod_pvt;				\
 } while (0)
 
 #define RING_PUSH_RESPONSES(_r) do {					\
-    wmb(); /* front sees responses /before/ updated producer index */	\
+    virt_wmb(); /* front sees responses /before/ updated producer index */	\
     (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt;				\
 } while (0)
 
@@ -250,9 +250,9 @@ struct __name##_back_ring {						\
 #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do {		\
     RING_IDX __old = (_r)->sring->req_prod;				\
     RING_IDX __new = (_r)->req_prod_pvt;				\
-    wmb(); /* back sees requests /before/ updated producer index */	\
+    virt_wmb(); /* back sees requests /before/ updated producer index */	\
     (_r)->sring->req_prod = __new;					\
-    mb(); /* back sees new requests /before/ we check req_event */	\
+    virt_mb(); /* back sees new requests /before/ we check req_event */	\
     (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) <		\
 		 (RING_IDX)(__new - __old));				\
 } while (0)
@@ -260,9 +260,9 @@ struct __name##_back_ring {						\
 #define RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(_r, _notify) do {		\
     RING_IDX __old = (_r)->sring->rsp_prod;				\
     RING_IDX __new = (_r)->rsp_prod_pvt;				\
-    wmb(); /* front sees responses /before/ updated producer index */	\
+    virt_wmb(); /* front sees responses /before/ updated producer index */	\
     (_r)->sring->rsp_prod = __new;					\
-    mb(); /* front sees new responses /before/ we check rsp_event */	\
+    virt_mb(); /* front sees new responses /before/ we check rsp_event */	\
     (_notify) = ((RING_IDX)(__new - (_r)->sring->rsp_event) <		\
 		 (RING_IDX)(__new - __old));				\
 } while (0)
@@ -271,7 +271,7 @@ struct __name##_back_ring {						\
     (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);			\
     if (_work_to_do) break;						\
     (_r)->sring->req_event = (_r)->req_cons + 1;			\
-    mb();								\
+    virt_mb();								\
     (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);			\
 } while (0)
 
@@ -279,7 +279,7 @@ struct __name##_back_ring {						\
     (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);			\
     if (_work_to_do) break;						\
     (_r)->sring->rsp_event = (_r)->rsp_cons + 1;			\
-    mb();								\
+    virt_mb();								\
     (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);			\
 } while (0)
 
-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300650 — Re: [Xen-devel] [PATCH v2 34/34] xen/io: use virt_xxx barriers

On 31/12/15 19:10, Michael S. Tsirkin wrote:
> include/xen/interface/io/ring.h uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.

Acked-by: David Vrabel <david.vrabel@citrix.com>

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300687 — Re: [PATCH v2 34/34] xen/io: use virt_xxx barriers

On Thu, 31 Dec 2015, Michael S. Tsirkin wrote:
> include/xen/interface/io/ring.h uses
> full memory barriers to communicate with the other side.
> 
> For guests compiled with CONFIG_SMP, smp_wmb and smp_mb
> would be sufficient, so mb() and wmb() here are only needed if
> a non-SMP guest runs on an SMP host.
> 
> Switch to virt_xxx barriers which serve this exact purpose.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  include/xen/interface/io/ring.h | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
> index 7dc685b..21f4fbd 100644
> --- a/include/xen/interface/io/ring.h
> +++ b/include/xen/interface/io/ring.h
> @@ -208,12 +208,12 @@ struct __name##_back_ring {						\
>  
>  
>  #define RING_PUSH_REQUESTS(_r) do {					\
> -    wmb(); /* back sees requests /before/ updated producer index */	\
> +    virt_wmb(); /* back sees requests /before/ updated producer index */	\
>      (_r)->sring->req_prod = (_r)->req_prod_pvt;				\
>  } while (0)
>  
>  #define RING_PUSH_RESPONSES(_r) do {					\
> -    wmb(); /* front sees responses /before/ updated producer index */	\
> +    virt_wmb(); /* front sees responses /before/ updated producer index */	\
>      (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt;				\
>  } while (0)
>  
> @@ -250,9 +250,9 @@ struct __name##_back_ring {						\
>  #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do {		\
>      RING_IDX __old = (_r)->sring->req_prod;				\
>      RING_IDX __new = (_r)->req_prod_pvt;				\
> -    wmb(); /* back sees requests /before/ updated producer index */	\
> +    virt_wmb(); /* back sees requests /before/ updated producer index */	\
>      (_r)->sring->req_prod = __new;					\
> -    mb(); /* back sees new requests /before/ we check req_event */	\
> +    virt_mb(); /* back sees new requests /before/ we check req_event */	\
>      (_notify) = ((RING_IDX)(__new - (_r)->sring->req_event) <		\
>  		 (RING_IDX)(__new - __old));				\
>  } while (0)
> @@ -260,9 +260,9 @@ struct __name##_back_ring {						\
>  #define RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(_r, _notify) do {		\
>      RING_IDX __old = (_r)->sring->rsp_prod;				\
>      RING_IDX __new = (_r)->rsp_prod_pvt;				\
> -    wmb(); /* front sees responses /before/ updated producer index */	\
> +    virt_wmb(); /* front sees responses /before/ updated producer index */	\
>      (_r)->sring->rsp_prod = __new;					\
> -    mb(); /* front sees new responses /before/ we check rsp_event */	\
> +    virt_mb(); /* front sees new responses /before/ we check rsp_event */	\
>      (_notify) = ((RING_IDX)(__new - (_r)->sring->rsp_event) <		\
>  		 (RING_IDX)(__new - __old));				\
>  } while (0)
> @@ -271,7 +271,7 @@ struct __name##_back_ring {						\
>      (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);			\
>      if (_work_to_do) break;						\
>      (_r)->sring->req_event = (_r)->req_cons + 1;			\
> -    mb();								\
> +    virt_mb();								\
>      (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);			\
>  } while (0)
>  
> @@ -279,7 +279,7 @@ struct __name##_back_ring {						\
>      (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);			\
>      if (_work_to_do) break;						\
>      (_r)->sring->rsp_event = (_r)->rsp_cons + 1;			\
> -    mb();								\
> +    virt_mb();								\
>      (_work_to_do) = RING_HAS_UNCONSUMED_RESPONSES(_r);			\
>  } while (0)
>  
> -- 
> MST
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299764 — [PATCH v2 02/32] asm-generic: guard smp_store_release/load_acquire

Allow architectures to override smp_store_release
and smp_load_acquire by guarding the defines
in asm-generic/barrier.h with ifndef directives.

This is in preparation to reusing asm-generic/barrier.h
on architectures which have their own definition
of these macros.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
 include/asm-generic/barrier.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 0f45f93..987b2e0 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -104,13 +104,16 @@
 #define smp_mb__after_atomic()	smp_mb()
 #endif
 
+#ifndef smp_store_release
 #define smp_store_release(p, v)						\
 do {									\
 	compiletime_assert_atomic_type(*p);				\
 	smp_mb();							\
 	WRITE_ONCE(*p, v);						\
 } while (0)
+#endif
 
+#ifndef smp_load_acquire
 #define smp_load_acquire(p)						\
 ({									\
 	typeof(*p) ___p1 = READ_ONCE(*p);				\
@@ -118,6 +121,7 @@ do {									\
 	smp_mb();							\
 	___p1;								\
 })
+#endif
 
 #endif /* !__ASSEMBLY__ */
 #endif /* __ASM_GENERIC_BARRIER_H */
-- 
MST

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299865 — [PATCH v2 30/32] virtio_ring: update weak barriers to use __smp_xxx

virtio ring uses smp_wmb on SMP and wmb on !SMP,
the reason for the later being that it might be
talking to another kernel on the same SMP machine.

This is exactly what __smp_XXX barriers do,
so switch to these instead of homegrown ifdef hacks.

Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Alexander Duyck <alexander.duyck@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/linux/virtio_ring.h | 25 ++++---------------------
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 67e06fe..f3fa55b 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -12,7 +12,7 @@
  * anyone care?
  *
  * For virtio_pci on SMP, we don't need to order with respect to MMIO
- * accesses through relaxed memory I/O windows, so smp_mb() et al are
+ * accesses through relaxed memory I/O windows, so virt_mb() et al are
  * sufficient.
  *
  * For using virtio to talk to real devices (eg. other heterogeneous
@@ -21,11 +21,10 @@
  * actually quite cheap.
  */
 
-#ifdef CONFIG_SMP
 static inline void virtio_mb(bool weak_barriers)
 {
 	if (weak_barriers)
-		smp_mb();
+		virt_mb();
 	else
 		mb();
 }
@@ -33,7 +32,7 @@ static inline void virtio_mb(bool weak_barriers)
 static inline void virtio_rmb(bool weak_barriers)
 {
 	if (weak_barriers)
-		smp_rmb();
+		virt_rmb();
 	else
 		rmb();
 }
@@ -41,26 +40,10 @@ static inline void virtio_rmb(bool weak_barriers)
 static inline void virtio_wmb(bool weak_barriers)
 {
 	if (weak_barriers)
-		smp_wmb();
+		virt_wmb();
 	else
 		wmb();
 }
-#else
-static inline void virtio_mb(bool weak_barriers)
-{
-	mb();
-}
-
-static inline void virtio_rmb(bool weak_barriers)
-{
-	rmb();
-}
-
-static inline void virtio_wmb(bool weak_barriers)
-{
-	wmb();
-}
-#endif
 
 struct virtio_device;
 struct virtqueue;
-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1299876 — Re: [PATCH v2 30/32] virtio_ring: update weak barriers to use __smp_xxx

On Fri, Jan 01, 2016 at 11:39:40AM +0200, Michael S. Tsirkin wrote:
> virtio ring uses smp_wmb on SMP and wmb on !SMP,
> the reason for the later being that it might be
> talking to another kernel on the same SMP machine.
> 
> This is exactly what __smp_XXX barriers do,
> so switch to these instead of homegrown ifdef hacks.
> 
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

The subject and commit log should say
virt_xxx and not __smp_xxx - I fixed this up in
my tree.

> ---
>  include/linux/virtio_ring.h | 25 ++++---------------------
>  1 file changed, 4 insertions(+), 21 deletions(-)
> 
> diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
> index 67e06fe..f3fa55b 100644
> --- a/include/linux/virtio_ring.h
> +++ b/include/linux/virtio_ring.h
> @@ -12,7 +12,7 @@
>   * anyone care?
>   *
>   * For virtio_pci on SMP, we don't need to order with respect to MMIO
> - * accesses through relaxed memory I/O windows, so smp_mb() et al are
> + * accesses through relaxed memory I/O windows, so virt_mb() et al are
>   * sufficient.
>   *
>   * For using virtio to talk to real devices (eg. other heterogeneous
> @@ -21,11 +21,10 @@
>   * actually quite cheap.
>   */
>  
> -#ifdef CONFIG_SMP
>  static inline void virtio_mb(bool weak_barriers)
>  {
>  	if (weak_barriers)
> -		smp_mb();
> +		virt_mb();
>  	else
>  		mb();
>  }
> @@ -33,7 +32,7 @@ static inline void virtio_mb(bool weak_barriers)
>  static inline void virtio_rmb(bool weak_barriers)
>  {
>  	if (weak_barriers)
> -		smp_rmb();
> +		virt_rmb();
>  	else
>  		rmb();
>  }
> @@ -41,26 +40,10 @@ static inline void virtio_rmb(bool weak_barriers)
>  static inline void virtio_wmb(bool weak_barriers)
>  {
>  	if (weak_barriers)
> -		smp_wmb();
> +		virt_wmb();
>  	else
>  		wmb();
>  }
> -#else
> -static inline void virtio_mb(bool weak_barriers)
> -{
> -	mb();
> -}
> -
> -static inline void virtio_rmb(bool weak_barriers)
> -{
> -	rmb();
> -}
> -
> -static inline void virtio_wmb(bool weak_barriers)
> -{
> -	wmb();
> -}
> -#endif
>  
>  struct virtio_device;
>  struct virtqueue;
> -- 
> MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | linux.kernel

csiph-web