From: Max Chou <max.chou@sifive.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>,
Weiwei Li <liwei1518@gmail.com>,
Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>,
Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
Chao Liu <chao.liu.zevorn@gmail.com>
Subject: Re: [PATCH v5 0/9] Add Zvfbfa extension support
Date: Mon, 16 Mar 2026 16:28:50 +0800 [thread overview]
Message-ID: <abe80eiIC4gXUHxk@sifive.com> (raw)
In-Reply-To: <CAKmqyKOcCKAb2w2t2qYgOevswst75FjzKfihrYP9+odRAsCQmw@mail.gmail.com>
On 2026-03-13 11:09, Alistair Francis wrote:
> The problem here is that there is no version control. If we merge this
> series and the PR changes then suddenly we are out of sync there is no
> way to track which version of the draft spec we support.
>
> We need clear versions, like we previously have. For example version
> 0.7 and then 0.8. Draft versions are ok, but we need a stable target
> to develop against.
>
> >
> > PR #2743 is currently open, meaning ratification is pending but not
> > yet complete. Under the new workflow, merge into main of
> > riscv-isa-manual is the signal that ratification is finalized. If you
> > prefer to wait until that merge happens before applying this patchset,
> > I completely understand. Alternatively, if you are comfortable
> > accepting it as ratification-pending, I am happy to address any
> > remaining technical comments.
>
> In this case we will have to wait as there is no stable version of the
> spec to point to.
>
> Alistair
>
Hi Alistair,
Thank you for your feedback on the version control and stability of the
Zvfbfa specification. I understand your concern about developing against
a moving target.
To address the lack of a stable target as you mentioned, I’d like to
help bridge this gap. Since this patchset was prepared based on the
Zvfbfa version v0.1 and this version has passed the ARC review, I
propose we coordinate with the Zvfbfa isa designer to check the
specific tag/commit ID of the Zvfbfa v0.1.
If we could create a tag or release for v0.1 (e.g., v0.1/v0.1-draft)
within the Zvfbfa repository that explicitly marks the current state of
the Zvfbfa spec, would that provide the necessary versioning baseline
for you to accept this patchset?
My goal is to ensure QEMU supports a traceable version of the draft spec
while respecting the current RVIA development process for this ISA
implementation patchset and the followings in the future.
rnax
next prev parent reply other threads:[~2026-03-16 8:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 7:10 [PATCH v5 0/9] Add Zvfbfa extension support Max Chou
2026-03-06 7:10 ` [PATCH v5 1/9] target/riscv: Add cfg properties for Zvfbfa extensions Max Chou
2026-03-09 4:44 ` Alistair Francis
2026-03-06 7:10 ` [PATCH v5 2/9] target/riscv: Add the Zvfbfa extension implied rule Max Chou
2026-03-09 4:45 ` Alistair Francis
2026-03-06 7:10 ` [PATCH v5 3/9] target/riscv: rvv: Add new VTYPE CSR field - altfmt Max Chou
2026-03-09 4:55 ` Alistair Francis
2026-03-16 9:20 ` Nutty.Liu
2026-03-06 7:10 ` [PATCH v5 4/9] target/riscv: rvv: Introduce reset_ill_vtype to reset illegal vtype CSR Max Chou
2026-03-09 4:55 ` Alistair Francis
2026-03-16 9:22 ` Nutty.Liu
2026-03-06 7:11 ` [PATCH v5 5/9] target/riscv: Use the tb->cs_base as the extend tb flags Max Chou
2026-03-09 5:01 ` Alistair Francis
2026-03-12 11:42 ` Max Chou
2026-03-13 0:59 ` Alistair Francis
2026-03-06 7:11 ` [PATCH v5 6/9] target/riscv: Introduce altfmt into DisasContext Max Chou
2026-03-09 5:02 ` Alistair Francis
2026-03-06 7:11 ` [PATCH v5 7/9] target/riscv: Introduce BF16 canonical NaN for Zvfbfa extension Max Chou
2026-03-09 5:04 ` Alistair Francis
2026-03-06 7:11 ` [PATCH v5 8/9] target/riscv: rvv: Support Zvfbfa vector bf16 operations Max Chou
2026-03-06 7:11 ` [PATCH v5 9/9] target/riscv: Expose Zvfbfa extension as an experimental cpu property Max Chou
2026-03-09 4:51 ` [PATCH v5 0/9] Add Zvfbfa extension support Alistair Francis
2026-03-12 11:16 ` Max Chou
2026-03-13 1:09 ` Alistair Francis
2026-03-16 8:28 ` Max Chou [this message]
2026-03-19 3:45 ` Alistair Francis
2026-03-26 3:42 ` Max Chou
2026-03-26 6:07 ` Chao Liu
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=abe80eiIC4gXUHxk@sifive.com \
--to=max.chou@sifive.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=chao.liu.zevorn@gmail.com \
--cc=daniel.barboza@oss.qualcomm.com \
--cc=liwei1518@gmail.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