From nobody Fri Aug 21 21:29:26 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=linux.alibaba.com ARC-Seal: i=1; a=rsa-sha256; t=1787294519; cv=none; d=zohomail.com; s=zohoarc; b=EBYoenp7YtYNSRRUU7xACMP372c0dx92mPyLlHv8zoVxXTOx8zMXtdoSmL4mGu1RHommdQ9f26oncKvf2R5W4N7qB2sxLqqyQT94c+pZ6RB6C6Khy+6XTCNxb4r9fbc9RauSD+qmV5X5c/8vPWCxkGdzLQvJ7rKAAyyXcpo6aH8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787294519; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=3Sv77UAvL0ZdsbyH97t0JnaftxrQooorODzWX0jaZio=; b=Xci9HezNI3MLsUUWarJG3W1yF9+H6fVBPqt6+faagw9Az18Pzfrub61ZiRpERw5x0m1B+7gDFfQ/PmMI6VqoE9WTMaJjbE57CTnd3x5rZWi4fHI8cWfbLrPHTKqrSs/ufU8X9qQaM8gASegTV9l4FsJBOYk7HmYoabTnbMQsPrQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1787294519777567.9224726184881; Thu, 20 Aug 2026 23:41:59 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wxIwG-0001Y5-5z; Fri, 21 Aug 2026 02:41:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wxIwE-0001XE-Pd; Fri, 21 Aug 2026 02:41:14 -0400 Received: from [115.124.30.101] (helo=out30-101.freemail.mail.aliyun.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wxIw8-000660-Ps; Fri, 21 Aug 2026 02:41:14 -0400 Received: from localhost.localdomain(mailfrom:zhiwei_liu@linux.alibaba.com fp:SMTPD_---0X9LMiS5_1787294439 cluster:ay36) by smtp.aliyun-inc.com; Fri, 21 Aug 2026 14:40:40 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787294441; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=3Sv77UAvL0ZdsbyH97t0JnaftxrQooorODzWX0jaZio=; b=mjS37iUYhzpCV9cRP+9HYaceiACWSg5SUBUxh5nQ89AiUfTf6XNlY76IQEyVLxDKfmyCxeKyagALt0lyQZPa1dmLetMeRXJxj/dFgDzFnR4luSeftjfw0EuzzpbtWR4OXutmfBHaoWjo0LzWHp3vqKoqKpebnjDPzyEy6LgJ/3w= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R271e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=maildocker-contentspam011083073210; MF=zhiwei_liu@linux.alibaba.com; NM=1; PH=DS; RN=12; SR=0; TI=SMTPD_---0X9LMiS5_1787294439; From: LIU Zhiwei To: qemu-devel@nongnu.org, qemu-riscv@nongnu.org, qemu-arm@nongnu.org Cc: palmer@dabbelt.com, alistair.francis@wdc.com, liwei1518@gmail.com, daniel.barboza@oss.qualcomm.com, chao.liu@processmission.com, zhiwei_liu@linux.alibaba.com, peter.maydell@linaro.org, richard.henderson@linaro.org, TANG TianCheng Subject: [PATCH 1/3] target/riscv: Fix RCsc ordering of Zalasr store-release Date: Fri, 21 Aug 2026 14:40:30 +0800 Message-Id: <20260821064032.49556-2-zhiwei_liu@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260821064032.49556-1-zhiwei_liu@linux.alibaba.com> References: <20260821064032.49556-1-zhiwei_liu@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 115.124.30.101 (deferred) Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=115.124.30.101; envelope-from=zhiwei_liu@linux.alibaba.com; helo=out30-101.freemail.mail.aliyun.com X-Spam_score_int: -166 X-Spam_score: -16.7 X-Spam_bar: ---------------- X-Spam_report: (-16.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @linux.alibaba.com) X-ZM-MESSAGEID: 1787294523352158501 Content-Type: text/plain; charset="utf-8" The Zalasr load-acquire instructions carry an acquire-RCsc annotation and the store-release instructions carry a release-RCsc annotation; the extension has no RCpc variant (Zalasr specification, chapter 2). Per Rule 7 of the RVWMO preserved program order rules ("a and b both have RCsc annotations"), a Zalasr store-release must precede any subsequent RCsc memory operation of the same hart in the global memory order. In particular "sw.rl X=3D1; lw.aq r1=3DY" must be ordered, which is what forbids the [0,0] outcome of a Store Buffering litmus test that runs this pair on two harts. gen_store_release() only emits a barrier before the store, which orders the memory operations preceding the store before the store itself (Rule 6, release semantics). Nothing prevents the store from being reordered with the memory operations that follow it, so under MTTCG the host CPU may execute the load-acquire that immediately follows a store-release before the store has left its store buffer: * on an x86 host (TSO), store-load is the only reordering the hardware may perform, and it is exactly the ordering that is missing here; * on an aarch64 host, no dmb follows the store either. The defect is easily observed with a bare-metal Store Buffering litmus test on a 4 vCPU guest: "sw.rl X=3D1; lw.aq r1=3DY" on hart 0 and "sw.rl Y=3D1; lw.aq r2=3DX" on hart 1 produce the architecturally forbidden [0,0] result in 89881 out of 100000 iterations. Fix this by emitting a full barrier after the store as well, which mirrors the FENCE translation. The TCG_MO_ST_LD bit included in TCG_MO_ALL makes the x86 backend emit a serializing lock-prefixed instruction after the store, draining the store buffer before any subsequent load executes, and the aarch64 backend emit dmb ish; the store therefore becomes globally visible before any subsequent memory operation of the same vCPU, and Rule 7 is satisfied. This is stronger than Rule 7 strictly requires, since the barrier also orders the store with respect to subsequent non-RCsc operations, but this matches how QEMU already implements FENCE and keeps the fix simple. The load-acquire side needs no change: the barrier emitted after the load already orders it with all subsequent memory operations, which covers Rule 5 and the remaining Rule 7 combinations (load-load and load-store). Signed-off-by: LIU Zhiwei Co-authored-by: TANG TianCheng Signed-off-by: TANG TianCheng --- target/riscv/tcg/insn_trans/trans_rvzalasr.c.inc | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/target/riscv/tcg/insn_trans/trans_rvzalasr.c.inc b/target/risc= v/tcg/insn_trans/trans_rvzalasr.c.inc index 79b0b2c63b..28d9b13c55 100644 --- a/target/riscv/tcg/insn_trans/trans_rvzalasr.c.inc +++ b/target/riscv/tcg/insn_trans/trans_rvzalasr.c.inc @@ -86,6 +86,14 @@ static bool gen_store_release(DisasContext *ctx, arg_sb_= aqrl *a, MemOp memop) tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL | bar); =20 tcg_gen_qemu_st_tl(data, addr, ctx->mem_idx, memop); + + /* + * Zalasr annotations are always RCsc: per RVWMO Rule 7, the store + * must also be ordered before any subsequent memory operation, + * e.g. a load-acquire in a Store Buffering litmus test. The + * barrier above only orders previous memory ops before the store. + */ + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC); return true; } =20 --=20 2.43.0 From nobody Fri Aug 21 21:29:26 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=linux.alibaba.com ARC-Seal: i=1; a=rsa-sha256; t=1787294520; cv=none; d=zohomail.com; s=zohoarc; b=EGXV7MpU/h6jf2+Jg6fjeteEDZaBYgF22+zaG23XlxI9Z7Qvmnasf4NP1AOZdLeN4YBBu3bMmqpn1gZCPygXlTOasFtN7vUDy/s94pIDCZgZBhJdyOeBQDZq0BBSAK6Utc6jJIC9dWXKMG0NjsgY0sOZ5M67Ou8wKx7Lp0kIeXM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787294520; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=UKnM9cWdP672CNzhiWDOMhhND+Qv5p67Q8VNGPB24y0=; b=BLYxVmUZEp+0SPto+c01QydKMKPmmhHVGdDA8itQNxzuJOwsmUKHTFEFmjEdGbRboChcXS32b9jUKV/bDIzrPCMS2DqDr+dr7dz24VQVNTzdP+o3Fy+IWZshYZOIOd1fdYOXqKVzT7Rud53whoeKIaCuJ8tVSuBGO7OYyh9tS9Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1787294519900640.8118047532113; Thu, 20 Aug 2026 23:41:59 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wxIwG-0001Y9-BZ; Fri, 21 Aug 2026 02:41:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wxIwE-0001WZ-7T; Fri, 21 Aug 2026 02:41:14 -0400 Received: from [115.124.30.131] (helo=out30-131.freemail.mail.aliyun.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wxIw9-000661-0D; Fri, 21 Aug 2026 02:41:13 -0400 Received: from localhost.localdomain(mailfrom:zhiwei_liu@linux.alibaba.com fp:SMTPD_---0X9LMiSM_1787294440 cluster:ay36) by smtp.aliyun-inc.com; Fri, 21 Aug 2026 14:40:41 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787294441; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=UKnM9cWdP672CNzhiWDOMhhND+Qv5p67Q8VNGPB24y0=; b=dNwEUWKHiih9g2AdvMJ/A+r0aRAfwLLMk6xt5kduR34+1o352GTlyVlDFht/V3mjKPJG4Mpg+gajs+KbJL8bcnzK7SnzejvrNsMjg9G7KemkFDK+UP5SE/ZyQU4ddBdqNwZoYWS5/G/uZ2FOXyCGlu6BqMC6VBBCjb/l5ZBc6K8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=maildocker-contentspam033037009110; MF=zhiwei_liu@linux.alibaba.com; NM=1; PH=DS; RN=11; SR=0; TI=SMTPD_---0X9LMiSM_1787294440; From: LIU Zhiwei To: qemu-devel@nongnu.org, qemu-riscv@nongnu.org, qemu-arm@nongnu.org Cc: palmer@dabbelt.com, alistair.francis@wdc.com, liwei1518@gmail.com, daniel.barboza@oss.qualcomm.com, chao.liu@processmission.com, zhiwei_liu@linux.alibaba.com, peter.maydell@linaro.org, richard.henderson@linaro.org Subject: [PATCH 2/3] target/arm: Fix RCsc ordering of store-release instructions Date: Fri, 21 Aug 2026 14:40:31 +0800 Message-Id: <20260821064032.49556-3-zhiwei_liu@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260821064032.49556-1-zhiwei_liu@linux.alibaba.com> References: <20260821064032.49556-1-zhiwei_liu@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 115.124.30.131 (deferred) Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=115.124.30.131; envelope-from=zhiwei_liu@linux.alibaba.com; helo=out30-131.freemail.mail.aliyun.com X-Spam_score_int: -166 X-Spam_score: -16.7 X-Spam_bar: ---------------- X-Spam_report: (-16.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @linux.alibaba.com) X-ZM-MESSAGEID: 1787294523350158500 Content-Type: text/plain; charset="utf-8" The Armv8 memory model has no RCpc store: every store-release in the architecture, including the AArch64 STLR and STLPUR and the A32/T32 STL, STLB and STLH, carries RCsc semantics (Arm Architecture Reference Manual, DDI 0487, section B2.3.8 "Acquire and release semantics"). The architecture therefore orders a Store-Release tagged RCsc before any subsequent Load-Acquire tagged RCsc of the same shareability domain, which is what forbids the [0,0] outcome of a Store Buffering litmus test that pairs "STLR X=3D1; LDAR Y" on one PE with "STLR Y=3D1; LDAR X" on another. The translators only emit a barrier before the store, which orders the memory operations preceding the store before the store itself (release semantics). Nothing prevents the store from being reordered with the memory operations that follow it, so under MTTCG the host CPU may execute the load-acquire that immediately follows a store-release before the store has left its store buffer: * on an x86 host (TSO), store-load is the only reordering the hardware may perform, and it is exactly the ordering that is missing here; * on an aarch64 host, no dmb follows the store either. The defect is easily observed with a bare-metal Store Buffering litmus test on a 2 vCPU virt guest: "STLR X=3D1; LDAR Y" on CPU 0 and "STLR Y=3D1; LDAR X" on CPU 1 produce the architecturally forbidden [0,0] result in 6 to 7 out of 100000 iterations, while inserting a DMB ISH between the store and the load on each CPU brings the number to 0, which validates the harness. Fix this by emitting a full barrier after the store as well, for STLR/STLLR and STLPUR on the AArch64 side and STL/STLB/STLH on the A32/T32 side. The TCG_MO_ST_LD bit included in TCG_MO_ALL makes the x86 backend emit a serializing lock-prefixed instruction after the store, draining the store buffer before any subsequent load executes, and the aarch64 backend emit dmb ish; the store therefore becomes globally visible before any subsequent memory operation of the same vCPU, and the RCsc store->load ordering is satisfied. This is stronger than the architecture strictly requires, since the barrier also orders the store with respect to subsequent RCpc operations such as LDAPR, but this matches how QEMU already implements FENCE-like ordering and keeps the fix simple. After the fix the litmus test no longer produces the forbidden outcome. The load-acquire side needs no change: the barrier emitted after an RCsc LDAR already orders it with all subsequent memory operations, and QEMU deliberately implements the RCpc LDAPR family as full load-acquire. Signed-off-by: LIU Zhiwei --- target/arm/tcg/translate-a64.c | 13 +++++++++++++ target/arm/tcg/translate.c | 6 ++++++ 2 files changed, 19 insertions(+) diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c index 4f9a93950b..b5bf977910 100644 --- a/target/arm/tcg/translate-a64.c +++ b/target/arm/tcg/translate-a64.c @@ -3672,6 +3672,13 @@ static bool trans_STLR(DisasContext *s, arg_stlr *a) true, a->rn !=3D 31, memop); do_gpr_st(s, cpu_reg(s, a->rt), clean_addr, memop, true, a->rt, iss_sf, a->lasr); + /* + * STLR is an RCsc store-release: the Armv8 architecture orders it + * before any subsequent RCsc load-acquire, which is what forbids the + * store-buffering litmus test. The barrier above only orders + * previous accesses before the store. + */ + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC); return true; } =20 @@ -4415,6 +4422,12 @@ static bool trans_STLR_i(DisasContext *s, arg_ldapr_= stlr_i *a) /* Store-Release semantics */ tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL); do_gpr_st(s, cpu_reg(s, a->rt), clean_addr, mop, true, a->rt, iss_sf, = true); + /* + * Like STLR, STLPUR is an RCsc store-release and must be ordered + * before any subsequent RCsc load-acquire, so it needs a barrier + * after the store as well. + */ + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC); return true; } =20 diff --git a/target/arm/tcg/translate.c b/target/arm/tcg/translate.c index 1770428d3c..bddac41bf9 100644 --- a/target/arm/tcg/translate.c +++ b/target/arm/tcg/translate.c @@ -4259,6 +4259,12 @@ static bool op_stl(DisasContext *s, arg_STL *a, MemO= p mop) tmp =3D load_reg(s, a->rt); tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL); gen_aa32_st_i32(s, tmp, addr, get_mem_index(s), mop | MO_ALIGN); + /* + * STL has the same RCsc store-release semantics as the AArch64 STLR + * and must be ordered before a subsequent RCsc load-acquire (LDA). + * The barrier above only orders previous accesses before the store. + */ + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_SC); disas_set_da_iss(s, mop, a->rt | ISSIsAcqRel | ISSIsWrite); =20 return true; --=20 2.43.0 From nobody Fri Aug 21 21:29:26 2026 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=linux.alibaba.com ARC-Seal: i=1; a=rsa-sha256; t=1787294519; cv=none; d=zohomail.com; s=zohoarc; b=GflHWnVdM14bSoYmFtsESiKqbm+AQNa8RXGuicYADRVbtC0XH/F6RdgRMJiRph5ML8P86nU/8uEVl3MS4w9Jl63TF/bFPb1pxCCQhH6jHjDC7Qx2tT7MvpZVuEUQvseGpoD8Bu6W+q5LJM98Kdbz2sg9mV0ddoFXfwBj1tuaFJs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787294519; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=DBulrXCYmN9obTHaPtKhQcdAYvfQQ3QKSWI0GMPC3C0=; b=jiSwnTrvKw0hwOXrwTRSowrhsVSdyL9lhuiO9423pXt6VcygGGyrBq8X1tzm/Bvc8Op3hYhm+qvtK0vBquxhLJ9nKEepAwcFM3eTiBvpaPm2RvgMQ+Ez29pQ9Y/+qIFpVDpK0QBRPLUgyB+ZoJc2Z2VWtVkXJe0p+cDM25vpHyE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1787294519828396.83980435368744; Thu, 20 Aug 2026 23:41:59 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1wxIwF-0001WX-Ar; Fri, 21 Aug 2026 02:41:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wxIwC-0001VY-Ck; Fri, 21 Aug 2026 02:41:12 -0400 Received: from [115.124.30.97] (helo=out30-97.freemail.mail.aliyun.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wxIw8-00066A-VE; Fri, 21 Aug 2026 02:41:12 -0400 Received: from localhost.localdomain(mailfrom:zhiwei_liu@linux.alibaba.com fp:SMTPD_---0X9LMiSs_1787294441 cluster:ay36) by smtp.aliyun-inc.com; Fri, 21 Aug 2026 14:40:41 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787294442; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=DBulrXCYmN9obTHaPtKhQcdAYvfQQ3QKSWI0GMPC3C0=; b=grtLEvgbofEOsCzVSri4oZVJZnC7usgrQo7xx16zxAHP4IbLxiKIyPx3/Iyl8VFO7QCVvphW0g4fd9V9BCKd94DorXWuFYb3VvQFN3hMbHDr46KWsWG4dyFn8SpWYVqavpxmVAnbUGwpEiEgUbnnT1WkOrREy7z8hS09Bg8IYe4= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R381e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=maildocker-contentspam033032089153; MF=zhiwei_liu@linux.alibaba.com; NM=1; PH=DS; RN=11; SR=0; TI=SMTPD_---0X9LMiSs_1787294441; From: LIU Zhiwei To: qemu-devel@nongnu.org, qemu-riscv@nongnu.org, qemu-arm@nongnu.org Cc: palmer@dabbelt.com, alistair.francis@wdc.com, liwei1518@gmail.com, daniel.barboza@oss.qualcomm.com, chao.liu@processmission.com, zhiwei_liu@linux.alibaba.com, peter.maydell@linaro.org, richard.henderson@linaro.org Subject: [PATCH 3/3] target/arm: Fix barrier polarity of A32 LDA load-acquire Date: Fri, 21 Aug 2026 14:40:32 +0800 Message-Id: <20260821064032.49556-4-zhiwei_liu@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260821064032.49556-1-zhiwei_liu@linux.alibaba.com> References: <20260821064032.49556-1-zhiwei_liu@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 115.124.30.97 (deferred) Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists1p.gnu.org; Received-SPF: pass client-ip=115.124.30.97; envelope-from=zhiwei_liu@linux.alibaba.com; helo=out30-97.freemail.mail.aliyun.com X-Spam_score_int: -166 X-Spam_score: -16.7 X-Spam_bar: ---------------- X-Spam_report: (-16.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @linux.alibaba.com) X-ZM-MESSAGEID: 1787294523312158500 Content-Type: text/plain; charset="utf-8" The A32 and T32 load-acquire instructions LDA, LDAB and LDAH must be ordered before the memory accesses that follow them, so their translator has to emit a trailing barrier. op_lda() emits that barrier with TCG_BAR_STRL instead of TCG_BAR_LDAQ, inverting the polarity: TCG_BAR_STRL annotates a leading barrier ("previous ops will not be delayed") and TCG_BAR_LDAQ a trailing one ("following ops will not come forward"), as documented in include/tcg/tcg-mo.h. The x86 and aarch64 backends only look at the TCG_MO_* bits, which the wrong annotation does not affect, so the generated host code is unchanged on those hosts. The annotation is still wrong: it violates the TCG barrier contract, it lets the optimizer's barrier merging in fold_mb() combine the barriers of an "LDA; STL" pair into a weaker one than the correctly annotated form (STRL|STRL stays STRL instead of LDAQ|STRL =3D SC), and it diverges from every other load-acquire translation in the target, which all use TCG_BAR_LDAQ. Fix the polarity. Signed-off-by: LIU Zhiwei --- target/arm/tcg/translate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/arm/tcg/translate.c b/target/arm/tcg/translate.c index bddac41bf9..a81b8d3852 100644 --- a/target/arm/tcg/translate.c +++ b/target/arm/tcg/translate.c @@ -4421,7 +4421,7 @@ static bool op_lda(DisasContext *s, arg_LDA *a, MemOp= mop) disas_set_da_iss(s, mop, a->rt | ISSIsAcqRel); =20 store_reg(s, a->rt, tmp); - tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL); + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_LDAQ); return true; } =20 --=20 2.43.0