search for: vringh_need_notify_us

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk of this tree-wide conversion, some

For several reasons, it would be beneficial to kill off ACCESS_ONCE() tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate types, more obviously document their intended behaviour, and are necessary for tools like KTSAN to work correctly (as otherwise reads and writes cannot be instrumented separately). While it's possible to script the bulk of this tree-wide conversion, some

This introduces vringh, which are generic accessors for virtio rings (host side). There's a host-side implementation in vhost, but it assumes that the rings are in userspace, and is tied to the vhost implementation. I have patches to adapt it to use vringh, but I'm pushing this in the next merge window for Sjur, who has CAIF patches which need it. This also includes a test program in

This introduces vringh, which are generic accessors for virtio rings (host side). There's a host-side implementation in vhost, but it assumes that the rings are in userspace, and is tied to the vhost implementation. I have patches to adapt it to use vringh, but I'm pushing this in the next merge window for Sjur, who has CAIF patches which need it. This also includes a test program in

...3,6 +3,7 @@ > * > * Since these may be in userspace, we use (inline) accessors. > */ > +#include <linux/compiler.h> > #include <linux/module.h> > #include <linux/vringh.h> > #include <linux/virtio_ring.h> > @@ -820,13 +821,13 @@ EXPORT_SYMBOL(vringh_need_notify_user); > static inline int getu16_kern(const struct vringh *vrh, > u16 *val, const __virtio16 *p) > { > - *val = vringh16_to_cpu(vrh, ACCESS_ONCE(*p)); > + *val = vringh16_to_cpu(vrh, READ_ONCE(*p)); > return 0; > } > > static inline int putu16_kern(const st...

...,7 @@ > * > * Since these may be in userspace, we use (inline) accessors. > */ > +#include <linux/compiler.h> > #include <linux/module.h> > #include <linux/vringh.h> > #include <linux/virtio_ring.h> > @@ -820,13 +821,13 @@ EXPORT_SYMBOL(vringh_need_notify_user); > static inline int getu16_kern(const struct vringh *vrh, > u16 *val, const __virtio16 *p) > { > - *val = vringh16_to_cpu(vrh, ACCESS_ONCE(*p)); > + *val = vringh16_to_cpu(vrh, READ_ONCE(*p)); > return 0; > } > > static inline int putu16_kern(...

...ingh.c +++ b/drivers/vhost/vringh.c @@ -3,6 +3,7 @@ * * Since these may be in userspace, we use (inline) accessors. */ +#include <linux/compiler.h> #include <linux/module.h> #include <linux/vringh.h> #include <linux/virtio_ring.h> @@ -820,13 +821,13 @@ EXPORT_SYMBOL(vringh_need_notify_user); static inline int getu16_kern(const struct vringh *vrh, u16 *val, const __virtio16 *p) { - *val = vringh16_to_cpu(vrh, ACCESS_ONCE(*p)); + *val = vringh16_to_cpu(vrh, READ_ONCE(*p)); return 0; } static inline int putu16_kern(const struct vringh *vrh, __virtio16 *p, u16 val) {...

This fixes remaining sparse warnings in vringh and mic by using virtio 1.0 compliant wrappers. This also needs by get_user patches to avoid getting warnings from these calls. Tested by running vringh_test. Rusty, I prefer fixing all these warnings for 3.19, any objections? Michael S. Tsirkin (3): vringh: 64 bit features vringh: initial virtio 1.0 support mic/host: initial virtio 1.0

This fixes remaining sparse warnings in vringh and mic by using virtio 1.0 compliant wrappers. This also needs by get_user patches to avoid getting warnings from these calls. Tested by running vringh_test. Rusty, I prefer fixing all these warnings for 3.19, any objections? Michael S. Tsirkin (3): vringh: 64 bit features vringh: initial virtio 1.0 support mic/host: initial virtio 1.0

Getting use of virtio rings correct is tricky, and a recent patch saw an implementation of in-kernel rings (as separate from userspace). This patch attempts to abstract the business of dealing with the virtio ring layout from the access (userspace or direct); to do this, we use function pointers, which gcc inlines correctly. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---

Getting use of virtio rings correct is tricky, and a recent patch saw an implementation of in-kernel rings (as separate from userspace). This patch attempts to abstract the business of dealing with the virtio ring layout from the access (userspace or direct); to do this, we use function pointers, which gcc inlines correctly. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---