From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drJ9p-0007fL-DN for qemu-devel@nongnu.org; Mon, 11 Sep 2017 03:29:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drJ9m-0004ds-Am for qemu-devel@nongnu.org; Mon, 11 Sep 2017 03:29:25 -0400 Date: Mon, 11 Sep 2017 09:29:11 +0200 From: Cornelia Huck Message-ID: <20170911092911.27e0886e.cohuck@redhat.com> In-Reply-To: <9058bb80-4e5c-3316-576f-1c21924a8a07@redhat.com> References: <1504100343-26607-1-git-send-email-thuth@redhat.com> <20170910032413.GB2735@umbus.fritz.box> <9058bb80-4e5c-3316-576f-1c21924a8a07@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for-2.11] hw/misc/ivshmem: Fix ivshmem_recv_msg() to also work on big endian systems List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: David Gibson , Peter Maydell , Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= , QEMU Developers , QEMU Trivial , Laurent Vivier , =?UTF-8?B?TWFyYy1BbmRyw6k=?= Lureau On Mon, 11 Sep 2017 04:35:08 +0200 Thomas Huth wrote: > On 10.09.2017 05:24, David Gibson wrote: > > On Wed, Aug 30, 2017 at 03:59:07PM +0100, Peter Maydell wrote: =20 > >> On 30 August 2017 at 15:53, Philippe Mathieu-Daud=C3=A9 wrote: =20 > >>> On 08/30/2017 10:39 AM, Thomas Huth wrote: =20 > >>>> The problem is that the server side code in ivshmem_server_send_one_= msg() > >>>> correctly translates all messages IDs into little endian 64-bit valu= es, > >>>> 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= (). =20 > >>> > >>> > >>> Yes, we lack BE testing :( =20 > >> > >> 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'. =20 > >=20 > > 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. =20 >=20 > 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' :)