On 10/22/2026 12:22 AM, Pierrick Bouvier wrote: > 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. >
I'll delay current series until the helper renaming is upstream, and repost it after. Regards, Pierrick
