From: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
To: Christoph Muellner <christoph.muellner@vrull.eu>,
qemu-riscv@nongnu.org, qemu-devel@nongnu.org,
Alistair Francis <alistair.francis@wdc.com>,
Bin Meng <bin.meng@windriver.com>,
Philipp Tomsich <philipp.tomsich@vrull.eu>,
Palmer Dabbelt <palmer@dabbelt.com>,
Richard Henderson <richard.henderson@linaro.org>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
Weiwei Li <liwei1518@gmail.com>,
Liu Zhiwei <zhiwei_liu@linux.alibaba.com>
Subject: Re: [RFC PATCH 1/2] RISC-V: Add support for Ztso
Date: Tue, 14 Nov 2023 10:22:46 -0300 [thread overview]
Message-ID: <b77ac647-c4d7-4dfc-bde5-1efffb4ebe91@ventanamicro.com> (raw)
In-Reply-To: <20231113095605.1131443-2-christoph.muellner@vrull.eu>
On 11/13/23 06:56, Christoph Muellner wrote:
> From: Palmer Dabbelt <palmer@rivosinc.com>
>
> The Ztso extension is already ratified, this adds it as a CPU property
> and adds various fences throughout the port in order to allow TSO
> targets to function on weaker hosts. We need no fences for AMOs as
> they're already SC, the placess we need barriers are described.
s/placess/places
> These fences are placed in the RISC-V backend rather than TCG as is
> planned for x86-on-arm64 because RISC-V allows heterogenous (and
s/heterogenous/heterogeneous
> likely soon dynamic) hart memory models.
>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
> ---
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> target/riscv/cpu.c | 2 ++
> target/riscv/cpu_cfg.h | 1 +
> target/riscv/insn_trans/trans_rva.c.inc | 11 ++++++++---
> target/riscv/insn_trans/trans_rvi.c.inc | 16 ++++++++++++++--
> target/riscv/insn_trans/trans_rvv.c.inc | 20 ++++++++++++++++++++
> target/riscv/translate.c | 3 +++
> 6 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 83c7c0cf07..b446e553b1 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -118,6 +118,7 @@ const RISCVIsaExtData isa_edata_arr[] = {
> ISA_EXT_DATA_ENTRY(zksed, PRIV_VERSION_1_12_0, ext_zksed),
> ISA_EXT_DATA_ENTRY(zksh, PRIV_VERSION_1_12_0, ext_zksh),
> ISA_EXT_DATA_ENTRY(zkt, PRIV_VERSION_1_12_0, ext_zkt),
> + ISA_EXT_DATA_ENTRY(ztso, PRIV_VERSION_1_12_0, ext_ztso),
> ISA_EXT_DATA_ENTRY(zvbb, PRIV_VERSION_1_12_0, ext_zvbb),
> ISA_EXT_DATA_ENTRY(zvbc, PRIV_VERSION_1_12_0, ext_zvbc),
> ISA_EXT_DATA_ENTRY(zve32f, PRIV_VERSION_1_10_0, ext_zve32f),
> @@ -1336,6 +1337,7 @@ const RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
> MULTI_EXT_CFG_BOOL("zksed", ext_zksed, false),
> MULTI_EXT_CFG_BOOL("zksh", ext_zksh, false),
> MULTI_EXT_CFG_BOOL("zkt", ext_zkt, false),
> + MULTI_EXT_CFG_BOOL("ztso", ext_ztso, false),
>
> MULTI_EXT_CFG_BOOL("zdinx", ext_zdinx, false),
> MULTI_EXT_CFG_BOOL("zfinx", ext_zfinx, false),
> diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
> index f4605fb190..a0f951d9c1 100644
> --- a/target/riscv/cpu_cfg.h
> +++ b/target/riscv/cpu_cfg.h
> @@ -70,6 +70,7 @@ struct RISCVCPUConfig {
> bool ext_zihintntl;
> bool ext_zihintpause;
> bool ext_zihpm;
> + bool ext_ztso;
> bool ext_smstateen;
> bool ext_sstc;
> bool ext_svadu;
> diff --git a/target/riscv/insn_trans/trans_rva.c.inc b/target/riscv/insn_trans/trans_rva.c.inc
> index 5f194a447b..85c7e31f2a 100644
> --- a/target/riscv/insn_trans/trans_rva.c.inc
> +++ b/target/riscv/insn_trans/trans_rva.c.inc
> @@ -28,7 +28,11 @@ static bool gen_lr(DisasContext *ctx, arg_atomic *a, MemOp mop)
> tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL);
> }
> tcg_gen_qemu_ld_tl(load_val, src1, ctx->mem_idx, mop);
> - if (a->aq) {
> + /*
> + * TSO defines AMOs as acquire+release-RCsc, but does not define LR/SC as
> + * AMOs. Instead treat them like loads.
> + */
> + if (a->aq || ctx->ztso) {
> tcg_gen_mb(TCG_MO_ALL | TCG_BAR_LDAQ);
> }
>
> @@ -64,9 +68,10 @@ static bool gen_sc(DisasContext *ctx, arg_atomic *a, MemOp mop)
> gen_set_label(l1);
> /*
> * Address comparison failure. However, we still need to
> - * provide the memory barrier implied by AQ/RL.
> + * provide the memory barrier implied by AQ/RL/TSO.
> */
> - tcg_gen_mb(TCG_MO_ALL + a->aq * TCG_BAR_LDAQ + a->rl * TCG_BAR_STRL);
> + TCGBar bar_strl = (ctx->ztso || a->rl) ? TCG_BAR_STRL : 0;
> + tcg_gen_mb(TCG_MO_ALL + a->aq * TCG_BAR_LDAQ + bar_strl);
> gen_set_gpr(ctx, a->rd, tcg_constant_tl(1));
>
> gen_set_label(l2);
> diff --git a/target/riscv/insn_trans/trans_rvi.c.inc b/target/riscv/insn_trans/trans_rvi.c.inc
> index faf6d65064..ad40d3e87f 100644
> --- a/target/riscv/insn_trans/trans_rvi.c.inc
> +++ b/target/riscv/insn_trans/trans_rvi.c.inc
> @@ -266,12 +266,20 @@ static bool gen_load_i128(DisasContext *ctx, arg_lb *a, MemOp memop)
>
> static bool gen_load(DisasContext *ctx, arg_lb *a, MemOp memop)
> {
> + bool out;
> +
> decode_save_opc(ctx);
> if (get_xl(ctx) == MXL_RV128) {
> - return gen_load_i128(ctx, a, memop);
> + out = gen_load_i128(ctx, a, memop);
> } else {
> - return gen_load_tl(ctx, a, memop);
> + out = gen_load_tl(ctx, a, memop);
> + }
> +
> + if (ctx->ztso) {
> + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_LDAQ);
> }
> +
> + return out;
> }
>
> static bool trans_lb(DisasContext *ctx, arg_lb *a)
> @@ -328,6 +336,10 @@ static bool gen_store_tl(DisasContext *ctx, arg_sb *a, MemOp memop)
> TCGv addr = get_address(ctx, a->rs1, a->imm);
> TCGv data = get_gpr(ctx, a->rs2, EXT_NONE);
>
> + if (ctx->ztso) {
> + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL);
> + }
> +
> tcg_gen_qemu_st_tl(data, addr, ctx->mem_idx, memop);
> return true;
> }
> diff --git a/target/riscv/insn_trans/trans_rvv.c.inc b/target/riscv/insn_trans/trans_rvv.c.inc
> index 78bd363310..76e63fcbca 100644
> --- a/target/riscv/insn_trans/trans_rvv.c.inc
> +++ b/target/riscv/insn_trans/trans_rvv.c.inc
> @@ -636,8 +636,28 @@ static bool ldst_us_trans(uint32_t vd, uint32_t rs1, uint32_t data,
> tcg_gen_addi_ptr(dest, tcg_env, vreg_ofs(s, vd));
> tcg_gen_addi_ptr(mask, tcg_env, vreg_ofs(s, 0));
>
> + /*
> + * According to the specification
> + *
> + * Additionally, if the Ztso extension is implemented, then vector memory
> + * instructions in the V extension and Zve family of extensions follow
> + * RVTSO at the instruction level. The Ztso extension does not
> + * strengthen the ordering of intra-instruction element accesses.
> + *
> + * as a result neither ordered nor unordered accesses from the V
> + * instructions need ordering within the loop but we do still need barriers
> + * around the loop.
> + */
> + if (is_store && s->ztso) {
> + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL);
> + }
> +
> fn(dest, mask, base, tcg_env, desc);
>
> + if (!is_store && s->ztso) {
> + tcg_gen_mb(TCG_MO_ALL | TCG_BAR_LDAQ);
> + }
> +
> if (!is_store) {
> mark_vs_dirty(s);
> }
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index f0be79bb16..ab56051d6d 100644
> --- a/target/riscv/translate.c
> +++ b/target/riscv/translate.c
> @@ -109,6 +109,8 @@ typedef struct DisasContext {
> /* PointerMasking extension */
> bool pm_mask_enabled;
> bool pm_base_enabled;
> + /* Ztso */
> + bool ztso;
> /* Use icount trigger for native debug */
> bool itrigger;
> /* FRM is known to contain a valid value. */
> @@ -1194,6 +1196,7 @@ static void riscv_tr_init_disas_context(DisasContextBase *dcbase, CPUState *cs)
> ctx->cs = cs;
> ctx->pm_mask_enabled = FIELD_EX32(tb_flags, TB_FLAGS, PM_MASK_ENABLED);
> ctx->pm_base_enabled = FIELD_EX32(tb_flags, TB_FLAGS, PM_BASE_ENABLED);
> + ctx->ztso = cpu->cfg.ext_ztso;
> ctx->itrigger = FIELD_EX32(tb_flags, TB_FLAGS, ITRIGGER);
> ctx->zero = tcg_constant_tl(0);
> ctx->virt_inst_excp = false;
next prev parent reply other threads:[~2023-11-14 13:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 9:56 [RFC PATCH 0/2] RISC-V: Add TSO extensions (Ztso/Ssdtso) Christoph Muellner
2023-11-13 9:56 ` [RFC PATCH 1/2] RISC-V: Add support for Ztso Christoph Muellner
2023-11-14 13:22 ` Daniel Henrique Barboza [this message]
2023-11-13 9:56 ` [RFC PATCH 2/2] RISC-V: Add support for Ssdtso Christoph Muellner
2023-11-14 13:23 ` Daniel Henrique Barboza
-- strict thread matches above, loose matches on Subject: below --
2022-09-17 7:26 [PATCH v2] RISC-V: Add support for Ztso Palmer Dabbelt
2023-11-13 9:56 ` Christoph Muellner
2022-09-23 4:35 ` Alistair Francis
2022-09-23 10:49 ` Palmer Dabbelt
2022-09-25 10:28 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b77ac647-c4d7-4dfc-bde5-1efffb4ebe91@ventanamicro.com \
--to=dbarboza@ventanamicro.com \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=christoph.muellner@vrull.eu \
--cc=liwei1518@gmail.com \
--cc=palmer@dabbelt.com \
--cc=palmer@rivosinc.com \
--cc=philipp.tomsich@vrull.eu \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=zhiwei_liu@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.