On Mon, 11 Sep 2017 04:35:08 +0200 Thomas Huth <th...@redhat.com> wrote:
> On 10.09.2017 05:24, David Gibson wrote: > > On Wed, Aug 30, 2017 at 03:59:07PM +0100, Peter Maydell wrote: > >> On 30 August 2017 at 15:53, Philippe Mathieu-Daudé <f4...@amsat.org> > >> wrote: > >>> On 08/30/2017 10:39 AM, Thomas Huth wrote: > >>>> The problem is that the server side code in ivshmem_server_send_one_msg() > >>>> correctly translates all messages IDs into little endian 64-bit values, > >>>> but the client side code in the ivshmem_recv_msg() function does not swap > >>>> the byte order back. Fix it by passing the value through le64_to_cpu(). > >>> > >>> > >>> Yes, we lack BE testing :( > >> > >> My pre-pull-request test set includes s390 and ppc64 bigendian. > >> This one was just missed because the 'slow' tests aren't in > >> 'make check'. > > > > I'm not what makes sense for staging this fix. I could take it > > through my tree, but it's not an obvious match, since this isn't > > really related to ppc at all. > > There does not seem to be maintainer for ivshmem, as far as I can see, > so I'd say any tree that is distantly related is fine. So I think you > could either take it through your ppc tree (since the bug affects big > endian ppc machines), or maybe Cornelia could take it through the s390x > tree (since we've seen the problem on the big endian s390x machines, > too). Otherwise I have to wait and see whether it goes through misc or > trivial, I guess... I'll queue it; and whoever sends the first pull request, 'wins' :)
