From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751406AbbLUKr4 (ORCPT ); Mon, 21 Dec 2015 05:47:56 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:16063 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751079AbbLUKrz (ORCPT ); Mon, 21 Dec 2015 05:47:55 -0500 X-IronPort-AV: E=Sophos;i="5.20,459,1444694400"; d="scan'208";a="326655467" Message-ID: <5677D8D5.7080700@citrix.com> Date: Mon, 21 Dec 2015 10:47:49 +0000 From: David Vrabel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: "Michael S. Tsirkin" , Peter Zijlstra CC: Jason Wang , Rusty Russell , , Alexander Duyck , , David Vrabel , , Boris Ostrovsky , , Ian Campbell Subject: Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb) References: <1450347932-16325-1-git-send-email-mst@redhat.com> <20151217105238.GA6375@twins.programming.kicks-ass.net> <20151217131554-mutt-send-email-mst@redhat.com> <20151217135726.GA6344@twins.programming.kicks-ass.net> <20151217161124-mutt-send-email-mst@redhat.com> <20151217143910.GD6344@twins.programming.kicks-ass.net> <20151220105146-mutt-send-email-mst@redhat.com> In-Reply-To: <20151220105146-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/12/15 09:25, Michael S. Tsirkin wrote: > > 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? For x86, yes. For arm/arm64 I think so, but would prefer one of the Xen arm maintainers to confirm. In particular, whether inner-shareable barriers are sufficient for memory shared with the hypervisor. > 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() The smp_ prefix doesn't make a lot of sense to me here since these barriers are going to be the same whether the kernel is SMP or not. David From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAy0X-0006W2-5z for qemu-devel@nongnu.org; Mon, 21 Dec 2015 05:48:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAy0T-00029G-4O for qemu-devel@nongnu.org; Mon, 21 Dec 2015 05:48:01 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:25717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAy0S-000296-Vz for qemu-devel@nongnu.org; Mon, 21 Dec 2015 05:47:57 -0500 Message-ID: <5677D8D5.7080700@citrix.com> Date: Mon, 21 Dec 2015 10:47:49 +0000 From: David Vrabel MIME-Version: 1.0 References: <1450347932-16325-1-git-send-email-mst@redhat.com> <20151217105238.GA6375@twins.programming.kicks-ass.net> <20151217131554-mutt-send-email-mst@redhat.com> <20151217135726.GA6344@twins.programming.kicks-ass.net> <20151217161124-mutt-send-email-mst@redhat.com> <20151217143910.GD6344@twins.programming.kicks-ass.net> <20151220105146-mutt-send-email-mst@redhat.com> In-Reply-To: <20151220105146-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Peter Zijlstra Cc: Ian Campbell , Jason Wang , Rusty Russell , qemu-devel@nongnu.org, Alexander Duyck , linux-kernel@vger.kernel.org, David Vrabel , xen-devel@lists.xenproject.org, Boris Ostrovsky , virtualization@lists.linux-foundation.org On 20/12/15 09:25, Michael S. Tsirkin wrote: > > 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? For x86, yes. For arm/arm64 I think so, but would prefer one of the Xen arm maintainers to confirm. In particular, whether inner-shareable barriers are sufficient for memory shared with the hypervisor. > 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() The smp_ prefix doesn't make a lot of sense to me here since these barriers are going to be the same whether the kernel is SMP or not. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb) Date: Mon, 21 Dec 2015 10:47:49 +0000 Message-ID: <5677D8D5.7080700@citrix.com> References: <1450347932-16325-1-git-send-email-mst@redhat.com> <20151217105238.GA6375@twins.programming.kicks-ass.net> <20151217131554-mutt-send-email-mst@redhat.com> <20151217135726.GA6344@twins.programming.kicks-ass.net> <20151217161124-mutt-send-email-mst@redhat.com> <20151217143910.GD6344@twins.programming.kicks-ass.net> <20151220105146-mutt-send-email-mst@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20151220105146-mutt-send-email-mst@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: "Michael S. Tsirkin" , Peter Zijlstra Cc: Ian Campbell , qemu-devel@nongnu.org, Alexander Duyck , linux-kernel@vger.kernel.org, David Vrabel , xen-devel@lists.xenproject.org, Boris Ostrovsky , virtualization@lists.linux-foundation.org List-Id: virtualization@lists.linuxfoundation.org On 20/12/15 09:25, Michael S. Tsirkin wrote: > > 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? For x86, yes. For arm/arm64 I think so, but would prefer one of the Xen arm maintainers to confirm. In particular, whether inner-shareable barriers are sufficient for memory shared with the hypervisor. > 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() The smp_ prefix doesn't make a lot of sense to me here since these barriers are going to be the same whether the kernel is SMP or not. David