similar to: [PATCH v2 0/3] vhost: cross-endian code cleanup

This series is a respin of the following patch: http://patchwork.ozlabs.org/patch/565921/ Patch 1 is preliminary work: it gives better names to the helpers that are involved in cross-endian support. Patch 2 is actually a v2 of the original patch. All devices now call a helper in the generic code, which DTRT according to vq->private_data, as suggested by Michael. --- Greg Kurz (2):

This series is a respin of the following patch: http://patchwork.ozlabs.org/patch/565921/ Patch 1 is preliminary work: it gives better names to the helpers that are involved in cross-endian support. Patch 2 is actually a v2 of the original patch. All devices now call a helper in the generic code, which DTRT according to vq->private_data, as suggested by Michael. --- Greg Kurz (2):

On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > The default use case for vhost is when the host and the vring have the > same endianness (default native endianness). But there are cases where > they differ and vhost should byteswap when accessing the vring: > - the host is big endian and the vring comes from a virtio 1.0 device > which is always little endian > -

On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > The default use case for vhost is when the host and the vring have the > same endianness (default native endianness). But there are cases where > they differ and vhost should byteswap when accessing the vring: > - the host is big endian and the vring comes from a virtio 1.0 device > which is always little endian > -

On Wed, Feb 10, 2016 at 01:11:34PM +0100, Greg Kurz wrote: > On Wed, 10 Feb 2016 13:21:22 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > > > The default use case for vhost is when the host and the vring have the > > > same endianness (default native endianness). But there

On Wed, Feb 10, 2016 at 01:11:34PM +0100, Greg Kurz wrote: > On Wed, 10 Feb 2016 13:21:22 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Wed, Jan 13, 2016 at 06:09:41PM +0100, Greg Kurz wrote: > > > The default use case for vhost is when the host and the vring have the > > > same endianness (default native endianness). But there

On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > The way vring endianness is being handled currently obfuscates > the code in vhost_init_used(). > > This patch tries to fix that by doing the following: > - move the the code that adjusts endianness to a dedicated helper > - export this helper so that backends explicitely call it > > No behaviour change. >

On Wed, Jan 13, 2016 at 06:09:47PM +0100, Greg Kurz wrote: > The way vring endianness is being handled currently obfuscates > the code in vhost_init_used(). > > This patch tries to fix that by doing the following: > - move the the code that adjusts endianness to a dedicated helper > - export this helper so that backends explicitely call it > > No behaviour change. >

On Fri, 10 Apr 2015 12:19:16 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > This patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the

On Fri, 10 Apr 2015 12:19:16 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > This patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the

On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: >> >> Hi! >> >> Recently I have been investigating some strange migration problems on >> s390x. >> >> It turned out under certain circumstances vhost_net corrupts avail.idx by >> using wrong endianness. [..] >>

On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: >> >> Hi! >> >> Recently I have been investigating some strange migration problems on >> s390x. >> >> It turned out under certain circumstances vhost_net corrupts avail.idx by >> using wrong endianness. [..] >>

On Fri, Apr 10, 2015 at 12:19:16PM +0200, Greg Kurz wrote: > This patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the endianness to be > used for ring

On Fri, Apr 10, 2015 at 12:19:16PM +0200, Greg Kurz wrote: > This patch brings cross-endian support to vhost when used to implement > legacy virtio devices. Since it is a relatively rare situation, the > feature availability is controlled by a kernel config option (not set > by default). > > The vq->is_le boolean field is added to cache the endianness to be > used for ring

On Fri, Jan 27, 2017 at 02:37:47PM +0100, Greg Kurz wrote: > On Fri, 27 Jan 2017 13:24:13 +0100 > Halil Pasic <pasic at linux.vnet.ibm.com> wrote: > > > On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > > > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: > > >> > > >> Hi! > > >> > > >> Recently I have

On Fri, Jan 27, 2017 at 02:37:47PM +0100, Greg Kurz wrote: > On Fri, 27 Jan 2017 13:24:13 +0100 > Halil Pasic <pasic at linux.vnet.ibm.com> wrote: > > > On 01/26/2017 08:20 PM, Michael S. Tsirkin wrote: > > > On Thu, Jan 26, 2017 at 06:39:14PM +0100, Halil Pasic wrote: > > >> > > >> Hi! > > >> > > >> Recently I have

The vq->is_le field is used to fix endianness when accessing the vring via the cpu_to_vhost16() and vhost16_to_cpu() helpers in the following cases: 1) host is big endian and device is modern virtio 2) host has cross-endian support and device is legacy virtio with a different endianness than the host Both cases rely on the VHOST_SET_FEATURES ioctl, but 2) also needs the

The vq->is_le field is used to fix endianness when accessing the vring via the cpu_to_vhost16() and vhost16_to_cpu() helpers in the following cases: 1) host is big endian and device is modern virtio 2) host has cross-endian support and device is legacy virtio with a different endianness than the host Both cases rely on the VHOST_SET_FEATURES ioctl, but 2) also needs the

Currently, under certain circumstances vhost_init_is_le does just a part of the initialization job, and depends on vhost_reset_is_le being called too. For this reason vhost_vq_init_access used to call vhost_reset_is_le when vq->private_data is NULL. This is not only counter intuitive, but also real a problem because it breaks vhost_net. The bug was introduced to vhost_net with commit

Currently, under certain circumstances vhost_init_is_le does just a part of the initialization job, and depends on vhost_reset_is_le being called too. For this reason vhost_vq_init_access used to call vhost_reset_is_le when vq->private_data is NULL. This is not only counter intuitive, but also real a problem because it breaks vhost_net. The bug was introduced to vhost_net with commit