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é <f4bug@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...

 Thomas