From: Alistair Francis <alistair23@gmail.com>
To: Max Chou <max.chou@sifive.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: Thu, 19 Mar 2026 13:45:00 +1000 [thread overview]
Message-ID: <CAKmqyKP-42diNbiAwr_qykVTAYgR=Ok2S4dgLwPN5oGuLTQGRg@mail.gmail.com> (raw)
In-Reply-To: <abe80eiIC4gXUHxk@sifive.com>
On Mon, Mar 16, 2026 at 6:28 PM Max Chou <max.chou@sifive.com> wrote:
>
> 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?
Yes, that's how things previously worked. Basically I think we just
need a tag (that won't be changed) in an official RISC-V repo that we
can point to. That way it's easy to say "this is the exact version we
used to write the QEMU implementation". Then if there is a version 0.2
we can easily see what has changed and update to match.
With the seemingly infinite number of draft extensions we need
something to manage the version and compatibility, and that seems like
the best bet.
Posting the draft PDF spec somewhere immutable would also work. We
just need to be able to point to something that won't change and
represents some sort of "release". So a git commit doesn't seem like
enough, we need a "release" that everyone can converge on.
Alistair
>
> 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-19 3:45 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
2026-03-19 3:45 ` Alistair Francis [this message]
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='CAKmqyKP-42diNbiAwr_qykVTAYgR=Ok2S4dgLwPN5oGuLTQGRg@mail.gmail.com' \
--to=alistair23@gmail.com \
--cc=alistair.francis@wdc.com \
--cc=chao.liu.zevorn@gmail.com \
--cc=daniel.barboza@oss.qualcomm.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