similar to: [PATCH v3 00/41] arch: barrier cleanup + barriers for virt

Displaying 20 results from an estimated 6000 matches similar to: "[PATCH v3 00/41] arch: barrier cleanup + barriers for virt"

2015 Dec 31
54
[PATCH v2 00/34] arch: barrier cleanup + barriers for virt
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
2015 Dec 31
54
[PATCH v2 00/34] arch: barrier cleanup + barriers for virt
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
2015 Dec 30
46
[PATCH 00/34] arch: barrier cleanup + __smp_XXX barriers for virt
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
2015 Dec 30
46
[PATCH 00/34] arch: barrier cleanup + __smp_XXX barriers for virt
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
2015 Dec 20
2
[Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
On Sun, Dec 20, 2015 at 05:07:19PM +0000, Andrew Cooper wrote: > > Very much +1 for fixing this. > > Those names would be fine, but they do add yet another set of options in > an already-complicated area. > > An alternative might be to have the regular smp_{w,r,}mb() not revert > back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a > non-native
2015 Dec 20
2
[Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
On Sun, Dec 20, 2015 at 05:07:19PM +0000, Andrew Cooper wrote: > > Very much +1 for fixing this. > > Those names would be fine, but they do add yet another set of options in > an already-complicated area. > > An alternative might be to have the regular smp_{w,r,}mb() not revert > back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a > non-native
2016 Jan 12
1
[PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release()
On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote: > From: Davidlohr Bueso <dave at stgolabs.net> > > With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()") > it was made clear that the context of this call (and thus set_mb) > is strictly for CPU ordering, as opposed to IO. As such all archs > should use the smp variant of
2016 Jan 12
1
[PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release()
On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote: > From: Davidlohr Bueso <dave at stgolabs.net> > > With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()") > it was made clear that the context of this call (and thus set_mb) > is strictly for CPU ordering, as opposed to IO. As such all archs > should use the smp variant of
2016 Jan 04
3
[PATCH v2 06/32] s390: reuse asm-generic/barrier.h
On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > On s390 read_barrier_depends, smp_read_barrier_depends > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the > asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > > This is in preparation to refactoring this code area. > >
2016 Jan 04
3
[PATCH v2 06/32] s390: reuse asm-generic/barrier.h
On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > On s390 read_barrier_depends, smp_read_barrier_depends > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the > asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > > This is in preparation to refactoring this code area. > >
2015 Dec 30
2
[PATCH 08/34] asm-generic: smp_store_mb should use smp_mb
On Wednesday 30 December 2015 15:24:47 Michael S. Tsirkin wrote: > asm-generic variant of smp_store_mb() calls mb() which is stronger > than implied by both the name and the documentation. > > smp_store_mb is only used by core kernel code at the moment, so > we know no one mis-uses it for an MMIO barrier. > Make it call smp_mb consistently before some arch-specific > code
2015 Dec 30
2
[PATCH 08/34] asm-generic: smp_store_mb should use smp_mb
On Wednesday 30 December 2015 15:24:47 Michael S. Tsirkin wrote: > asm-generic variant of smp_store_mb() calls mb() which is stronger > than implied by both the name and the documentation. > > smp_store_mb is only used by core kernel code at the moment, so > we know no one mis-uses it for an MMIO barrier. > Make it call smp_mb consistently before some arch-specific > code
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
Hi Michael, On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote: > This defines __smp_xxx barriers for powerpc > for use by virtualization. > > smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > This reduces the amount of arch-specific boiler-plate code. > > Signed-off-by: Michael S. Tsirkin <mst at
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
Hi Michael, On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote: > This defines __smp_xxx barriers for powerpc > for use by virtualization. > > smp_xxx barriers are removed as they are > defined correctly by asm-generic/barriers.h > > This reduces the amount of arch-specific boiler-plate code. > > Signed-off-by: Michael S. Tsirkin <mst at
2016 Jan 04
1
[PATCH v2 06/32] s390: reuse asm-generic/barrier.h
On Mon, Jan 04, 2016 at 04:03:39PM +0100, Martin Schwidefsky wrote: > On Mon, 4 Jan 2016 14:20:42 +0100 > Peter Zijlstra <peterz at infradead.org> wrote: > > > On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > > > On s390 read_barrier_depends, smp_read_barrier_depends > > > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic
2016 Jan 04
1
[PATCH v2 06/32] s390: reuse asm-generic/barrier.h
On Mon, Jan 04, 2016 at 04:03:39PM +0100, Martin Schwidefsky wrote: > On Mon, 4 Jan 2016 14:20:42 +0100 > Peter Zijlstra <peterz at infradead.org> wrote: > > > On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > > > On s390 read_barrier_depends, smp_read_barrier_depends > > > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
On Tue, Jan 05, 2016 at 10:51:17AM +0200, Michael S. Tsirkin wrote: > On Tue, Jan 05, 2016 at 09:36:55AM +0800, Boqun Feng wrote: > > Hi Michael, > > > > On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote: > > > This defines __smp_xxx barriers for powerpc > > > for use by virtualization. > > > > > > smp_xxx barriers are
2016 Jan 05
2
[PATCH v2 15/32] powerpc: define __smp_xxx
On Tue, Jan 05, 2016 at 10:51:17AM +0200, Michael S. Tsirkin wrote: > On Tue, Jan 05, 2016 at 09:36:55AM +0800, Boqun Feng wrote: > > Hi Michael, > > > > On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote: > > > This defines __smp_xxx barriers for powerpc > > > for use by virtualization. > > > > > > smp_xxx barriers are
2016 Jan 04
1
[PATCH v2 17/32] arm: define __smp_xxx
On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote: > On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote: > > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > > > On Sat, Jan 02, 2016 at 11:24:38AM +0000, Russell King - ARM Linux wrote: > > > > > > My only concern is that it gives people an additional handle onto a
2016 Jan 04
1
[PATCH v2 17/32] arm: define __smp_xxx
On Mon, Jan 04, 2016 at 02:54:20PM +0100, Peter Zijlstra wrote: > On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote: > > On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > > > On Sat, Jan 02, 2016 at 11:24:38AM +0000, Russell King - ARM Linux wrote: > > > > > > My only concern is that it gives people an additional handle onto a