From: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
To: Max Chou <max.chou@sifive.com>,
qemu-devel@nongnu.org, qemu-riscv@nongnu.org
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>,
Weiwei Li <liwei1518@gmail.com>,
Liu Zhiwei <zhiwei_liu@linux.alibaba.com>
Subject: Re: [RFC PATCH 3/8] target/riscv: rvv: Add new VTYPE CSR field - altfmt
Date: Wed, 17 Sep 2025 10:57:33 -0300 [thread overview]
Message-ID: <26d72d8e-5e58-4a04-865c-34f6094e74e9@ventanamicro.com> (raw)
In-Reply-To: <20250915084037.1816893-4-max.chou@sifive.com>
On 9/15/25 5:40 AM, Max Chou wrote:
> According to the Zvfbfa ISA spec v0.1, the vtype CSR adds a new field:
> altfmt for BF16 support.
> This update changes the layout of the vtype CSR fields.
>
> Signed-off-by: Max Chou <max.chou@sifive.com>
> ---
> target/riscv/cpu.h | 4 ++--
> target/riscv/vector_helper.c | 29 ++++++++++++++++++++++++-----
> 2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 738e68fa6e2..532386000af 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -190,8 +190,8 @@ FIELD(VTYPE, VLMUL, 0, 3)
> FIELD(VTYPE, VSEW, 3, 3)
> FIELD(VTYPE, VTA, 6, 1)
> FIELD(VTYPE, VMA, 7, 1)
> -FIELD(VTYPE, VEDIV, 8, 2)
> -FIELD(VTYPE, RESERVED, 10, sizeof(target_ulong) * 8 - 11)
> +FIELD(VTYPE, ALTFMT, 8, 1)
> +FIELD(VTYPE, RESERVED, 9, sizeof(target_ulong) * 8 - 10)
>
> typedef struct PMUCTRState {
> /* Current value of a counter */
> diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
> index 7c67d67a13f..603d0731ae1 100644
> --- a/target/riscv/vector_helper.c
> +++ b/target/riscv/vector_helper.c
> @@ -33,6 +33,22 @@
> #include "vector_internals.h"
> #include <math.h>
>
> +static target_ulong vtype_reserved(CPURISCVState *env, target_ulong vtype)
> +{
> + int xlen = riscv_cpu_xlen(env);
> + target_ulong reserved = 0;
> +
> + if (riscv_cpu_cfg(env)->ext_zvfbfa) {
> + reserved = vtype & MAKE_64BIT_MASK(R_VTYPE_RESERVED_SHIFT,
> + xlen - 1 - R_VTYPE_RESERVED_SHIFT);
> + } else {
> + reserved = vtype & MAKE_64BIT_MASK(R_VTYPE_ALTFMT_SHIFT,
> + xlen - 1 - R_VTYPE_ALTFMT_SHIFT);
> + }
Is this correct? The 'reserved' value you're returning when the new extension is enabled
is the original value from vsetvl:
> + if (riscv_cpu_cfg(env)->ext_zvfbfa) {
> + reserved = vtype & MAKE_64BIT_MASK(R_VTYPE_RESERVED_SHIFT,
> + xlen - 1 - R_VTYPE_RESERVED_SHIFT);
The original val you removed:
> - target_ulong reserved = s2 &
> - MAKE_64BIT_MASK(R_VTYPE_RESERVED_SHIFT,
> - xlen - 1 - R_VTYPE_RESERVED_SHIFT);
To preserve the existing behavior I believe you want to negate the conditional:
> + if (!riscv_cpu_cfg(env)->ext_zvfbfa) {
> + reserved = vtype & MAKE_64BIT_MASK(R_VTYPE_RESERVED_SHIFT,
> + xlen - 1 - R_VTYPE_RESERVED_SHIFT);
> + } else {
> + reserved = vtype & MAKE_64BIT_MASK(R_VTYPE_ALTFMT_SHIFT,
> + xlen - 1 - R_VTYPE_ALTFMT_SHIFT);
> + }
i.e. return the existing 'reserved' val if the new extension is absent, otherwise return
the new val.
Thanks,
Daniel
> +
> + return reserved;
> +}
> +
> target_ulong HELPER(vsetvl)(CPURISCVState *env, target_ulong s1,
> target_ulong s2, target_ulong x0)
> {
> @@ -41,12 +57,9 @@ target_ulong HELPER(vsetvl)(CPURISCVState *env, target_ulong s1,
> uint64_t vlmul = FIELD_EX64(s2, VTYPE, VLMUL);
> uint8_t vsew = FIELD_EX64(s2, VTYPE, VSEW);
> uint16_t sew = 8 << vsew;
> - uint8_t ediv = FIELD_EX64(s2, VTYPE, VEDIV);
> + uint8_t altfmt = FIELD_EX64(s2, VTYPE, ALTFMT);
> int xlen = riscv_cpu_xlen(env);
> bool vill = (s2 >> (xlen - 1)) & 0x1;
> - target_ulong reserved = s2 &
> - MAKE_64BIT_MASK(R_VTYPE_RESERVED_SHIFT,
> - xlen - 1 - R_VTYPE_RESERVED_SHIFT);
> uint16_t vlen = cpu->cfg.vlenb << 3;
> int8_t lmul;
>
> @@ -63,7 +76,13 @@ target_ulong HELPER(vsetvl)(CPURISCVState *env, target_ulong s1,
> }
> }
>
> - if ((sew > cpu->cfg.elen) || vill || (ediv != 0) || (reserved != 0)) {
> + if (cpu->cfg.ext_zvfbfa) {
> + if (altfmt == 1 && vsew >= MO_32) {
> + vill = true;
> + }
> + }
> +
> + if ((sew > cpu->cfg.elen) || vill || (vtype_reserved(env, s2) != 0)) {
> /* only set vill bit. */
> env->vill = 1;
> env->vtype = 0;
next prev parent reply other threads:[~2025-09-17 13:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 8:40 [RFC PATCH 0/8] Add Zvfbfa extension support Max Chou
2025-09-15 8:40 ` [RFC PATCH 1/8] target/riscv: Add cfg properities for Zvfbfa extensions Max Chou
2025-09-17 13:47 ` Daniel Henrique Barboza
2025-09-15 8:40 ` [RFC PATCH 2/8] target/riscv: Add the Zvfbfa extension implied rule Max Chou
2025-09-17 13:47 ` Daniel Henrique Barboza
2025-09-15 8:40 ` [RFC PATCH 3/8] target/riscv: rvv: Add new VTYPE CSR field - altfmt Max Chou
2025-09-17 13:57 ` Daniel Henrique Barboza [this message]
2025-09-22 8:03 ` Max Chou
2025-09-22 11:41 ` Daniel Henrique Barboza
2025-09-15 8:40 ` [RFC PATCH 4/8] target/riscv: Use the tb->cs_bqse as the extend tb flags Max Chou
2025-09-15 8:40 ` [RFC PATCH 5/8] target/riscv: Introduce altfmt into DisasContext Max Chou
2025-09-15 8:40 ` [RFC PATCH 6/8] target/riscv: Introduce BF16 canonical NaN for Zvfbfa extension Max Chou
2025-09-15 8:40 ` [RFC PATCH 7/8] target/riscv: rvv: Support Zvfbfa vector bf16 operations Max Chou
2025-09-15 8:40 ` [RFC PATCH 8/8] target/riscv: Expose Zvfbfa extension as an experimental cpu property Max Chou
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=26d72d8e-5e58-4a04-865c-34f6094e74e9@ventanamicro.com \
--to=dbarboza@ventanamicro.com \
--cc=alistair.francis@wdc.com \
--cc=liwei1518@gmail.com \
--cc=max.chou@sifive.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).