On 10/21/2026 7:42 PM, Alistair Francis wrote: > On Wed, 2026-10-21 at 14:35 -0700, Pierrick Bouvier wrote: >> 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. > > Can we at least rename all of them then? >
I'm not sure to understand what is suggested. Is it to rename *all* riscv helpers to prefix them with riscv_, and not only the one required? > Ad hoc renaming just seems like the worst of all the options > Compilation (and linking) act as a safe barrier, so while it's not consistent, we can't introduce regression. Also, it's temporary. It will be gone in a few weeks. >> >> 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. > > Agreed > > Alistair > >> >> Regards, >> Pierrick
