On Thu, 2026-10-22 at 00:22 -0700, 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?
Yeah, everything should be consistent. I don't really care what the answer is, just that it's consistent > > > 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. Oh, that's not too bad then I guess Alistair > > > > > > > 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 >
