Il gio 6 mar 2025, 10:27 Philippe Mathieu-Daudé <phi...@linaro.org> ha
scritto:
> This API is to allow refactoring code for heterogeneous emulation,
> without changing user-facing behavior of current qemu-system binaries,
> which I now consider as 'legacy'.
>
> Once all current restrictions removed, the new qemu-system-heterogeneous
> binary is expected to run any combination of targets.
>
> qemu-system-$target will be a call to qemu-system-heterogeneous with
> a restricted subset, possibly in the form of:
>
> $ qemu-system-heterogeneous --target aarch64-softmmu
>
Or just qemu-system I guess.
^ equivalent of today's qemu-system-aarch64
>
> If you don't like 'qemu_legacy_binary_' prefix, I can use
> 'qemu_single_binary_' instead.
>
Still there is a problem with renaming binaries (both the "qemu-kvm" case
and the good/bad case that Richard pointed out).
I think you should try creating two versions of system/arch_init.c, so that
it has a separate implementation for heterogeneous vs. single-target
binaries. Then you can keep separate linking steps for single-target
binaries and you naturally get the right target info from either the
target-specific arch_init-single.c, or the --target option for
arch_init-multi.c.
(Is --target even necessary? As long as you have a way disambiguate
same-named machines like -M virt, and have no default machine in the
multi-target binary, you shouldn't need it).
target_is_64bit() is misleading, for example in:
>
> $ qemu-system-aarch64 -M zynqmp
>
> we create 64-bit and 32-bit ARM cores.
>
Agreed, bit size and endianness should only matter in the CPU code.
Paolo
>
