From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLiZz-0006W5-Gy for qemu-devel@nongnu.org; Tue, 19 Jan 2016 21:33:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLiZy-00032I-FX for qemu-devel@nongnu.org; Tue, 19 Jan 2016 21:33:03 -0500 Date: Wed, 20 Jan 2016 13:13:57 +1100 From: David Gibson Message-ID: <20160120021357.GH27454@voom.redhat.com> References: <20160115150005.17358.43294.stgit@bahia.huguette.org> <20160115150038.17358.21849.stgit@bahia.huguette.org> <20160118022519.GH9301@voom.fritz.box> <20160119105920.2e4068a7@bahia.huguette.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nOM8ykUjac0mNN89" Content-Disposition: inline In-Reply-To: <20160119105920.2e4068a7@bahia.huguette.org> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 5/7] target-ppc: gdbstub: fix altivec registers for little-endian guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Paolo Bonzini , qemu-ppc@nongnu.org, qemu-devel@nongnu.org --nOM8ykUjac0mNN89 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2016 at 10:59:20AM +0100, Greg Kurz wrote: > On Mon, 18 Jan 2016 13:25:19 +1100 > David Gibson wrote: >=20 > > On Fri, Jan 15, 2016 at 04:00:38PM +0100, Greg Kurz wrote: > > > Altivec registers are 128-bit wide. They are stored in memory as two > > > 64-bit values that must be byteswapped when the guest is little-endia= n. > > > Let's reuse the ppc_maybe_bswap_register() helper for this. > > >=20 > > > We also need to fix the ordering of the 64-bit elements according to > > > the target endianness, for both system and user mode. > > >=20 > > > Signed-off-by: Greg Kurz =20 > >=20 > > What bothers me about this is that avr_need_swap() now depends on both > > host and guest endianness. However the VSCR and VRSAVE swap - like > > the swaps for GPRs and FPRs - uses ppc_maybe_bswap_register() which > > depends only on guest endianness. > >=20 > > Why does altivec depend on the host endianness? > >=20 >=20 > This has always been the case: >=20 > commit b4f8d821e5211bbb51a278ba0fc4a4db2d581221 > Author: aurel32 > Date: Sat Jan 24 15:08:09 2009 +0000 >=20 > target-ppc: Add Altivec register read/write using XML >=20 > [...] >=20 > +static int gdb_get_avr_reg(CPUState *env, uint8_t *mem_buf, int n) > +{ > + if (n < 32) { > +#ifdef WORDS_BIGENDIAN > + stq_p(mem_buf, env->avr[n].u64[0]); > + stq_p(mem_buf+8, env->avr[n].u64[1]); > +#else > + stq_p(mem_buf, env->avr[n].u64[1]); > + stq_p(mem_buf+8, env->avr[n].u64[0]); > +#endif > + return 16; > + } >=20 > My understanding is that gdb expects registers to be presented with > the target endianness but QEMU have them in host endianness. >=20 > The ppc_maybe_bswap_register() helper is needed to fix 64-bit values > according to the target effective endianness because stq_p() always > consider both ppc64 and ppc64le to be big endian. >=20 > Here, we have a 128-bit register that we break into two 64-bit values > in memory. Each quad word has to be fixed by ppc_maybe_bswap_register(). > But we also have to reorder these quad words if the host endianness > differs from the target's one. This is the purpose of avr_need_swap(). Ok, understood. I've merged the series to ppc-for-2.6 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --nOM8ykUjac0mNN89 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWnu1lAAoJEGw4ysog2bOSr78QAIG4J4RE07RLRCK83UiQCUP3 STGM06ownB8uWVk6g8hrMq32Nf0bre3QWy7SRvKbuQrHtXvi8q9+vgVTfP/XpSle Msn/2v3qtIm760FNKLE3s9wDHg1SnNNNGEEW8jJHJrSmcTix9vAHKT0mvAgrEuhF PsFHIehWnN2hVTE3Elt2Yn8GgKtZuppii1N/AdWx7wUAqDu3JR4ox8o+x1X/TuXt ynmjYpKlZMurt3ioqHo0luwzf4OZFG0sdW+lrff9WaWSDr+glHZjbLZHIV56CnUS AGPGesg80s6dfDa9E7HleJyAH9U6Qg/gL8a7aninc/T+bnJ5QXJ+lXjzdxBPGYv4 gkVeaPwMBxh6m1kFAYILzGE5Pq57WRzIV98qHKemi2sltJgWVbpcLejEdJq6KFHW qp85JPsahyUURFI+b+LWKvgqSd6uT1pgOybj2uXWccdxvY6xTMkaMbsnvPA0LJXu I3xmDAQc7foFiO9SE1cPI8yoEaPeJRp48Vfp3VtH5ew5gzguOlpA0EWOR3un0upb b41aaPiEt0E1zEB/La/cLjfAtw/6kv0Erk/3aHh+mPjadAcLGoU1WW8JK8CXL9th 2KdCs8G3pYAG6WBrBbtruE9s0+gcZKS/s20aNhtmR8XqNg1WBcoFxB1agDtw5KnU HIoQm6aNPkw9w1ERV4D9 =10xR -----END PGP SIGNATURE----- --nOM8ykUjac0mNN89--