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? Ad hoc renaming just seems like the worst of all the options > > 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
