All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jason Wang <jasowang@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	qemu-devel@nongnu.org,
	Alexander Duyck <alexander.duyck@gmail.com>,
	linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
Date: Sun, 20 Dec 2015 11:25:58 +0200	[thread overview]
Message-ID: <20151220105146-mutt-send-email-mst__3424.33957052908$1450603637$gmane$org@redhat.com> (raw)
In-Reply-To: <20151217143910.GD6344@twins.programming.kicks-ass.net>

On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
> > > 
> > > You could of course go fix that instead of mutilating things into
> > > sort-of functional state.
> > 
> > Yes, we'd just need to touch all architectures, all for
> > the sake of UP which almost no one uses.
> > Basically, we need APIs that explicitly are
> > for talking to another kernel on a different CPU on
> > the same SMP system, and implemented identically
> > between CONFIG_SMP and !CONFIG_SMP on all architectures.
> > 
> > Do you think this is something of general usefulness,
> > outside virtio?
> 
> I'm not aware of any other case, but if there are more parts of virt
> that need this then I see no problem adding it.

When I wrote this, I assumed there are no other users, and I'm still not
sure there are other users at the moment. Do you see a problem then?

> That is, virt in general is the only use-case that I can think of,
> because this really is an artifact of interfacing with an SMP host while
> running an UP kernel.

Or another guest kernel on an SMP host.

> But I'm really not familiar with virt, so I do not know if there's more
> sites outside of virtio that could use this.
> Touching all archs is a tad tedious, but its fairly straight forward.

So I looked and I was only able to find other another possible user in Xen.

Cc Xen folks.

I noticed that drivers/xen/xenbus/xenbus_comms.c uses
full memory barriers to communicate with the other side.
For example:

                /* Must write data /after/ reading the consumer index.  * */
                mb();

                memcpy(dst, data, avail);
                data += avail;
                len -= avail;
        
                /* Other side must not see new producer until data is * there. */
                wmb();
                intf->req_prod += avail;
                
                /* Implies mb(): other side will see the updated producer. */
                notify_remote_via_evtchn(xen_store_evtchn);

To me, it looks like 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.

Is my analysis correct?

So what I'm suggesting is something like the below patch,
except instead of using virtio directly, a new set of barriers
that behaves identically for SMP and non-SMP guests will be introduced.

And of course the weak barriers flag is not needed for Xen -
that's a virtio only thing.

For example:

smp_pv_wmb()
smp_pv_rmb()
smp_pv_mb()

I'd like to get confirmation from Xen folks before posting
this patchset.

Comments/suggestions?

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

--

compile-tested only.

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index fdb0f33..a28f049 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -36,6 +36,7 @@
 #include <linux/interrupt.h>
 #include <linux/sched.h>
 #include <linux/err.h>
+#include <linux/virtio_ring.h>
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <xen/events.h>
@@ -123,14 +124,14 @@ int xb_write(const void *data, unsigned len)
 			avail = len;
 
 		/* Must write data /after/ reading the consumer index. */
-		mb();
+		virtio_mb(true);
 
 		memcpy(dst, data, avail);
 		data += avail;
 		len -= avail;
 
 		/* Other side must not see new producer until data is there. */
-		wmb();
+		virtio_wmb(true);
 		intf->req_prod += avail;
 
 		/* Implies mb(): other side will see the updated producer. */
@@ -180,14 +181,14 @@ int xb_read(void *data, unsigned len)
 			avail = len;
 
 		/* Must read data /after/ reading the producer index. */
-		rmb();
+		virtio_rmb(true);
 
 		memcpy(data, src, avail);
 		data += avail;
 		len -= avail;
 
 		/* Other side must not see free space until we've copied out */
-		mb();
+		virtio_mb(true);
 		intf->rsp_cons += avail;
 
 		pr_debug("Finished read of %i bytes (%i to go)\n", avail, len);

-- 
MST

  parent reply	other threads:[~2015-12-20  9:26 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-17 10:32 [PATCH] virtio_ring: use smp_store_mb Michael S. Tsirkin
2015-12-17 10:32 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-17 10:52 ` Peter Zijlstra
2015-12-17 10:52   ` Peter Zijlstra
2015-12-17 10:52   ` [Qemu-devel] " Peter Zijlstra
2015-12-17 13:16   ` Michael S. Tsirkin
2015-12-17 13:16     ` Michael S. Tsirkin
2015-12-17 13:16     ` [Qemu-devel] " Michael S. Tsirkin
2015-12-17 13:57     ` Peter Zijlstra
2015-12-17 13:57       ` Peter Zijlstra
2015-12-17 13:57       ` [Qemu-devel] " Peter Zijlstra
2015-12-17 14:33       ` Michael S. Tsirkin
2015-12-17 14:33         ` Michael S. Tsirkin
2015-12-17 14:33         ` [Qemu-devel] " Michael S. Tsirkin
2015-12-17 14:39         ` Peter Zijlstra
2015-12-17 14:39           ` Peter Zijlstra
2015-12-17 14:39           ` [Qemu-devel] " Peter Zijlstra
2015-12-17 14:43           ` Michael S. Tsirkin
2015-12-17 14:43           ` Michael S. Tsirkin
2015-12-17 14:43             ` [Qemu-devel] " Michael S. Tsirkin
2015-12-20  9:25           ` new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb) Michael S. Tsirkin
2015-12-20  9:25             ` Michael S. Tsirkin
2015-12-20  9:25             ` [Qemu-devel] " Michael S. Tsirkin
2015-12-20 17:07             ` Andrew Cooper
2015-12-20 17:07             ` [Xen-devel] " Andrew Cooper
2015-12-20 17:07               ` Andrew Cooper
2015-12-20 17:07               ` [Qemu-devel] " Andrew Cooper
2015-12-20 19:59               ` Peter Zijlstra
2015-12-20 19:59                 ` Peter Zijlstra
2015-12-20 19:59                 ` [Qemu-devel] " Peter Zijlstra
2015-12-21  7:10                 ` Michael S. Tsirkin
2015-12-21  7:10                 ` [Xen-devel] " Michael S. Tsirkin
2015-12-21  7:10                 ` Michael S. Tsirkin
2015-12-21  7:10                   ` [Qemu-devel] " Michael S. Tsirkin
2015-12-21  7:22                   ` [PATCH RFC] smp_store_mb should use smp_mb Michael S. Tsirkin
2015-12-21  7:22                   ` Michael S. Tsirkin
2015-12-21  7:22                   ` Michael S. Tsirkin
2015-12-21  7:22                     ` [Qemu-devel] " Michael S. Tsirkin
2015-12-20 19:59               ` new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb) Peter Zijlstra
2015-12-21 10:47             ` David Vrabel
2015-12-21 10:47             ` [Xen-devel] " David Vrabel
2015-12-21 10:47               ` David Vrabel
2015-12-21 10:47               ` [Qemu-devel] " David Vrabel
2015-12-21 11:52               ` Michael S. Tsirkin
2015-12-21 11:52               ` [Xen-devel] " Michael S. Tsirkin
2015-12-21 11:52                 ` Michael S. Tsirkin
2015-12-21 11:52                 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-21 14:50               ` Stefano Stabellini
2015-12-21 14:50                 ` Stefano Stabellini
2015-12-21 14:50                 ` Stefano Stabellini
2015-12-21 14:50                 ` Stefano Stabellini
2015-12-21 14:50               ` [Qemu-devel] " Stefano Stabellini
2015-12-20  9:25           ` Michael S. Tsirkin [this message]
2015-12-17 11:22 ` [PATCH] virtio_ring: use smp_store_mb Peter Zijlstra
2015-12-17 11:22   ` [Qemu-devel] " Peter Zijlstra
2015-12-17 13:26   ` Michael S. Tsirkin
2015-12-17 13:26     ` Michael S. Tsirkin
2015-12-17 13:26     ` [Qemu-devel] " Michael S. Tsirkin
2015-12-17 14:02     ` Peter Zijlstra
2015-12-17 14:02     ` Peter Zijlstra
2015-12-17 14:02       ` [Qemu-devel] " Peter Zijlstra
2015-12-17 14:34       ` Michael S. Tsirkin
2015-12-17 14:34       ` Michael S. Tsirkin
2015-12-17 14:34         ` [Qemu-devel] " Michael S. Tsirkin
2015-12-17 15:09         ` Peter Zijlstra
2015-12-17 15:09         ` Peter Zijlstra
2015-12-17 15:09           ` [Qemu-devel] " Peter Zijlstra
2015-12-17 15:52           ` Will Deacon
2015-12-17 15:52           ` Will Deacon
2015-12-17 15:52             ` [Qemu-devel] " Will Deacon
2015-12-17 19:21             ` Michael S. Tsirkin
2015-12-17 19:21               ` Michael S. Tsirkin
2015-12-17 19:21               ` [Qemu-devel] " Michael S. Tsirkin
2015-12-17 11:22 ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='20151220105146-mutt-send-email-mst__3424.33957052908$1450603637$gmane$org@redhat.com' \
    --to=mst@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.