From nobody Tue Dec 16 09:00:16 2025 Delivered-To: importer@patchew.org Received-SPF: temperror (zoho.com: Error in retrieving data from DNS) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=temperror (zoho.com: Error in retrieving data from DNS) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1512589129246944.175380348509; Wed, 6 Dec 2017 11:38:49 -0800 (PST) Received: from localhost ([::1]:57284 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMfWW-00051b-82 for importer@patchew.org; Wed, 06 Dec 2017 14:38:28 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMfCV-0000kt-9h for qemu-devel@nongnu.org; Wed, 06 Dec 2017 14:17:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMfCT-0000nZ-En for qemu-devel@nongnu.org; Wed, 06 Dec 2017 14:17:47 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41516) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eMfCT-0000lz-4k for qemu-devel@nongnu.org; Wed, 06 Dec 2017 14:17:45 -0500 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB6JFuEB114723 for ; Wed, 6 Dec 2017 14:17:44 -0500 Received: from e12.ny.us.ibm.com (e12.ny.us.ibm.com [129.33.205.202]) by mx0a-001b2d01.pphosted.com with ESMTP id 2epm1wf76g-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 06 Dec 2017 14:17:43 -0500 Received: from localhost by e12.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Dec 2017 14:17:40 -0500 Received: from b01cxnp23034.gho.pok.ibm.com (9.57.198.29) by e12.ny.us.ibm.com (146.89.104.199) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 6 Dec 2017 14:17:37 -0500 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vB6JHaWX46727366; Wed, 6 Dec 2017 19:17:37 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 40BECB2054; Wed, 6 Dec 2017 14:14:44 -0500 (EST) Received: from localhost (unknown [9.80.93.86]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id E99C5B2052; Wed, 6 Dec 2017 14:14:43 -0500 (EST) From: Michael Roth To: qemu-devel@nongnu.org Date: Wed, 6 Dec 2017 13:16:28 -0600 X-Mailer: git-send-email 2.11.0 In-Reply-To: <20171206191648.18208-1-mdroth@linux.vnet.ibm.com> References: <20171206191648.18208-1-mdroth@linux.vnet.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 17120619-0048-0000-0000-00000210AF91 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008161; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000244; SDB=6.00956379; UDB=6.00483442; IPR=6.00736416; BA=6.00005729; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018387; XFM=3.00000015; UTC=2017-12-06 19:17:39 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120619-0049-0000-0000-000043620870 Message-Id: <20171206191648.18208-36-mdroth@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712060273 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 148.163.156.1 Subject: [Qemu-devel] [PATCH 35/55] translate.c: Fix usermode big-endian AArch32 LDREXD and STREXD X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , qemu-stable@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_6 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Peter Maydell For AArch32 LDREXD and STREXD, architecturally the 32-bit word at the lowest address is always Rt and the one at addr+4 is Rt2, even if the CPU is big-endian. Our implementation does these with a single 64-bit store, so if we're big-endian then we need to put the two 32-bit halves together in the opposite order to little-endian, so that they end up in the right places. We were trying to do this with the gen_aa32_frob64() function, but that is not correct for the usermode emulator, because there there is a distinction between "load a 64 bit value" (which does a BE 64-bit access and doesn't need swapping) and "load two 32 bit values as one 64 bit access" (where we still need to do the swapping, like system mode BE32). Fixes: https://bugs.launchpad.net/qemu/+bug/1725267 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Message-id: 1509622400-13351-1-git-send-email-peter.maydell@linaro.org (cherry picked from commit 3448d47b3172015006b79197eb5a69826c6a7b6d) Signed-off-by: Michael Roth --- target/arm/translate.c | 39 ++++++++++++++++++++++++++++++++++----- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/target/arm/translate.c b/target/arm/translate.c index d1a5f56998..ad758d333d 100644 --- a/target/arm/translate.c +++ b/target/arm/translate.c @@ -7858,9 +7858,27 @@ static void gen_load_exclusive(DisasContext *s, int = rt, int rt2, TCGv_i32 tmp2 =3D tcg_temp_new_i32(); TCGv_i64 t64 =3D tcg_temp_new_i64(); =20 - gen_aa32_ld_i64(s, t64, addr, get_mem_index(s), opc); + /* For AArch32, architecturally the 32-bit word at the lowest + * address is always Rt and the one at addr+4 is Rt2, even if + * the CPU is big-endian. That means we don't want to do a + * gen_aa32_ld_i64(), which invokes gen_aa32_frob64() as if + * for an architecturally 64-bit access, but instead do a + * 64-bit access using MO_BE if appropriate and then split + * the two halves. + * This only makes a difference for BE32 user-mode, where + * frob64() must not flip the two halves of the 64-bit data + * but this code must treat BE32 user-mode like BE32 system. + */ + TCGv taddr =3D gen_aa32_addr(s, addr, opc); + + tcg_gen_qemu_ld_i64(t64, taddr, get_mem_index(s), opc); + tcg_temp_free(taddr); tcg_gen_mov_i64(cpu_exclusive_val, t64); - tcg_gen_extr_i64_i32(tmp, tmp2, t64); + if (s->be_data =3D=3D MO_BE) { + tcg_gen_extr_i64_i32(tmp2, tmp, t64); + } else { + tcg_gen_extr_i64_i32(tmp, tmp2, t64); + } tcg_temp_free_i64(t64); =20 store_reg(s, rt2, tmp2); @@ -7909,15 +7927,26 @@ static void gen_store_exclusive(DisasContext *s, in= t rd, int rt, int rt2, TCGv_i64 n64 =3D tcg_temp_new_i64(); =20 t2 =3D load_reg(s, rt2); - tcg_gen_concat_i32_i64(n64, t1, t2); + /* For AArch32, architecturally the 32-bit word at the lowest + * address is always Rt and the one at addr+4 is Rt2, even if + * the CPU is big-endian. Since we're going to treat this as a + * single 64-bit BE store, we need to put the two halves in the + * opposite order for BE to LE, so that they end up in the right + * places. + * We don't want gen_aa32_frob64() because that does the wrong + * thing for BE32 usermode. + */ + if (s->be_data =3D=3D MO_BE) { + tcg_gen_concat_i32_i64(n64, t2, t1); + } else { + tcg_gen_concat_i32_i64(n64, t1, t2); + } tcg_temp_free_i32(t2); - gen_aa32_frob64(s, n64); =20 tcg_gen_atomic_cmpxchg_i64(o64, taddr, cpu_exclusive_val, n64, get_mem_index(s), opc); tcg_temp_free_i64(n64); =20 - gen_aa32_frob64(s, o64); tcg_gen_setcond_i64(TCG_COND_NE, o64, o64, cpu_exclusive_val); tcg_gen_extrl_i64_i32(t0, o64); =20 --=20 2.11.0