similar to: [BUG/RFC] vhost: net: big endian viring access despite virtio 1

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, 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

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. > > I managed to track the problem down (I'm pretty sure). It boils down to > the following. > >

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 been investigating some strange migration problems on > >> s390x. > >> > >> It

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

On 01/30/2017 08:06 PM, Greg Kurz wrote: >> 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

On 01/30/2017 08:06 PM, Greg Kurz wrote: >> 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

This series is a new tentative to have cleaner cross-endian code. Patches 1/3 is new: it fixes a side-effect in case vhost_init_used() fails. Patch 2/3 comes from v1: it renames cross-endian helpers Patch 3/3 is new: it simply renames vhost_init_used() as suggested by Michael. --- Greg Kurz (3): vhost: fix error path in vhost_init_used() vhost: rename cross-endian helpers

This series is a new tentative to have cleaner cross-endian code. Patches 1/3 is new: it fixes a side-effect in case vhost_init_used() fails. Patch 2/3 comes from v1: it renames cross-endian helpers Patch 3/3 is new: it simply renames vhost_init_used() as suggested by Michael. --- Greg Kurz (3): vhost: fix error path in vhost_init_used() vhost: rename cross-endian helpers

On Mon, 30 Jan 2017 11:09:36 +0100 Halil Pasic <pasic at linux.vnet.ibm.com> wrote: > 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,

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

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

On Tue, Jan 31, 2017 at 04:56:13PM +0100, Halil Pasic wrote: > > > On 01/30/2017 08:06 PM, Greg Kurz wrote: > >> 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

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 > -