include/exec/translation-block.h | 1 + target/riscv/cpu.c | 15 +- target/riscv/cpu.h | 7 +- target/riscv/cpu_cfg_fields.h.inc | 1 + target/riscv/helper.h | 60 ++ target/riscv/insn_trans/trans_rvv.c.inc | 988 +++++++++++++++--------- target/riscv/internals.h | 1 + target/riscv/tcg/tcg-cpu.c | 15 +- target/riscv/translate.c | 11 + target/riscv/vector_helper.c | 389 +++++++++- 10 files changed, 1088 insertions(+), 400 deletions(-)
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.
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
Changes in v5:
- Fix typo in patch 1/5/8
- Remove unnecessary do_bf16_nanbox
Changes in v4:
- Rebase on riscv-to-apply.next (commit 21101a7)
- Update commit message of patch 2 (target/riscv: Add the Zvfbfa
extension implied rule)
- Update checking flow of illegal ALTFMT SEW patterns at patch 3
(target/riscv: rvv: Add new VTYPE CSR field - altfmt)
Changes in v3:
- Rebased on riscv-to-apply.next (commit f66f234)
- Fix typo in v2 patch 5 commit message
Changes from v2:
- Removed RFC designation from the series
- Updated commit message for patch 3 (VTYPE CSR field -
altfmt) to clearly explain:
* VEDIV field removal (bits 8-9) since EDIV extension is not
planned to be part of the base V extension
* ALTFMT field addition at bit 8
* RESERVED field change from bit 10 to bit 9
- Added new patch 4: Introduce reset_ill_vtype helper function to
consolidate illegal vtype CSR reset logic
v4: <20260304132514.2889449-1-max.chou@sifive.com>
v3: <20260127014227.406653-1-max.chou@sifive.com>
v2: <20260108132631.9429-1-max.chou@sifive.com>
v1: <20250915084037.1816893-1-max.chou@sifive.com>
rnax
Max Chou (9):
target/riscv: Add cfg properties for Zvfbfa extensions
target/riscv: Add the Zvfbfa extension implied rule
target/riscv: rvv: Add new VTYPE CSR field - altfmt
target/riscv: rvv: Introduce reset_ill_vtype to reset illegal vtype
CSR
target/riscv: Use the tb->cs_base as the extend tb flags
target/riscv: Introduce altfmt into DisasContext
target/riscv: Introduce BF16 canonical NaN for Zvfbfa extension
target/riscv: rvv: Support Zvfbfa vector bf16 operations
target/riscv: Expose Zvfbfa extension as an experimental cpu property
include/exec/translation-block.h | 1 +
target/riscv/cpu.c | 15 +-
target/riscv/cpu.h | 7 +-
target/riscv/cpu_cfg_fields.h.inc | 1 +
target/riscv/helper.h | 60 ++
target/riscv/insn_trans/trans_rvv.c.inc | 988 +++++++++++++++---------
target/riscv/internals.h | 1 +
target/riscv/tcg/tcg-cpu.c | 15 +-
target/riscv/translate.c | 11 +
target/riscv/vector_helper.c | 389 +++++++++-
10 files changed, 1088 insertions(+), 400 deletions(-)
--
2.52.0
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 > > Changes in v5: > - Fix typo in patch 1/5/8 > - Remove unnecessary do_bf16_nanbox > > Changes in v4: > - Rebase on riscv-to-apply.next (commit 21101a7) > - Update commit message of patch 2 (target/riscv: Add the Zvfbfa > extension implied rule) > - Update checking flow of illegal ALTFMT SEW patterns at patch 3 > (target/riscv: rvv: Add new VTYPE CSR field - altfmt) > > Changes in v3: > - Rebased on riscv-to-apply.next (commit f66f234) > - Fix typo in v2 patch 5 commit message > > Changes from v2: > - Removed RFC designation from the series > - Updated commit message for patch 3 (VTYPE CSR field - > altfmt) to clearly explain: > * VEDIV field removal (bits 8-9) since EDIV extension is not > planned to be part of the base V extension > * ALTFMT field addition at bit 8 > * RESERVED field change from bit 10 to bit 9 > - Added new patch 4: Introduce reset_ill_vtype helper function to > consolidate illegal vtype CSR reset logic > > v4: <20260304132514.2889449-1-max.chou@sifive.com> > v3: <20260127014227.406653-1-max.chou@sifive.com> > v2: <20260108132631.9429-1-max.chou@sifive.com> > v1: <20250915084037.1816893-1-max.chou@sifive.com> > > rnax > > > Max Chou (9): > target/riscv: Add cfg properties for Zvfbfa extensions > target/riscv: Add the Zvfbfa extension implied rule > target/riscv: rvv: Add new VTYPE CSR field - altfmt > target/riscv: rvv: Introduce reset_ill_vtype to reset illegal vtype > CSR > target/riscv: Use the tb->cs_base as the extend tb flags > target/riscv: Introduce altfmt into DisasContext > target/riscv: Introduce BF16 canonical NaN for Zvfbfa extension > target/riscv: rvv: Support Zvfbfa vector bf16 operations > target/riscv: Expose Zvfbfa extension as an experimental cpu property > > include/exec/translation-block.h | 1 + > target/riscv/cpu.c | 15 +- > target/riscv/cpu.h | 7 +- > target/riscv/cpu_cfg_fields.h.inc | 1 + > target/riscv/helper.h | 60 ++ > target/riscv/insn_trans/trans_rvv.c.inc | 988 +++++++++++++++--------- > target/riscv/internals.h | 1 + > target/riscv/tcg/tcg-cpu.c | 15 +- > target/riscv/translate.c | 11 + > target/riscv/vector_helper.c | 389 +++++++++- > 10 files changed, 1088 insertions(+), 400 deletions(-) > > -- > 2.52.0 > >
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].
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].
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.
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
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 >
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
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
On 2026-03-19 13:45, Alistair Francis wrote: > 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. > Hi Alistair, The official riscv-isa-manual repository has added a new tag for the frozen Zvfbfa v0.9, as shown below: https://github.com/riscv/riscv-isa-manual/releases/tag/zvfbfa-0.9 The current v5 implementation fully complies with this frozen specification. Since the Zvfbfa is frozen, should I prepare a v6 that removes the “x-“ prefix from the zvfbfa property and updates the specification reference ? Thanks, rnax > 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
On Thu, Mar 26, 2026 at 11:42:58AM +0800, Max Chou wrote: > On 2026-03-19 13:45, Alistair Francis wrote: > > 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. > > > > Hi Alistair, > > The official riscv-isa-manual repository has added a new tag for the > frozen Zvfbfa v0.9, as shown below: > > https://github.com/riscv/riscv-isa-manual/releases/tag/zvfbfa-0.9 > > The current v5 implementation fully complies with this frozen > specification. > > Since the Zvfbfa is frozen, should I prepare a v6 that removes the “x-“ > prefix from the zvfbfa property and updates the specification reference > ? I think we need a v6 series, usually it's fine to implementation after spec tag is release. That said, we should defer to Alistair's thoughts on this. Additionally, my new debug spec series can be sent upstream later (base on the zvfbfa tb ext_flag patch), once zvfbfa ia all ready and pulled. Thanks, Chao > > Thanks, > rnax > > > 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
© 2016 - 2026 Red Hat, Inc.