From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLT4V-00062a-Hw for qemu-devel@nongnu.org; Tue, 19 Jan 2016 04:59:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLT4S-0005UP-Bl for qemu-devel@nongnu.org; Tue, 19 Jan 2016 04:59:31 -0500 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:35082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLT4S-0005TD-3e for qemu-devel@nongnu.org; Tue, 19 Jan 2016 04:59:28 -0500 Received: from localhost by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 19 Jan 2016 09:59:25 -0000 Date: Tue, 19 Jan 2016 10:59:20 +0100 From: Greg Kurz Message-ID: <20160119105920.2e4068a7@bahia.huguette.org> In-Reply-To: <20160118022519.GH9301@voom.fritz.box> References: <20160115150005.17358.43294.stgit@bahia.huguette.org> <20160115150038.17358.21849.stgit@bahia.huguette.org> <20160118022519.GH9301@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [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: David Gibson Cc: qemu-devel@nongnu.org, Paolo Bonzini , qemu-ppc@nongnu.org, Alexander Graf , Anton Blanchard On Mon, 18 Jan 2016 13:25:19 +1100 David Gibson wrote: > 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-endian. > > Let's reuse the ppc_maybe_bswap_register() helper for this. > > > > We also need to fix the ordering of the 64-bit elements according to > > the target endianness, for both system and user mode. > > > > Signed-off-by: Greg Kurz > > 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. > > Why does altivec depend on the host endianness? > This has always been the case: commit b4f8d821e5211bbb51a278ba0fc4a4db2d581221 Author: aurel32 Date: Sat Jan 24 15:08:09 2009 +0000 target-ppc: Add Altivec register read/write using XML [...] +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; + } My understanding is that gdb expects registers to be presented with the target endianness but QEMU have them in host endianness. 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. 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(). Cheers. -- Greg > > --- > > target-ppc/translate_init.c | 12 ++++++++++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c > > index 18e9e561561f..80d53e4dcf5a 100644 > > --- a/target-ppc/translate_init.c > > +++ b/target-ppc/translate_init.c > > @@ -8754,9 +8754,9 @@ static void dump_ppc_insns (CPUPPCState *env) > > static bool avr_need_swap(CPUPPCState *env) > > { > > #ifdef HOST_WORDS_BIGENDIAN > > - return false; > > + return msr_le; > > #else > > - return true; > > + return !msr_le; > > #endif > > } > > > > @@ -8800,14 +8800,18 @@ static int gdb_get_avr_reg(CPUPPCState *env, uint8_t *mem_buf, int n) > > stq_p(mem_buf, env->avr[n].u64[1]); > > stq_p(mem_buf+8, env->avr[n].u64[0]); > > } > > + ppc_maybe_bswap_register(env, mem_buf, 8); > > + ppc_maybe_bswap_register(env, mem_buf + 8, 8); > > return 16; > > } > > if (n == 32) { > > stl_p(mem_buf, env->vscr); > > + ppc_maybe_bswap_register(env, mem_buf, 4); > > return 4; > > } > > if (n == 33) { > > stl_p(mem_buf, (uint32_t)env->spr[SPR_VRSAVE]); > > + ppc_maybe_bswap_register(env, mem_buf, 4); > > return 4; > > } > > return 0; > > @@ -8816,6 +8820,8 @@ static int gdb_get_avr_reg(CPUPPCState *env, uint8_t *mem_buf, int n) > > static int gdb_set_avr_reg(CPUPPCState *env, uint8_t *mem_buf, int n) > > { > > if (n < 32) { > > + ppc_maybe_bswap_register(env, mem_buf, 8); > > + ppc_maybe_bswap_register(env, mem_buf + 8, 8); > > if (!avr_need_swap(env)) { > > env->avr[n].u64[0] = ldq_p(mem_buf); > > env->avr[n].u64[1] = ldq_p(mem_buf+8); > > @@ -8826,10 +8832,12 @@ static int gdb_set_avr_reg(CPUPPCState *env, uint8_t *mem_buf, int n) > > return 16; > > } > > if (n == 32) { > > + ppc_maybe_bswap_register(env, mem_buf, 4); > > env->vscr = ldl_p(mem_buf); > > return 4; > > } > > if (n == 33) { > > + ppc_maybe_bswap_register(env, mem_buf, 4); > > env->spr[SPR_VRSAVE] = (target_ulong)ldl_p(mem_buf); > > return 4; > > } > > >