On 10/21/2026 2:27 PM, Yonggang Luo wrote: > 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. >
Hi Yonggang, It's one of the reason I preferred the ad hoc rename so far, not being sure the effort was worth the result. The original attempt you sent to fix this by renaming binary symbols using asm() is definitely too much magic to my taste. I hope the second attempt, source based, will be more satisfying, as it has very little magic (just relying on HELPER and HELPER_INFO macros). In all cases, this is a conversation that can happen in parallel of enabling more targets since reverting those renames is a pretty simple task. Regards, Pierrick
