Hi everyone,

We have been dealing with two sources of extensions information in
target/riscv/cpu.c:

- isa_edata_arr[]: an array that we must keep in riscv,isa ordering that
  also has priv_spec info;
- riscv_cpu_* arrays: used to set user properties and set defaults for
  rv32/rv64, among other users across the code.

The main issue here is the info being duplicated across arrays.  When
adding new extensions we go through a ritual of adding basically the
same stuff in both isa_edata_arr[] and riscv_cpu_extensions[].  We can
eventually forget to do all steps of that dance, resulting in patch 1.

The second issue is a desire for less abstractions.  An extension is
something that we report in riscv,isa, that might be exposed to users or
not, that might be a vendor or an experimental ext.  All these
distinctions don't require multiple distinct arrays.

I also made an effort to start moving away from the 'named features'
stuff we have going on.  A 'named feature' is just an extension that
most of the time isn't exposed to users, most of the time represents
innate TCG behavior, and sometimes have a different enable mechanism
aside from setting a flag to 'true'.  None of that is exclusive to this
class of extensions therefore I believe we should move away from it
over time.

There are more design simplifications I want to do in cpu.c and with CPUs
in general, but for now we can enjoy less lines to maintain.

Patches based on alistair/riscv-to-apply.next.


Changes from v1:
- added a new patch (patch 08) to handle riscv_cpu_update_misa_x().
  This solves a build break reported by Chao.
- v1 link: https://lore.kernel.org/qemu-devel/20260511132910.1738069-1-daniel.barboza@oss.qualcomm.com/ 

Daniel Henrique Barboza (14):
  target/riscv/cpu.c: add xlrbr isa_edata_arr[] entry
  target/riscv/cpu.c: fix smctr/ssctr isa_edata_arr[] order
  target/riscv: make riscv-qmp-cmds use isa_data_arr[]
  target/riscv/tcg: treat all exts equally in
    cpu_disable_priv_spec_isa_exts
  target/riscv/tcg: use only isa_edata_arr[] in cpu_cfg_ext_get_name()
  target/riscv/cpu.c: remove riscv_cpu_enable_named_feat()
  target/riscv: remove riscv_cpu_named_features[]
  target/riscv/tcg: use isa_edata_arr[] in riscv_cpu_update_misa_x()
  target/riscv/kvm: use isa_edata_arr[] for unavailable props
  target/riscv/tcg: use isa_edata_arr[] to enable max exts
  target/riscv/tcg: use cfg_offset as cpu_set_multi_ext cb opaque
  target/riscv: do not set defaults in cpu prop callback
  target/riscv/tcg: use isa_edata_arr[] to create user props
  target/riscv/cpu: remove riscv_cpu_* arrays

 target/riscv/cpu.c            | 315 ++++++++++++----------------------
 target/riscv/cpu.h            |  12 +-
 target/riscv/kvm/kvm-cpu.c    |  25 ++-
 target/riscv/riscv-qmp-cmds.c |  30 +---
 target/riscv/tcg/tcg-cpu.c    | 144 ++++------------
 5 files changed, 157 insertions(+), 369 deletions(-)

-- 
2.43.0

On Tue, May 12, 2026 at 1:30 PM Daniel Henrique Barboza
<daniel.barboza@oss.qualcomm.com> wrote:
>
> Hi everyone,
>
> We have been dealing with two sources of extensions information in
> target/riscv/cpu.c:
>
> - isa_edata_arr[]: an array that we must keep in riscv,isa ordering that
>   also has priv_spec info;
> - riscv_cpu_* arrays: used to set user properties and set defaults for
>   rv32/rv64, among other users across the code.
>
> The main issue here is the info being duplicated across arrays.  When
> adding new extensions we go through a ritual of adding basically the
> same stuff in both isa_edata_arr[] and riscv_cpu_extensions[].  We can
> eventually forget to do all steps of that dance, resulting in patch 1.
>
> The second issue is a desire for less abstractions.  An extension is
> something that we report in riscv,isa, that might be exposed to users or
> not, that might be a vendor or an experimental ext.  All these
> distinctions don't require multiple distinct arrays.
>
> I also made an effort to start moving away from the 'named features'
> stuff we have going on.  A 'named feature' is just an extension that
> most of the time isn't exposed to users, most of the time represents
> innate TCG behavior, and sometimes have a different enable mechanism
> aside from setting a flag to 'true'.  None of that is exclusive to this
> class of extensions therefore I believe we should move away from it
> over time.
>
> There are more design simplifications I want to do in cpu.c and with CPUs
> in general, but for now we can enjoy less lines to maintain.
>
> Patches based on alistair/riscv-to-apply.next.

Thanks!

Applied to riscv-to-apply.next

Alistair

>
>
> Changes from v1:
> - added a new patch (patch 08) to handle riscv_cpu_update_misa_x().
>   This solves a build break reported by Chao.
> - v1 link: https://lore.kernel.org/qemu-devel/20260511132910.1738069-1-daniel.barboza@oss.qualcomm.com/
>
> Daniel Henrique Barboza (14):
>   target/riscv/cpu.c: add xlrbr isa_edata_arr[] entry
>   target/riscv/cpu.c: fix smctr/ssctr isa_edata_arr[] order
>   target/riscv: make riscv-qmp-cmds use isa_data_arr[]
>   target/riscv/tcg: treat all exts equally in
>     cpu_disable_priv_spec_isa_exts
>   target/riscv/tcg: use only isa_edata_arr[] in cpu_cfg_ext_get_name()
>   target/riscv/cpu.c: remove riscv_cpu_enable_named_feat()
>   target/riscv: remove riscv_cpu_named_features[]
>   target/riscv/tcg: use isa_edata_arr[] in riscv_cpu_update_misa_x()
>   target/riscv/kvm: use isa_edata_arr[] for unavailable props
>   target/riscv/tcg: use isa_edata_arr[] to enable max exts
>   target/riscv/tcg: use cfg_offset as cpu_set_multi_ext cb opaque
>   target/riscv: do not set defaults in cpu prop callback
>   target/riscv/tcg: use isa_edata_arr[] to create user props
>   target/riscv/cpu: remove riscv_cpu_* arrays
>
>  target/riscv/cpu.c            | 315 ++++++++++++----------------------
>  target/riscv/cpu.h            |  12 +-
>  target/riscv/kvm/kvm-cpu.c    |  25 ++-
>  target/riscv/riscv-qmp-cmds.c |  30 +---
>  target/riscv/tcg/tcg-cpu.c    | 144 ++++------------
>  5 files changed, 157 insertions(+), 369 deletions(-)
>
> --
> 2.43.0
>
>