On Thu, 6 Mar 2025, Daniel P. Berrangé wrote:
On Thu, Mar 06, 2025 at 12:34:13PM +0100, Paolo Bonzini wrote:
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).
We could special case the '-kvm' suffix, because by its nature it
implies the current binary build target.
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).
If we did 'query-machines' on qemu-system-heterogeneous, it would
return all machines from all targets. To disambiguate naming there
are various options
* The query-machines command would have to gain a new 'target'
field and we would have to document that uniqness is across
the tuple (name, target), not merely name. That's a semantic
change.
We would still need a way to express the 'target' when asking
to instantiate a machine
* The query-machines command would have to gain a new 'target'
paramter so callers can restrict the data they receive back
We would still need a way to express the 'target' when asking
to instantiate a machine
* Rename all machine types so they are '<target>-<machine>'
The query-machines command doesn't change. Apps would have
to "parse" the machine name to see what 'target' each is
associated with, or we include an explicit 'target' field
in the returned data. Instianting a machine would not need
changing
I think -machine m68k:virt could work, -M help would list machines like:
arm:raspi
i386:pc
etc.
Management apps could easily find : to separate arch but those that don't
care about arch would just work and list more possible machines. Some
machines like pc or mac99 that may appear differently in different single
arch binary might need to get resolved first. Maybe need a way to search
machine list by pattern e.g. as -machine x86_64:help.
I tend to agree with Peter that if a multi binary qemu-system-arm would be
able to also create the 64 bit machines that's not a problem as long as
all the 32 bit machines still work the same. This would just make
qemu-system-arm and qemu-system-aarch64 the same or maybe you can set the
search pattern from command name so qemu-system-arm -M help would be the
same as qemu-system -M arm:help.
Allowing renaming binaries and still keep single arch behaviour probably
needs to keep a way to build single arch binaries so you can't convert
everything to runtime check and drop #ifdefs.
Regards,
BALATON Zoltan
* Require --target CLI arg, meaning query-machines remains
unchanged, as does instantiating machines
Any other options ?
The last is the simplest option if we just make --target be defaulted
based on the binary name.
With regards,
Daniel
