On Thu, Oct 22, 2026 at 2:27 AM Pierrick Bouvier
<[email protected]> wrote:
>
> On 10/16/2026 4:22 PM, Pierrick Bouvier wrote:
> > This series adds this target to set of multi-target.
> > Changes are straightforward: functions and helpers renaming, and one type
> > restriction for this target only.
> >
> > While the series applies cleanly, it will need those additional two series
> > to
> > build multi-target test binary:
> >
> > - Based-on: [email protected]
> > "multi-target: remove dump functions duplication"
> > - Based-on: [email protected]
> > "multi-target: remove qmp_query_cpu_model_expansion duplication"
> >
> > Usually I prefer to wait for series to be merged, but I have good hope to
> > catch
> > the freeze date if current series is reviewed, and send all three at once.
> >
> > v2
> > --
> >
> > - make virt machine only available for riscv targets
> > - enhance multi-target test to detect duplicated types between all targets
> > (we
> > missed the virt machine since we were always picking the first target
> > avail)
> > - add an additional commit with the rest of softmmu commented for future
> > work
> >
> > Pierrick Bouvier (9):
> > target-info: add target_base_riscv
> > hw/riscv/virt: make machine available for riscv targets only
> > test/unit/multi-target: check QOM types can be initialized with any
> > target
> > hw/riscv/virt: restrict scope of virt_is_acpi_enabled to this file
> > target/riscv: rename virt_acpi_setup to riscv_virt_acpi_setup
> > target/riscv: prefix helpers conflicting with other arch
> > target/riscv/tcg: restrict tcg-accel-riscv-cpu to riscv targets
> > meson.build: add riscv64-softmmu to multi-target
> > meson.build: list all remaining softmmu targets as comments
> >
> > hw/riscv/virt-acpi-build.c | 2 +-
> > hw/riscv/virt.c | 14 ++++----
> > include/hw/riscv/virt.h | 3 +-
> > include/qemu/target-info.h | 7 ++++
> > meson.build | 18 ++++++++++
> > target-info.c | 11 ++++++
> > target/riscv/helper.h | 24 ++++++-------
> > target/riscv/tcg/bitmanip_helper.c | 4 +--
> > target/riscv/tcg/fpu_helper.c | 16 ++++-----
> > .../tcg/insn_trans/trans_privileged.c.inc | 2 +-
> > target/riscv/tcg/insn_trans/trans_rvd.c.inc | 8 ++---
> > target/riscv/tcg/insn_trans/trans_rvf.c.inc | 8 ++---
> > target/riscv/tcg/insn_trans/trans_rvi.c.inc | 4 +--
> > .../tcg/insn_trans/trans_rvzicfiss.c.inc | 2 +-
> > target/riscv/tcg/insn_trans/trans_xlrbr.c.inc | 4 +--
> > target/riscv/tcg/op_helper.c | 4 +--
> > target/riscv/tcg/tcg-cpu.c | 1 +
> > target/riscv/tcg/translate.c | 4 +--
> > tests/unit/test-multi-target.c | 34 ++++++++++++++-----
> > 19 files changed, 113 insertions(+), 57 deletions(-)
> >
>
> Except if there are specific comments, I'll send it as a PR tomorrow,
> with the two companions based-on series, and with the current helper
> renaming, as there was no comment on general helper renaming. Helpers
> renaming can be reverted as part of general helper series.
Hi Pierrick
I personally feel a general helper introduced too much magic, I think
helpers renaming is fine.
If we want sharing a name, a more make sense way is refactoring them
have same behavior, such
as add/div/mul.
>
> Regards,
> Pierrick
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
