search for: kurze

Only cosmetic and documentation changes since v5. --- Greg Kurz (8): virtio: introduce virtio_is_little_endian() helper tun: add tun_is_little_endian() helper macvtap: introduce macvtap_is_little_endian() helper vringh: introduce vringh_is_little_endian() helper vhost: introduce vhost_is_little_endian() helper virtio: add explicit big-endian support to memory

Only cosmetic and documentation changes since v5. --- Greg Kurz (8): virtio: introduce virtio_is_little_endian() helper tun: add tun_is_little_endian() helper macvtap: introduce macvtap_is_little_endian() helper vringh: introduce vringh_is_little_endian() helper vhost: introduce vhost_is_little_endian() helper virtio: add explicit big-endian support to memory

On Fri, 24 Apr 2015 15:31:54 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Fri, Apr 24, 2015 at 02:24:15PM +0200, Greg Kurz wrote: > > Only cosmetic and documentation changes since v5. > > > > --- > > Looks sane to me. I plan to review and apply next week. > Hi Michael, I realize you just got back and have tons of things to do... Do

On Fri, 24 Apr 2015 15:31:54 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Fri, Apr 24, 2015 at 02:24:15PM +0200, Greg Kurz wrote: > > Only cosmetic and documentation changes since v5. > > > > --- > > Looks sane to me. I plan to review and apply next week. > Hi Michael, I realize you just got back and have tons of things to do... Do

On Tue, Apr 21, 2015 at 06:22:20PM +0200, Greg Kurz wrote: > On Tue, 21 Apr 2015 16:06:33 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Fri, Apr 10, 2015 at 12:20:21PM +0200, Greg Kurz wrote: > > > The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers > > > that are always little-endian. It can also be used to

On Tue, Apr 21, 2015 at 06:22:20PM +0200, Greg Kurz wrote: > On Tue, 21 Apr 2015 16:06:33 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Fri, Apr 10, 2015 at 12:20:21PM +0200, Greg Kurz wrote: > > > The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers > > > that are always little-endian. It can also be used to

I have an application that talks to hardware via the serial port. (Actually, it talks to a lot of hardware, banking peripherals). The app runs on both Win32 and OS/2. Of course, the main theme is porting the thing natively to linux (and I'm working on that). But just for fun I tried to get it to work with WINE, and while the "device emulation" works perfectly (much to my

On Wed, 06 May 2015 14:07:37 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > Unlike with add and clear, there is no valid reason to abort when checking > for a feature. It makes more sense to return false (i.e. the feature bit > isn't set). This is exactly what __virtio_has_feature() does if fbit >= 32. > > This allows to introduce code that is aware about new

On Wed, 06 May 2015 14:07:37 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > Unlike with add and clear, there is no valid reason to abort when checking > for a feature. It makes more sense to return false (i.e. the feature bit > isn't set). This is exactly what __virtio_has_feature() does if fbit >= 32. > > This allows to introduce code that is aware about new

Hi, This patchset allows vhost_net to be used with legacy virtio when guest and host have a different endianness. It is based on previous work by C?dric Le Goater: https://www.mail-archive.com/kvm-ppc at vger.kernel.org/msg09848.html As suggested by MST: - the API now asks for a specific format (big endian) instead of the hint whether byteswap is needed or not (patch 1) - rebased on top of

Hi, This patchset allows vhost_net to be used with legacy virtio when guest and host have a different endianness. It is based on previous work by C?dric Le Goater: https://www.mail-archive.com/kvm-ppc at vger.kernel.org/msg09848.html As suggested by MST: - the API now asks for a specific format (big endian) instead of the hint whether byteswap is needed or not (patch 1) - rebased on top of

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

commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian support for legacy devices") introduced a minor regression: even with cross-endian disabled, and even on LE host, vhost_is_little_endian is checking is_le flag so there's always a branch. To fix, simply check virtio_legacy_is_little_endian first. Cc: Greg Kurz <gkurz at linux.vnet.ibm.com> Signed-off-by:

commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian support for legacy devices") introduced a minor regression: even with cross-endian disabled, and even on LE host, vhost_is_little_endian is checking is_le flag so there's always a branch. To fix, simply check virtio_legacy_is_little_endian first. Cc: Greg Kurz <gkurz at linux.vnet.ibm.com> Signed-off-by:

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

Hi, This series allows QEMU to use vhost with legacy virtio devices when host and target don't have the same endianness. Only network devices are covered for the moment. I had already posted a series some monthes ago but it never got reviewed. Moreover, the underlying kernel support was entirely re-written and is still waiting to be applied by Michael. I hence post as RFC. The corresponding

Hi, This series allows QEMU to use vhost with legacy virtio devices when host and target don't have the same endianness. Only network devices are covered for the moment. I had already posted a series some monthes ago but it never got reviewed. Moreover, the underlying kernel support was entirely re-written and is still waiting to be applied by Michael. I hence post as RFC. The corresponding

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