similar to: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

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

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 24, 2016 at 10:25:11AM +0000, Mark Rutland wrote: > > 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 > >

On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 24, 2016 at 10:25:11AM +0000, Mark Rutland wrote: > > 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 > >

vDPA supports the possibility to use user VA in the iotlb messages. So, let's add support for user VA in vringh to use it in the vDPA simulators. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- Notes: v3: - refactored avoiding code duplication [Eugenio] v2: - replace kmap_atomic() with kmap_local_page() [see previous patch] - fix cast warnings when

kmap_atomic() is deprecated in favor of kmap_local_page() since commit f3ba3c710ac5 ("mm/highmem: Provide kmap_local*"). With kmap_local_page() the mappings are per thread, CPU local, can take page-faults, and can be called from any context (including interrupts). Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored

v2: - rebased on Linus' tree, commit ae3419fbac84 ("vc_screen: don't clobber return value in vcs_read") - removed `struct task_struct *owner` param (unused for now, maybe ?useful to support cgroups) [Jason] - add unbind_mm callback [Jason] - call the new unbind_mm callback during the release [Jason] - avoid to call bind_mm callback after the reset, since the device ?is not

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: >> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > >>> What are use cases for such primitive that won't be OK with "read once >>> _and_ atomically"? >> >> I have none to hand. > > Whatever triggers the

On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: >> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > >>> What are use cases for such primitive that won't be OK with "read once >>> _and_ atomically"? >> >> I have none to hand. > > Whatever triggers the

On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > > READ/WRITE_ONCE imply atomicity. Even if their names don't spell it (a > function name doesn't have to spell all of its guarantees). Most of > the uses of READ/WRITE_ONCE will be broken if they are not atomic. In practice, this is certainly the assumption made by many/most users of the *_ONCE() accessors.

Hi, This patchset allows vhost to be used with legacy virtio when guest and host have a different endianness. It is compatible with modern virtio and can be fully compiled out through kernel config. FWIW, I could flawlessly kexec/reboot guests from ppc64 to ppc64le and back. I could also migrate from a ppc64 to a ppc64le host and back. No regressions on x86 as expected. My experimental QEMU tree

Hi, This patchset allows vhost to be used with legacy virtio when guest and host have a different endianness. It is compatible with modern virtio and can be fully compiled out through kernel config. FWIW, I could flawlessly kexec/reboot guests from ppc64 to ppc64le and back. I could also migrate from a ppc64 to a ppc64le host and back. No regressions on x86 as expected. My experimental QEMU tree

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

Hi, This patchset allows vhost to be used with legacy virtio when guest and host have a different endianness. It is a complete rework of my initial post. Patches 1 to 5 are preliminary work: we move the endianness check out of all memory accessors to separate functions. Patch 6 changes the semantics of the accessors so that they have explicit big endian support. Patch 7 brings the cross-endian

Hi, This patchset allows vhost to be used with legacy virtio when guest and host have a different endianness. It is a complete rework of my initial post. Patches 1 to 5 are preliminary work: we move the endianness check out of all memory accessors to separate functions. Patch 6 changes the semantics of the accessors so that they have explicit big endian support. Patch 7 brings the cross-endian

On 11/24/2016 11:25 AM, Mark Rutland wrote: > Despite living under drivers/ vringh.c is also used as part of the userspace > virtio tools. Before we can kill off the ACCESS_ONCE()definition in the tools, > we must convert vringh.c to use {READ,WRITE}_ONCE(). > > This patch does so, along with the required include of <linux/compiler.h> for > the relevant definitions. The

On 2016?11?24? 18:25, Mark Rutland wrote: > Despite living under drivers/ vringh.c is also used as part of the userspace > virtio tools. Before we can kill off the ACCESS_ONCE()definition in the tools, > we must convert vringh.c to use {READ,WRITE}_ONCE(). > > This patch does so, along with the required include of <linux/compiler.h> for > the relevant definitions. The