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: Fri, 13 Mar 2026 11:09:57 +1000 [thread overview]
Message-ID: <CAKmqyKOcCKAb2w2t2qYgOevswst75FjzKfihrYP9+odRAsCQmw@mail.gmail.com> (raw)
In-Reply-To: <abKfuTO7zg5d67E8@sifive.com>
On Thu, Mar 12, 2026 at 9:16 PM Max Chou <max.chou@sifive.com> wrote:
>
> On 2026-03-09 14:51, Alistair Francis wrote:
> > On Fri, Mar 6, 2026 at 5:13 PM Max Chou <max.chou@sifive.com> wrote:
> > >
> > > This patch series adds support for the RISC-V Zvfbfa extension, which
> > > provides additional BF16 vector compute support.
> > >
> > > The isa spec of Zvfbfa extension is not ratified yet, so this patch
> > > series is based on the latest draft of the spec (v0.1) and make the
> > > Zvfbfa extension as an experimental extension.
> >
> > It's not only not ratified, there isn't even a draft spec. A personal
> > GitHub repo without any tags or releases is not enough for us to take
> > this unfortunately.
> >
> > >
> > > The Zvfbfa extension adds a 1-bit field, altfmt, to the vtype CSR in
> > > bit position 8.
> > > The Zvfbfa extension requires the Zve32f and Zfbfmin extensions.
> > >
> > > Specification:
> > > https://github.com/aswaterman/riscv-misc/blob/main/isa/zvfbfa.adoc
> >
> > Overall this looks ok. Once a draft spec is released we can apply it
> >
> > Alistair
> >
>
> Hi Alistair,
>
> Thanks for the review. You asked for a pointer to the standalone ISA
> spec repo for Zvfbfa — I want to explain why that doesn’t exist and
> where the spec lives instead.
>
> RVIA changed the ISA development workflow: new ISA specifications are
> no longer developed in standalone repositories. Instead, they are
> developed as forked branches of the base ISA manual repo
> (riscv/riscv-isa-manual) and merged into it upon ratification [1].
That's fine. The details you point to show forking to a RISC-V org
GitHub account. In which case it's still clearly a RISC-V spec, under
RVI. As long as it's tagged for draft releases that isn't really any
different then before.
>
> For Zvfbfa specifically, the official spec artifact under this new
> workflow is a PR against riscv-isa-manual [2], incorporating the spec
> text [3]. The PR notes that the spec has passed internal review and
> ARC review, as documented in the tech-unprivileged list thread [4].
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
>
> Please let me know how you would like to proceed.
>
> References:
> [1] https://lists.riscv.org/g/sig-documentation/message/275
> [2] https://github.com/riscv/riscv-isa-manual/pull/2743
> [3] https://github.com/aswaterman/riscv-misc/blob/main/isa/zvfbfa.adoc
> [4] https://lists.riscv.org/g/tech-unprivileged/message/1031
> https://lists.riscv.org/g/tech-unprivileged/message/1085
> https://lists.riscv.org/g/tech-unprivileged/message/1109
>
> Best regards,
> rnax
>
next prev parent reply other threads:[~2026-03-13 1:11 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 [this message]
2026-03-16 8:28 ` Max Chou
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=CAKmqyKOcCKAb2w2t2qYgOevswst75FjzKfihrYP9+odRAsCQmw@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