* Re: [v3,11/41] mips: reuse asm-generic/barrier.h
From: Paul E. McKenney @ 2016-01-27 23:32 UTC (permalink / raw)
To: Will Deacon
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, Peter Zijlstra,
virtualization, H. Peter Anvin, sparclinux, Ingo Molnar,
linux-arch, linux-s390, Russell King - ARM Linux,
user-mode-linux-devel, linux-sh, Michael Ellerman, x86, xen-devel,
Ingo Molnar, linux-xtensa, james.hogan, Arnd Bergmann,
Stefano Stabellini, adi-buildroot-devel, Leonid Yegoshin,
ddaney.cavm, Thomas Gleixner, linux-metag
In-Reply-To: <20160127102546.GD2390@arm.com>
On Wed, Jan 27, 2016 at 10:25:46AM +0000, Will Deacon wrote:
> On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote:
> > On Tue, Jan 26, 2016 at 12:16:09PM +0000, Will Deacon wrote:
> > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> > > > On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote:
> > > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> > > > > > PPC Overlapping Group-B sets version 4
> > > > > > ""
> > > > > > (* When the Group-B sets from two different barriers involve instructions in
> > > > > > the same thread, within that thread one set must contain the other.
> > > > > >
> > > > > > P0 P1 P2
> > > > > > Rx=1 Wy=1 Wz=2
> > > > > > dep. lwsync lwsync
> > > > > > Ry=0 Wz=1 Wx=1
> > > > > > Rz=1
> > > > > >
> > > > > > assert(!(z=2))
> > > > > >
> > > > > > Forbidden by ppcmem, allowed by herd.
> > > > > > *)
> > > > > > {
> > > > > > 0:r1=x; 0:r2=y; 0:r3=z;
> > > > > > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
> > > > > > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
> > > > > > }
> > > > > > P0 | P1 | P2 ;
> > > > > > lwz r6,0(r1) | stw r4,0(r2) | stw r5,0(r3) ;
> > > > > > xor r7,r6,r6 | lwsync | lwsync ;
> > > > > > lwzx r7,r7,r2 | stw r4,0(r3) | stw r4,0(r1) ;
> > > > > > lwz r8,0(r3) | | ;
> > > > > >
> > > > > > exists
> > > > > > (z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)
> > > > >
> > > > > That really hurts. Assuming that the "assert(!(z=2))" is actually there
> > > > > to constrain the coherence order of z to be {0->1->2}, then I think that
> > > > > this test is forbidden on arm using dmb instead of lwsync. That said, I
> > > > > also don't think the Rz=1 in P0 changes anything.
> > > >
> > > > What about the smp_wmb() variant of dmb that orders only stores?
> > >
> > > Tricky, but I think it still works out if the coherence order of z is as
> > > I described above. The line of reasoning is weird though -- I ended up
> > > considering the two cases where P0 reads z before and after it reads x
> > > and what that means for the read of y.
> >
> > By "works out" you mean that ARM prohibits the outcome?
>
> Yes, that's my understanding.
Very good, we have agreement between the two architectures, then. ;-)
Thanx, Paul
^ permalink raw reply
* Re: [v3,11/41] mips: reuse asm-generic/barrier.h
From: Paul E. McKenney @ 2016-01-27 23:30 UTC (permalink / raw)
To: Boqun Feng
Cc: linux-mips, linux-ia64@vger.kernel.org, Michael S. Tsirkin,
Peter Zijlstra, Will Deacon, virtualization, Peter Anvin,
sparclinux, Ingo Molnar, linux-arch@vger.kernel.org, linux-s390,
Russell King - ARM Linux, Herbert Xu, linux-sh, Michael Ellerman,
the arch/x86 maintainers, xen-devel, Ingo Molnar, linux-xtensa,
James Hogan, uml-devel, Stefano Stabellini <stefano.sta>
In-Reply-To: <20160127020447.GA1293@fixme-laptop.cn.ibm.com>
On Wed, Jan 27, 2016 at 10:04:47AM +0800, Boqun Feng wrote:
> On Tue, Jan 26, 2016 at 03:29:21PM -0800, Paul E. McKenney wrote:
> > On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote:
> > > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > >
> > > > You might as well just write it as
> > > >
> > > > struct foo x = READ_ONCE(*ptr);
> > > > x->bar = 5;
> > > >
> > > > because that "smp_read_barrier_depends()" does NOTHING wrt the second write.
> > >
> > > Just to clarify: on alpha it adds a memory barrier, but that memory
> > > barrier is useless.
> >
> > No trailing data-dependent read, so agreed, no smp_read_barrier_depends()
> > needed. That said, I believe that we should encourage rcu_dereference*()
> > or lockless_dereference() instead of READ_ONCE() for documentation
> > reasons, though.
> >
> > > On non-alpha, it is a no-op, and obviously does nothing simply because
> > > it generates no code.
> > >
> > > So if anybody believes that the "smp_read_barrier_depends()" does
> > > something, they are *wrong*.
> >
> > The other problem with smp_read_barrier_depends() is that it is often
> > a pain figuring out which prior load it is supposed to apply to.
> > Hence my preference for rcu_dereference*() and lockless_dereference().
> >
>
> Because semantically speaking, rcu_derefence*() and
> lockless_dereference() are CONSUME(i.e. data/address dependent
> read->read and read->write pairs are ordered), whereas
> smp_read_barrier_depends() only guarantees read->read pairs with data
> dependency are ordered, right?
>
> If so, maybe we need to call it out in memory-barriers.txt, for example:
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 904ee42..6b262c2 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -1703,8 +1703,8 @@ There are some more advanced barrier functions:
>
>
> (*) lockless_dereference();
> - This can be thought of as a pointer-fetch wrapper around the
> - smp_read_barrier_depends() data-dependency barrier.
> + This is a load, and any load or store that has a data dependency on the
> + value returned by this load won't be reordered before this load.
This is a good start, but more is needed to warn people off of
smp_read_barrier_depends(). But yes, better explanation would be good.
Thanx, Paul
> This is also similar to rcu_dereference(), but in cases where
> object lifetime is handled by some mechanism other than RCU, for
>
>
> Regards,
> Boqun
>
> > > And if anybody sends out an email with that smp_read_barrier_depends()
> > > in an example, they are actively just confusing other people, which is
> > > even worse than just being wrong. Which is why I jumped in.
> > >
> > > So stop perpetuating the myth that smp_read_barrier_depends() does
> > > something here. It does not. It's a bug, and it has become this "mind
> > > virus" for some people that seem to believe that it does something.
> >
> > It looks like I should add words to memory-barriers.txt de-emphasizing
> > smp_read_barrier_depends(). I will take a look at that.
> >
> > > I had to remove this crap once from the kernel already, see commit
> > > 105ff3cbf225 ("atomic: remove all traces of READ_ONCE_CTRL() and
> > > atomic*_read_ctrl()").
> > >
> > > I don't want to ever see that broken construct again. And I want to
> > > make sure that everybody is educated about how broken it was. I'm
> > > extremely unhappy that it came up again.
> >
> > Well, if it makes you feel better, that was control dependencies and this
> > was data dependencies. So it was not -exactly- the same. ;-)
> >
> > (Sorry, couldn't resist...)
> >
> > > If it turns out that some architecture does actually need a barrier
> > > between a read and a dependent write, then that will mean that
> > >
> > > (a) we'll have to make up a _new_ barrier, because
> > > "smp_read_barrier_depends()" is not that barrier. We'll presumably
> > > then have to make that new barrier part of "rcu_derefence()" and
> > > friends.
> >
> > Agreed. We can worry about whether or not we replace the current
> > smp_read_barrier_depends() with that new barrier when and if such
> > hardware appears.
> >
> > > (b) we will have found an architecture with even worse memory
> > > ordering semantics than alpha, and we'll have to stop castigating
> > > alpha for being the worst memory ordering ever.
> >
> > ;-) ;-) ;-)
> >
> > > but I sincerely hope that we'll never find that kind of broken architecture.
> >
> > Apparently at least some hardware vendors are reading memory-barriers.txt,
> > so perhaps the odds of that kind of breakage have reduced.
> >
> > Thanx, Paul
> >
^ permalink raw reply
* Re: [PULL] virtio: fixes, tests
From: Linus Torvalds @ 2016-01-27 22:57 UTC (permalink / raw)
To: Michael S. Tsirkin, Junio C Hamano
Cc: jmarchan, KVM list, Network Development, Kamal Mostafa,
Linux Kernel Mailing List, virtualization, Sasha Levin
In-Reply-To: <20160128001448-mutt-send-email-mst@redhat.com>
On Wed, Jan 27, 2016 at 2:15 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>>
>> Anyway, pulled. Just curious about how that thing happened.
>
> That's because apparently diffstat obeys orderfile rules:
Ugh. I guess that makes sense, but it's still very annoying for
something like a pull request, where now different people end up
having different diffstats. And the reason I never noticed it is that
likely there aren't that many people who use an orderfile.
I guess something like "-O /dev/null" in the pull-request would undo
it, but it is a bit annoying.
I've never actually met anybody (knowingly) that used that option. I
thought it was a Junio-only use case (it's been around forever as a
command line option, but the config file entry seems to be somewhat
recent and I wasn't even aware of it).
Adding Junio just as background to see what he thinks. Looks like the
diff.orderfile config option hits not just porcelain, but plumbing
too.
Linus
^ permalink raw reply
* Re: [PULL] virtio: fixes, tests
From: Michael S. Tsirkin @ 2016-01-27 22:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: jmarchan, KVM list, Network Development, Kamal Mostafa,
Linux Kernel Mailing List, virtualization, Sasha Levin
In-Reply-To: <CA+55aFzypP2SDdX7y8MpZGKhmLJot=UT4i328CYBcNQsP2VU+Q@mail.gmail.com>
On Wed, Jan 27, 2016 at 11:57:52AM -0800, Linus Torvalds wrote:
> On Wed, Jan 27, 2016 at 11:12 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > arch/sh/include/asm/barrier.h | 1 -
> > tools/virtio/asm/barrier.h | 22 +-
> > tools/virtio/linux/compiler.h | 9 +
> > tools/virtio/linux/kernel.h | 1 +
> > tools/virtio/ringtest/main.h | 119 ++++++++++
> > drivers/virtio/virtio_pci_common.c | 2 +
> > tools/virtio/ringtest/main.c | 366 +++++++++++++++++++++++++++++++
> > tools/virtio/ringtest/ring.c | 272 +++++++++++++++++++++++
> > tools/virtio/ringtest/virtio_ring_0_9.c | 316 ++++++++++++++++++++++++++
> > tools/virtio/ringtest/virtio_ring_poll.c | 2 +
> > tools/virtio/ringtest/Makefile | 22 ++
> > tools/virtio/ringtest/README | 2 +
> > tools/virtio/ringtest/run-on-all.sh | 24 ++
> > 13 files changed, 1148 insertions(+), 10 deletions(-)
>
> How the heck did you generate that diffstat? The names should be
> ordered, and are for me.
>
> Anyway, pulled. Just curious about how that thing happened.
>
> Linus
That's because apparently diffstat obeys orderfile rules:
[diff]
renames = true
orderfile = "/home/mst/.gitorderfile"
$ cat .gitorderfile
configure
Makefile*
*.json
*.h
*.c
^ permalink raw reply
* Re: [PULL] virtio: fixes, tests
From: Linus Torvalds @ 2016-01-27 19:57 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jmarchan, KVM list, Network Development, Kamal Mostafa,
Linux Kernel Mailing List, virtualization, Sasha Levin
In-Reply-To: <20160127211216-mutt-send-email-mst@redhat.com>
On Wed, Jan 27, 2016 at 11:12 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> arch/sh/include/asm/barrier.h | 1 -
> tools/virtio/asm/barrier.h | 22 +-
> tools/virtio/linux/compiler.h | 9 +
> tools/virtio/linux/kernel.h | 1 +
> tools/virtio/ringtest/main.h | 119 ++++++++++
> drivers/virtio/virtio_pci_common.c | 2 +
> tools/virtio/ringtest/main.c | 366 +++++++++++++++++++++++++++++++
> tools/virtio/ringtest/ring.c | 272 +++++++++++++++++++++++
> tools/virtio/ringtest/virtio_ring_0_9.c | 316 ++++++++++++++++++++++++++
> tools/virtio/ringtest/virtio_ring_poll.c | 2 +
> tools/virtio/ringtest/Makefile | 22 ++
> tools/virtio/ringtest/README | 2 +
> tools/virtio/ringtest/run-on-all.sh | 24 ++
> 13 files changed, 1148 insertions(+), 10 deletions(-)
How the heck did you generate that diffstat? The names should be
ordered, and are for me.
Anyway, pulled. Just curious about how that thing happened.
Linus
^ permalink raw reply
* [PULL] virtio: fixes, tests
From: Michael S. Tsirkin @ 2016-01-27 19:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: jmarchan, kvm, mst, netdev, kamal, linux-kernel, virtualization,
sasha.levin
The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to 481eaec37e91e2b33f17275901172f50ce2c71e8:
tools/virtio: add ringtest utilities (2016-01-26 10:18:30 +0200)
----------------------------------------------------------------
virtio: fixes, tests
This fixes existing tests broken by barrier rework,
and adds some new tests.
Plus, there's a fix for an old bug in virtio-pci.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Michael S. Tsirkin (4):
virtio_pci: fix use after free on release
tools/virtio: use virt_xxx barriers
sh: fix smp_store_mb for !SMP
tools/virtio: add ringtest utilities
arch/sh/include/asm/barrier.h | 1 -
tools/virtio/asm/barrier.h | 22 +-
tools/virtio/linux/compiler.h | 9 +
tools/virtio/linux/kernel.h | 1 +
tools/virtio/ringtest/main.h | 119 ++++++++++
drivers/virtio/virtio_pci_common.c | 2 +
tools/virtio/ringtest/main.c | 366 +++++++++++++++++++++++++++++++
tools/virtio/ringtest/ring.c | 272 +++++++++++++++++++++++
tools/virtio/ringtest/virtio_ring_0_9.c | 316 ++++++++++++++++++++++++++
tools/virtio/ringtest/virtio_ring_poll.c | 2 +
tools/virtio/ringtest/Makefile | 22 ++
tools/virtio/ringtest/README | 2 +
tools/virtio/ringtest/run-on-all.sh | 24 ++
13 files changed, 1148 insertions(+), 10 deletions(-)
create mode 100644 tools/virtio/linux/compiler.h
create mode 100644 tools/virtio/ringtest/main.h
create mode 100644 tools/virtio/ringtest/main.c
create mode 100644 tools/virtio/ringtest/ring.c
create mode 100644 tools/virtio/ringtest/virtio_ring_0_9.c
create mode 100644 tools/virtio/ringtest/virtio_ring_poll.c
create mode 100644 tools/virtio/ringtest/Makefile
create mode 100644 tools/virtio/ringtest/README
create mode 100755 tools/virtio/ringtest/run-on-all.sh
^ permalink raw reply
* Re: [PATCH v4 5/5] x86: drop mfence in favor of lock+addl
From: Michael S. Tsirkin @ 2016-01-27 17:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Davidlohr Bueso, Davidlohr Bueso, Peter Zijlstra,
Andrey Konovalov, the arch/x86 maintainers,
Linux Kernel Mailing List, virtualization, Andy Lutomirski,
Borislav Petkov, Borislav Petkov, Andy Lutomirski, H. Peter Anvin,
Thomas Gleixner, Paul E. McKenney, Ingo Molnar, Ingo Molnar
In-Reply-To: <CA+55aFzcDiKjz8yzRf9ET7Qc-qeNFP5bO0qW7o2cB9G9=yXHng@mail.gmail.com>
On Wed, Jan 27, 2016 at 09:37:45AM -0800, Linus Torvalds wrote:
> On Wed, Jan 27, 2016 at 7:10 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > -#define __smp_mb() mb()
> > +#define __smp_mb() asm volatile("lock; addl $0,-4(%%esp)" ::: "memory", "cc")
>
> So this doesn't look right for x86-64. Using %esp rather than %rsp.
> How did that even work for you?
>
> Linus
Oops, didn't test this version properly.
Pls disregard, I'll repost after some proper testing.
--
MST
^ permalink raw reply
* Re: [PATCH v4 5/5] x86: drop mfence in favor of lock+addl
From: Linus Torvalds @ 2016-01-27 17:37 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Davidlohr Bueso, Davidlohr Bueso, Peter Zijlstra,
Andrey Konovalov, the arch/x86 maintainers,
Linux Kernel Mailing List, virtualization, Andy Lutomirski,
Borislav Petkov, Borislav Petkov, Andy Lutomirski, H. Peter Anvin,
Thomas Gleixner, Paul E. McKenney, Ingo Molnar, Ingo Molnar
In-Reply-To: <1453904765-11073-6-git-send-email-mst@redhat.com>
On Wed, Jan 27, 2016 at 7:10 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> -#define __smp_mb() mb()
> +#define __smp_mb() asm volatile("lock; addl $0,-4(%%esp)" ::: "memory", "cc")
So this doesn't look right for x86-64. Using %esp rather than %rsp.
How did that even work for you?
Linus
^ permalink raw reply
* [PATCH v4 5/5] x86: drop mfence in favor of lock+addl
From: Michael S. Tsirkin @ 2016-01-27 15:10 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds
Cc: Davidlohr Bueso, Davidlohr Bueso, Peter Zijlstra,
Andrey Konovalov, the arch/x86 maintainers, virtualization,
Andy Lutomirski, Borislav Petkov, Borislav Petkov,
Andy Lutomirski, H. Peter Anvin, Thomas Gleixner,
Paul E. McKenney, Ingo Molnar, Ingo Molnar
In-Reply-To: <1453904765-11073-1-git-send-email-mst@redhat.com>
mfence appears to be way slower than a locked instruction - let's use
lock+add unconditionally, as we always did on old 32-bit.
Just poking at SP would be the most natural, but if we
then read the value from SP, we get a false dependency
which will slow us down.
This was noted in this article:
http://shipilev.net/blog/2014/on-the-fence-with-dependencies/
And is easy to reproduce by sticking a barrier in a small non-inline
function.
So let's use a negative offset - which avoids this problem since we
build with the red zone disabled.
Unfortunately there's some code that wants to order clflush instructions
using mb(), so we can't replace that - but smp_mb should be safe
to replace.
Update mb/rmb/wmb on 32 bit to use the negative offset, too, for
consistency.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/x86/include/asm/barrier.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index bfb28ca..7ab9581 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -11,11 +11,11 @@
*/
#ifdef CONFIG_X86_32
-#define mb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "mfence", \
+#define mb() asm volatile(ALTERNATIVE("lock; addl $0,-4(%%esp)", "mfence", \
X86_FEATURE_XMM2) ::: "memory", "cc")
-#define rmb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "lfence", \
+#define rmb() asm volatile(ALTERNATIVE("lock; addl $0,-4(%%esp)", "lfence", \
X86_FEATURE_XMM2) ::: "memory", "cc")
-#define wmb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "sfence", \
+#define wmb() asm volatile(ALTERNATIVE("lock; addl $0,-4(%%esp)", "sfence", \
X86_FEATURE_XMM2) ::: "memory", "cc")
#else
#define mb() asm volatile("mfence":::"memory")
@@ -30,7 +30,7 @@
#endif
#define dma_wmb() barrier()
-#define __smp_mb() mb()
+#define __smp_mb() asm volatile("lock; addl $0,-4(%%esp)" ::: "memory", "cc")
#define __smp_rmb() dma_rmb()
#define __smp_wmb() barrier()
#define __smp_store_mb(var, value) do { (void)xchg(&var, value); } while (0)
--
MST
^ permalink raw reply related
* [PATCH v4 4/5] x86: use mb() around clflush
From: Michael S. Tsirkin @ 2016-01-27 15:10 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds
Cc: Len Brown, Davidlohr Bueso, Davidlohr Bueso, Peter Zijlstra,
the arch/x86 maintainers, Oleg Nesterov, virtualization,
Mike Galbraith, Ingo Molnar, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, Thomas Gleixner, Paul E. McKenney, Ingo Molnar
In-Reply-To: <1453904765-11073-1-git-send-email-mst@redhat.com>
commit f8e617f4582995f7c25ef25b4167213120ad122b ("sched/idle/x86:
Optimize unnecessary mwait_idle() resched IPIs") adds
memory barriers around clflush, but this seems wrong
for UP since barrier() has no effect on clflush.
We really want mfence so switch to mb() instead.
Cc: Mike Galbraith <bitbucket@online.de>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/x86/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 9f7c21c..9decee2 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -418,9 +418,9 @@ static void mwait_idle(void)
if (!current_set_polling_and_test()) {
trace_cpu_idle_rcuidle(1, smp_processor_id());
if (this_cpu_has(X86_BUG_CLFLUSH_MONITOR)) {
- smp_mb(); /* quirk */
+ mb(); /* quirk */
clflush((void *)¤t_thread_info()->flags);
- smp_mb(); /* quirk */
+ mb(); /* quirk */
}
__monitor((void *)¤t_thread_info()->flags, 0, 0);
--
MST
^ permalink raw reply related
* [PATCH v4 3/5] x86: tweak the comment about use of wmb for IO
From: Michael S. Tsirkin @ 2016-01-27 15:10 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds
Cc: Davidlohr Bueso, Arnd Bergmann, Davidlohr Bueso, Peter Zijlstra,
Andrey Konovalov, the arch/x86 maintainers, virtualization,
Ingo Molnar, Borislav Petkov, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, Thomas Gleixner, Paul E. McKenney, Ingo Molnar
In-Reply-To: <1453904765-11073-1-git-send-email-mst@redhat.com>
On x86, we *do* still use the non-nop rmb/wmb for IO barriers, but even
that is generally questionable.
Leave them around as historial unless somebody can point to a case where
they care about the performance, but tweak the comment so people
don't think they are strictly required in all cases.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/x86/include/asm/barrier.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index a291745..bfb28ca 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -6,7 +6,7 @@
/*
* Force strict CPU ordering.
- * And yes, this is required on UP too when we're talking
+ * And yes, this might be required on UP too when we're talking
* to devices.
*/
--
MST
^ permalink raw reply related
* [PATCH v4 2/5] x86: drop a comment left over from X86_OOSTORE
From: Michael S. Tsirkin @ 2016-01-27 15:10 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds
Cc: Davidlohr Bueso, Arnd Bergmann, Davidlohr Bueso, Peter Zijlstra,
Andrey Konovalov, the arch/x86 maintainers, virtualization,
Ingo Molnar, Borislav Petkov, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, Thomas Gleixner, Paul E. McKenney, Ingo Molnar
In-Reply-To: <1453904765-11073-1-git-send-email-mst@redhat.com>
The comment about wmb being non-nop to deal with non-intel CPUs is a
left over from before commit 09df7c4c8097 ("x86: Remove
CONFIG_X86_OOSTORE").
It makes no sense now: in particular, wmb is not a nop even for regular
intel CPUs because of weird use-cases e.g. dealing with WC memory.
Drop this comment.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/x86/include/asm/barrier.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index a65bdb1..a291745 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -11,10 +11,6 @@
*/
#ifdef CONFIG_X86_32
-/*
- * Some non-Intel clones support out of order store. wmb() ceases to be a
- * nop for these.
- */
#define mb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "mfence", \
X86_FEATURE_XMM2) ::: "memory", "cc")
#define rmb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "lfence", \
--
MST
^ permalink raw reply related
* [PATCH v4 1/5] x86: add cc clobber for addl
From: Michael S. Tsirkin @ 2016-01-27 15:10 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds
Cc: Davidlohr Bueso, Arnd Bergmann, Davidlohr Bueso, Peter Zijlstra,
Andrey Konovalov, the arch/x86 maintainers, virtualization,
Ingo Molnar, Borislav Petkov, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, Thomas Gleixner, Paul E. McKenney, Ingo Molnar
In-Reply-To: <1453904765-11073-1-git-send-email-mst@redhat.com>
addl clobbers flags (such as CF) but barrier.h didn't tell this to gcc.
Historically, gcc doesn't need one on x86, and always considers flags
clobbered. We are probably missing the cc clobber in a *lot* of places
for this reason.
But even if not necessary, it's probably a good thing to add for
documentation, and in case gcc semantcs ever change.
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/x86/include/asm/barrier.h | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index a584e1c..a65bdb1 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -15,9 +15,12 @@
* Some non-Intel clones support out of order store. wmb() ceases to be a
* nop for these.
*/
-#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2)
-#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)
-#define wmb() alternative("lock; addl $0,0(%%esp)", "sfence", X86_FEATURE_XMM)
+#define mb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "mfence", \
+ X86_FEATURE_XMM2) ::: "memory", "cc")
+#define rmb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "lfence", \
+ X86_FEATURE_XMM2) ::: "memory", "cc")
+#define wmb() asm volatile(ALTERNATIVE("lock; addl $0,0(%%esp)", "sfence", \
+ X86_FEATURE_XMM2) ::: "memory", "cc")
#else
#define mb() asm volatile("mfence":::"memory")
#define rmb() asm volatile("lfence":::"memory")
--
MST
^ permalink raw reply related
* [PATCH v4 0/5] x86: faster smp_mb()+documentation tweaks
From: Michael S. Tsirkin @ 2016-01-27 15:10 UTC (permalink / raw)
To: linux-kernel, Linus Torvalds
Cc: Davidlohr Bueso, Davidlohr Bueso, Peter Zijlstra,
the arch/x86 maintainers, virtualization, Borislav Petkov,
H. Peter Anvin, Thomas Gleixner, Paul E. McKenney, Ingo Molnar
mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's
2 to 3 times slower than lock; addl that we use on older CPUs.
So we really should use the locked variant everywhere, except that intel manual
says that clflush is only ordered by mfence, so we can't.
Note: some callers of clflush seems to assume sfence will
order it, so there could be existing bugs around this code.
Fortunately no callers of clflush (except one) order it using smp_mb(), so
after fixing that one caller, it seems safe to override smp_mb straight away.
Down the road, it might make sense to introduce clflush_mb() and switch
to that for clflush callers.
While I was at it, I found some inconsistencies in comments in
arch/x86/include/asm/barrier.h
The documentation fixes are included first - I verified that
they do not change the generated code at all. Borislav Petkov
said they will appear in tip eventually, included here for
completeness.
The last patch changes __smp_mb() to lock addl. I was unable to
measure a speed difference on a macro benchmark,
but I noted that even doing
#define mb() barrier()
seems to make no difference for most benchmarks
(it causes hangs sometimes, of course).
HPA asked that the last patch is deferred until we hear back from
intel, which makes sense of course. So it needs HPA's ack.
Changes from v3:
Leave mb() alone for now since it's used to order
clflush, which requires mfence. Optimize smp_mb instead.
Changes from v2:
add patch adding cc clobber for addl
tweak commit log for patch 2
use addl at SP-4 (as opposed to SP) to reduce data dependencies
Michael S. Tsirkin (5):
x86: add cc clobber for addl
x86: drop a comment left over from X86_OOSTORE
x86: tweak the comment about use of wmb for IO
x86: use mb() around clflush
x86: drop mfence in favor of lock+addl
arch/x86/include/asm/barrier.h | 17 ++++++++---------
arch/x86/kernel/process.c | 4 ++--
2 files changed, 10 insertions(+), 11 deletions(-)
--
MST
^ permalink raw reply
* Re: [PATCH] documentation: Add disclaimer
From: David Howells @ 2016-01-27 14:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, Will Deacon,
virtualization, dhowells, H. Peter Anvin, sparclinux, Ingo Molnar,
linux-arch, linux-s390, Russell King - ARM Linux,
user-mode-linux-devel, linux-sh, Michael Ellerman, x86, xen-devel,
Ingo Molnar, Paul E. McKenney, linux-xtensa, james.hogan,
Arnd Bergmann, Stefano Stabellini, adi-buildroot-devel,
Leonid Yegoshin, ddaney.cavm
In-Reply-To: <20160127083546.GJ6357@twins.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> wrote:
> +==========
> +DISCLAIMER
> +==========
> +
> +This document is not a specification; it is intentionally (for the sake of
> +brevity) and unintentionally (due to being human) incomplete. This document is
> +meant as a guide to using the various memory barriers provided by Linux, but
> +in case of any doubt (and there are many) please ask.
> +
> +I repeat, this document is not a specification of what Linux expects from
> +hardware.
The purpose of this document is twofold:
(1) to specify the minimum functionality that one can rely on for any
particular barrier, and
(2) to provide a guide as to how to use the barriers that are available.
Note that an architecture can provide more than the minimum requirement for
any particular barrier, but if the barrier provides less than that, it is
incorrect.
Note also that it is possible that a barrier may be a no-op for an
architecture because the way that arch works renders an explicit barrier
unnecessary in that case.
> +
Can you bung an extra blank line in here if you have to redo this at all?
> +========
> +CONTENTS
> +========
>
> (*) Abstract memory access model.
>
David
^ permalink raw reply
* Re: [PATCH v2 0/3] x86: faster mb()+other barrier.h tweaks
From: Michael S. Tsirkin @ 2016-01-27 14:18 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Davidlohr Bueso, Davidlohr Bueso, the arch/x86 maintainers,
linux-kernel, virtualization, Borislav Petkov, H. Peter Anvin,
Thomas Gleixner, Paul E. McKenney, Linus Torvalds, Ingo Molnar
In-Reply-To: <20160127141409.GQ6357@twins.programming.kicks-ass.net>
On Wed, Jan 27, 2016 at 03:14:09PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 27, 2016 at 04:07:56PM +0200, Michael S. Tsirkin wrote:
> > mwait_idle is the only one that calls smp_mb and not mb()
> > I couldn't figure out why - original patches did mb()
> > there.
>
> That probably wants changing. That said, running UP kernels on affected
> hardware is 'unlikely' :-)
OK that's nice. After changing that one place, everyone calls
mb() around clflush so it should be safe to change smp_mb away
from mfence without breaking things.
I'm testing v4 that does this.
--
MST
^ permalink raw reply
* Re: [PATCH v2 0/3] x86: faster mb()+other barrier.h tweaks
From: Peter Zijlstra @ 2016-01-27 14:14 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Davidlohr Bueso, Davidlohr Bueso, the arch/x86 maintainers,
linux-kernel, virtualization, Borislav Petkov, H. Peter Anvin,
Thomas Gleixner, Paul E. McKenney, Linus Torvalds, Ingo Molnar
In-Reply-To: <20160127120222-mutt-send-email-mst@redhat.com>
On Wed, Jan 27, 2016 at 04:07:56PM +0200, Michael S. Tsirkin wrote:
> mwait_idle is the only one that calls smp_mb and not mb()
> I couldn't figure out why - original patches did mb()
> there.
That probably wants changing. That said, running UP kernels on affected
hardware is 'unlikely' :-)
^ permalink raw reply
* Re: [PATCH v2 0/3] x86: faster mb()+other barrier.h tweaks
From: Michael S. Tsirkin @ 2016-01-27 14:07 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Davidlohr Bueso, Davidlohr Bueso, Peter Zijlstra,
the arch/x86 maintainers, linux-kernel, virtualization,
Borislav Petkov, Thomas Gleixner, Paul E. McKenney,
Linus Torvalds, Ingo Molnar
In-Reply-To: <56A7E722.7030701@zytor.com>
On Tue, Jan 26, 2016 at 01:37:38PM -0800, H. Peter Anvin wrote:
> On 01/26/16 00:20, Michael S. Tsirkin wrote:
> > On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote:
> >
> > Hi hpa,
> > Any luck getting some feedback on this one?
> >
>
> Yes. What we know so far is that *most* cases it will work, but there
> are apparently a few corner cases where MFENCE or a full-blown
> serializing instruction is necessary. We are trying to characterize
> those corner cases and see if any of them affect the kernel.
It would be very interesting to know your findings.
Going over the manual I found one such case, and then going over the
kernel code I found some questionable uses of barriers - it would be
interesting to find out what some other cases are.
So I think it's probably useful to find out the full answer, anyway.
Awaiting the answers with interest.
> Even if they are, we can probably make those barriers explicitly
> different, but we don't want to go ahead with the change until we know
> where we need to care.
>
> -hpa
Thanks!
Now that you definitely said there are corner cases, I poked some more
at the manual and found one:
CLFLUSH is only ordered by the MFENCE instruction. It is not guaranteed
to be ordered by any other fencing or serializing instructions or by
another CLFLUSH instruction. For example, software can use an MFENCE
instruction to ensure that previous stores are included in the
write-back.
There are instances of this in mwait_play_dead,
clflush_cache_range, mwait_idle_with_hints, mwait_idle ..
A comment near pcommit_sfence includes an example
flush_and_commit_buffer code which is interesting -
it assumes sfence flushes clflush.
So it appears that pcommit_sfence in that file is wrong then?
At least on processors where it falls back on clflush.
mwait_idle is the only one that calls smp_mb and not mb()
I couldn't figure out why - original patches did mb()
there.
Outside core kernel - drm_cache_flush_clflush, drm_clflush_sg,
drm_clflush_virt_range.
Then there's gru_start_instruction in drivers/misc/sgi-gru/.
But otherwise drivers/misc/sgi-gru/ calls clflush in gru_flush_cache
without calling mb() - this could be a bug.
Looking at all users, it seems that only mwait_idle calls smp_mb,
around clflush, others call mb().
So at least as a first step, maybe it makes sense to scope this down
somewhat by changing mwait_idle to call mb() and then optimizing
__smp_mb instead of mb?
I'll post v3 that does this.
--
MST
^ permalink raw reply
* Re: [v3,11/41] mips: reuse asm-generic/barrier.h
From: Maciej W. Rozycki @ 2016-01-27 12:09 UTC (permalink / raw)
To: Ralf Baechle
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, Peter Zijlstra,
Will Deacon, virtualization, H. Peter Anvin, sparclinux,
Ingo Molnar, linux-arch, linux-s390, Russell King - ARM Linux,
user-mode-linux-devel, linux-sh, Michael Ellerman, x86, xen-devel,
Ingo Molnar, Paul E. McKenney, linux-xtensa, james.hogan,
Arnd Bergmann, Stefano Stabellini, adi-buildroot-devel,
Leonid Yegoshin
In-Reply-To: <20160127104032.GB2939@linux-mips.org>
On Wed, 27 Jan 2016, Ralf Baechle wrote:
> > So you need to build a different kernel for some types of MIPS systems?
>
> Yes. We can't really do without. Classic MIPS code is not relocatable
> without the complexity of PIC code as used by ELF DSOs - and their
> performanc penalty. Plus we have a number of architecture revisions
> ovr the decades, big and little endian, 32 and 64 bit as the major
> stumbling stones. There however are groups of similar systems that
> can share kernel binaries.
Matt (cc-ed) has recently posted patches to add support for a relocatable
kernel, implemented without the usual overhead of PIC code. It works by
retaining relocations in a fully-linked binary and then simply replaying
the work the static linker does when assigning addresses, as the image
loaded is copied to its intended destination at an early bootstrap stage.
See:
<http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=1449137297-30464-1-git-send-email-matt.redfearn%40imgtec.com>
for details.
I think this framework can be reused by carefully choosing instructions
used in early bootstrap code, up to the relocation stage, so that it is
runnable anywhere (not the same as PIC!) like early ld.so initialisation
and then loading the whole attached image starting from an address where
RAM does exist on target hardware.
Endianness is a different matter, obviously we can't build a single image
for both, although for distributions' sake an approach similar to one used
with bi-endian firmware (for hardware which has an easy way to switch the
endianness, e.g. a physical jumper or a configuration bit stored in flash
memory; not to be confused with the reverse user endianness mode) might be
feasible, by glueing two kernel images together and then selecting the
right one early in bootstrap, perhaps again reusing Matt's framework.
I'm not sure if this is worth the effort though, I suspect the usage level
of this feature would be minimal.
All in all I think making a generic MIPS kernel just might be feasible,
but with the diversity of options available the effort required would be
enormous. NetBSD for example I believe supports building a kernel that
correctly runs on both R3000 (MIPS I, 32-bit) and R4000 (MIPS III, 64-bit)
DEC hardware (as did DEC Ultrix, the vendor OS for these systems). These
processors are different enough from each other that you cannot use the
same code for cache, memory and exception management in an OS kernel --
backward compatibility is only provided for user software. That proves
the concept, however in a very limited way only, not even covering SMP,
and their R4000 kernel does not support 64-bit userland I believe. They
still have completely separate ports for other MIPS hardware, such as for
Broadcom SiByte SB-1 (MIPS64r1) processors.
Maciej
^ permalink raw reply
* Re: [v3,11/41] mips: reuse asm-generic/barrier.h
From: Maciej W. Rozycki @ 2016-01-27 11:26 UTC (permalink / raw)
To: Leonid Yegoshin
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, Peter Zijlstra,
Will Deacon, virtualization, H. Peter Anvin, sparclinux,
Ingo Molnar, linux-arch, linux-s390, Russell King - ARM Linux,
user-mode-linux-devel, linux-sh, Michael Ellerman, x86, xen-devel,
Ingo Molnar, paulmck, linux-xtensa, james.hogan, Arnd Bergmann,
Stefano Stabellini, adi-buildroot-devel, ddaney.cavm,
Thomas Gleixner, linux-me
In-Reply-To: <56984642.3090106@imgtec.com>
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
> > So you need to build a different kernel for some types of MIPS systems?
> > Or do you do boot-time rewriting, like a number of other arches do?
>
> I don't know. I would like to have responses. Ralf asked Maciej about old
> systems and that came nowhere. Even rewrite - don't know what to do with that:
> no lightweight SYNC or no SYNC at all - yes, it is still possible that SYNC on
> some systems can be too heavy or even harmful, nobody tested that.
I don't recall being asked; mind that I might not get to messages I have
not been cc-ed in a timely manner and I may miss some altogether. With
the amount of mailing list traffic that passes by me my scanner may fail
to trigger. Sorry if this causes anybody trouble, but such is life.
Coincidentally, I have just posted some notes on SYNC in a different
thread, see <http://lkml.iu.edu/hypermail/linux/kernel/1601.3/03080.html>.
There's a reference to an older message of mine there too. I hope this
answers your questions.
Maciej
^ permalink raw reply
* Re: [v3,11/41] mips: reuse asm-generic/barrier.h
From: Ralf Baechle @ 2016-01-27 10:40 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, Peter Zijlstra,
Will Deacon, virtualization, H. Peter Anvin, sparclinux,
Ingo Molnar, linux-arch, linux-s390, Russell King - ARM Linux,
user-mode-linux-devel, linux-sh, Michael Ellerman, x86, xen-devel,
Ingo Molnar, linux-xtensa, james.hogan, Arnd Bergmann,
Stefano Stabellini, adi-buildroot-devel, Leonid Yegoshin,
ddaney.cavm, Thomas Gleixner
In-Reply-To: <20160115004753.GN3818@linux.vnet.ibm.com>
On Thu, Jan 14, 2016 at 04:47:53PM -0800, Paul E. McKenney wrote:
> So you need to build a different kernel for some types of MIPS systems?
Yes. We can't really do without. Classic MIPS code is not relocatable
without the complexity of PIC code as used by ELF DSOs - and their
performanc penalty. Plus we have a number of architecture revisions
ovr the decades, big and little endian, 32 and 64 bit as the major
stumbling stones. There however are groups of similar systems that
can share kernel binaries.
> Or do you do boot-time rewriting, like a number of other arches do?
We don't rewrite the code (as in the .text of the vmlinux binary) but we
do runtime code generation for a few highly performance sensitive area
of the kernel code such as copy_page() or TLB exception handlers. This
allows more flexibility than just inserting templates into the kernel
code. Downside - it means we have some of the complexity of as and ld
in the kernel.
Ralf
^ permalink raw reply
* Re: [v3,11/41] mips: reuse asm-generic/barrier.h
From: Will Deacon @ 2016-01-27 10:25 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, Peter Zijlstra,
virtualization, H. Peter Anvin, sparclinux, Ingo Molnar,
linux-arch, linux-s390, Russell King - ARM Linux,
user-mode-linux-devel, linux-sh, Michael Ellerman, x86, xen-devel,
Ingo Molnar, linux-xtensa, james.hogan, Arnd Bergmann,
Stefano Stabellini, adi-buildroot-devel, Leonid Yegoshin,
ddaney.cavm, Thomas Gleixner, linux-metag
In-Reply-To: <20160126195820.GS4503@linux.vnet.ibm.com>
On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:16:09PM +0000, Will Deacon wrote:
> > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> > > On Mon, Jan 25, 2016 at 04:42:43PM +0000, Will Deacon wrote:
> > > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> > > > > PPC Overlapping Group-B sets version 4
> > > > > ""
> > > > > (* When the Group-B sets from two different barriers involve instructions in
> > > > > the same thread, within that thread one set must contain the other.
> > > > >
> > > > > P0 P1 P2
> > > > > Rx=1 Wy=1 Wz=2
> > > > > dep. lwsync lwsync
> > > > > Ry=0 Wz=1 Wx=1
> > > > > Rz=1
> > > > >
> > > > > assert(!(z=2))
> > > > >
> > > > > Forbidden by ppcmem, allowed by herd.
> > > > > *)
> > > > > {
> > > > > 0:r1=x; 0:r2=y; 0:r3=z;
> > > > > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
> > > > > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
> > > > > }
> > > > > P0 | P1 | P2 ;
> > > > > lwz r6,0(r1) | stw r4,0(r2) | stw r5,0(r3) ;
> > > > > xor r7,r6,r6 | lwsync | lwsync ;
> > > > > lwzx r7,r7,r2 | stw r4,0(r3) | stw r4,0(r1) ;
> > > > > lwz r8,0(r3) | | ;
> > > > >
> > > > > exists
> > > > > (z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)
> > > >
> > > > That really hurts. Assuming that the "assert(!(z=2))" is actually there
> > > > to constrain the coherence order of z to be {0->1->2}, then I think that
> > > > this test is forbidden on arm using dmb instead of lwsync. That said, I
> > > > also don't think the Rz=1 in P0 changes anything.
> > >
> > > What about the smp_wmb() variant of dmb that orders only stores?
> >
> > Tricky, but I think it still works out if the coherence order of z is as
> > I described above. The line of reasoning is weird though -- I ended up
> > considering the two cases where P0 reads z before and after it reads x
> > and what that means for the read of y.
>
> By "works out" you mean that ARM prohibits the outcome?
Yes, that's my understanding.
Will
^ permalink raw reply
* Re: [PATCH 0/2] vhost: cross-endian code cleanup
From: Greg Kurz @ 2016-01-27 10:25 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20160113170934.23705.62626.stgit@bahia.huguette.org>
On Wed, 13 Jan 2016 18:09:34 +0100
Greg Kurz <gkurz@linux.vnet.ibm.com> wrote:
> This series is a respin of the following patch:
>
> http://patchwork.ozlabs.org/patch/565921/
>
> Patch 1 is preliminary work: it gives better names to the helpers that are
> involved in cross-endian support.
>
> Patch 2 is actually a v2 of the original patch. All devices now call a
> helper in the generic code, which DTRT according to vq->private_data, as
> suggested by Michael.
>
Hi Michael,
This is just a friendly reminder for this series, which was
reviewed by Cornelia already.
Thanks.
--
Greg
> ---
>
> Greg Kurz (2):
> vhost: helpers to enable/disable vring endianness
> vhost: disentangle vring endianness stuff from the core code
>
>
> drivers/vhost/net.c | 3 +++
> drivers/vhost/scsi.c | 3 +++
> drivers/vhost/test.c | 2 ++
> drivers/vhost/vhost.c | 40 ++++++++++++++++++++++++++++------------
> drivers/vhost/vhost.h | 1 +
> 5 files changed, 37 insertions(+), 12 deletions(-)
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
>
^ permalink raw reply
* Re: [v3,11/41] mips: reuse asm-generic/barrier.h
From: Will Deacon @ 2016-01-27 10:23 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, Peter Zijlstra,
virtualization, H. Peter Anvin, sparclinux, Ingo Molnar,
linux-arch, linux-s390, Russell King - ARM Linux,
user-mode-linux-devel, linux-sh, Michael Ellerman, x86, xen-devel,
Ingo Molnar, linux-xtensa, james.hogan, Arnd Bergmann,
Stefano Stabellini, adi-buildroot-devel, Leonid Yegoshin,
ddaney.cavm, Thomas Gleixner, linux-metag
In-Reply-To: <20160126233733.GZ4503@linux.vnet.ibm.com>
On Tue, Jan 26, 2016 at 03:37:33PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:10:10PM +0000, Will Deacon wrote:
> > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote:
> > > PPC WRCnf+addrs
> > > ""
> > > {
> > > 0:r2=x; 0:r3=y;
> > > 1:r2=x; 1:r3=y;
> > > 2:r2=x; 2:r3=y;
> > > c=a; d=b; x=c; y=d;
> > > }
> > > P0 | P1 | P2 ;
> > > stw r3,0(r2) | lwz r8,0(r2) | lwz r8,0(r3) ;
> > > | stw r2,0(r8) | lwz r9,0(r8) ;
> > > exists
> > > (1:r8=y /\ 2:r8=x /\ 2:r9=c)
> >
> > Agreed.
>
> OK, thank you! Would you agree that it would be good to replace the
> current xor-based fake-dependency litmus tests with tests having real
> dependencies?
Yes, because it would look a lot more like real (kernel) code.
Will
^ permalink raw reply
* Re: [PATCH] documentation: Add disclaimer
From: Will Deacon @ 2016-01-27 10:11 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-ia64, Michael S. Tsirkin, virtualization,
H. Peter Anvin, sparclinux, Ingo Molnar, linux-arch, linux-s390,
Russell King - ARM Linux, user-mode-linux-devel, linux-sh,
Michael Ellerman, x86, xen-devel, Ingo Molnar, Paul E. McKenney,
linux-xtensa, james.hogan, Arnd Bergmann, Stefano Stabellini,
adi-buildroot-devel, Leonid Yegoshin, ddaney.cavm,
Thomas Gleixner, linux-metag
In-Reply-To: <20160127083546.GJ6357@twins.programming.kicks-ass.net>
On Wed, Jan 27, 2016 at 09:35:46AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote:
> > So Peter, would you like to update your patch to include yourself
> > and Will as authors?
>
> Sure, here goes.
>
> ---
> Subject: documentation: Add disclaimer
>
> It appears people are reading this document as a requirements list for
> building hardware. This is not the intent of this document. Nor is it
> particularly suited for this purpose.
>
> The primary purpose of this document is our collective attempt to define
> a set of primitives that (hopefully) allow us to write correct code on
> the myriad of SMP platforms Linux supports.
>
> Its a definite work in progress as our understanding of these platforms,
> and memory ordering in general, progresses.
>
> Nor does being mentioned in this document mean we think its a
> particularly good idea; the data dependency barrier required by Alpha
> being a prime example. Yes we have it, no you're insane to require it
> when building new hardware.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> Documentation/memory-barriers.txt | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox