Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
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 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
On Mon, Dec 21, 2015 at 10:47:49AM +, David Vrabel wrote: > 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 Guest kernel - yes. But it's only needed because you are running on an SMP host. -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] [Xen-devel] new barrier type for paravirt (was Re: [PATCH] virtio_ring: use smp_store_mb)
On Mon, 21 Dec 2015, David Vrabel wrote: > 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. inner-shareable barriers are certainly OK. In this case there would be also a switch from dsb to dmb barriers, which I also think should be OK. What about all the mb() and wmb() in RING_PUSH_REQUESTS and RING_PUSH_RESPONSES in include/xen/interface/io/ring.h ? > > 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. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
