From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E32BC433ED for ; Tue, 18 May 2021 06:55:44 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3C017611BD for ; Tue, 18 May 2021 06:55:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C017611BD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ilande.co.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:57516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1litdn-0007VR-BP for qemu-devel@archiver.kernel.org; Tue, 18 May 2021 02:55:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1litbh-0005gT-NY; Tue, 18 May 2021 02:53:33 -0400 Received: from mail.ilande.co.uk ([2001:41c9:1:41f::167]:48366 helo=mail.default.ilande.uk0.bigv.io) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1litbf-0004gf-R4; Tue, 18 May 2021 02:53:33 -0400 Received: from host217-39-58-213.range217-39.btcentralplus.com ([217.39.58.213] helo=[192.168.1.65]) by mail.default.ilande.uk0.bigv.io with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1litbg-0004lB-Gx; Tue, 18 May 2021 07:53:32 +0100 To: David Gibson , "Paul A. Clarke" References: <20210517214032.156187-1-pc@us.ibm.com> From: Mark Cave-Ayland Message-ID: <25618d64-b40c-ff7e-8f69-1cddcd3863f1@ilande.co.uk> Date: Tue, 18 May 2021 07:53:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 217.39.58.213 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: [PATCH] Fix `lxvdsx` (issue #212) X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on mail.default.ilande.uk0.bigv.io) Received-SPF: pass client-ip=2001:41c9:1:41f::167; envelope-from=mark.cave-ayland@ilande.co.uk; helo=mail.default.ilande.uk0.bigv.io X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Giuseppe Musacchio , qemu-ppc@nongnu.org, Richard Henderson , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 18/05/2021 02:34, David Gibson wrote: > I'm having a hard time convincing myself this is correct in all cases. > Have you tested it with all combinations of BE/LE host and BE/LE guest > code? > > The description in the ISA is pretty inscrutable, since it's in terms > of the confusing numbering if different element types in BE vs LE > mode. > > It looks to me like before bcb0b7b1a1c0 this originally resolved to > MO_Q modified by ctx->default_tcg_memop_mask, which appears to depend > on the current guest endian mode. That's pretty hard to trace through > the various layers of macros, but for reference, before bcb0b7b1a1c0 > this used gen_qemu_ld64_i64(), which appears to be constructed by the > line GEN_QEMU_LOAD_64(ld64, DEF_MEMOP(MO_Q)) in translate.c. > > Richard or Giuseppe, care to weigh in? > >> --- >> target/ppc/translate/vsx-impl.c.inc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/target/ppc/translate/vsx-impl.c.inc b/target/ppc/translate/vsx-impl.c.inc >> index b817d31260bb..46f97c029ca8 100644 >> --- a/target/ppc/translate/vsx-impl.c.inc >> +++ b/target/ppc/translate/vsx-impl.c.inc >> @@ -162,7 +162,7 @@ static void gen_lxvdsx(DisasContext *ctx) >> gen_addr_reg_index(ctx, EA); >> >> data = tcg_temp_new_i64(); >> - tcg_gen_qemu_ld_i64(data, EA, ctx->mem_idx, MO_TEQ); >> + tcg_gen_qemu_ld_i64(data, EA, ctx->mem_idx, MO_LEQ); >> tcg_gen_gvec_dup_i64(MO_Q, vsr_full_offset(xT(ctx->opcode)), 16, 16, data); >> >> tcg_temp_free(EA); Right. I think what is happening here is currently the load uses MO_TE (i.e. target endian) which defaults to big endian for PPC and that's why you're seeing the byte swap. The reason this is required for the vector instructions is because the vector registers need to be stored in host byte-order to allow them to make use of the host's vector instructions. A quick look around the same file at gen_lxvw4x() suggests that you need a solution like this to work correctly with both big and little endian: if (ctx->le_mode) { tcg_gen_qemu_ld_i64(data, EA, ctx->mem_idx, MO_LEQ); } else { tcg_gen_qemu_ld_i64(data, EA, ctx->mem_idx, MO_BEQ); } The original commit message for bcb0b7b1a1c0 mentions that the implementation is based upon that of the lxvwsx instruction, so I'm fairly sure that gen_lxvwsx() is also broken for little endian and will need a similar fix too. ATB, Mark.