On Thu, 6 Mar 2025, Pierrick Bouvier wrote:
On 3/6/25 07:28, BALATON Zoltan wrote:
On Thu, 6 Mar 2025, Daniel P. Berrangé wrote:
On Thu, Mar 06, 2025 at 02:45:52PM +0100, BALATON Zoltan wrote:
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.
...except that custom structures/formats in command line args is
something we've tried very hard to eliminate in Qemu, and instead
model everything as a distinct fields, using QAPI, so...
.. if you're meaning "arm:raspi" as a short hand for "target:machine"
that would be a design anti-pattern, b
...if you're meaning that "arm:raspi" is the full machine name, to be
strictly treated as an opaque string that would be acceptable.
I rather think the latter would not end up being treated as an opaque
string though - the tempetation to parse it & assign semantics to the
pieces is just too great. So I'm not a fan of that approach.
From a QAPI design best pratice POV, the requirement would be for
-machine target=arm,name=raspi
As long as I don't have to type that and can use -M arm:raspi as a
shorthand that's OK but then we could just make an exception for this and
combine target and machine name here for simplicity. Unless it's simpler
to internally use separate name and target attributes and implement a
command line shorthand. You'll also need a way to display machine list
with target and name in a way that's easy to parse for tools for which the
target:name format seems like a trivial way. So I don't mind how you
rationalise it and call all of it the machine name or if it's implemented
as separate name and target attributes but please try to keep the command
line something a human can use too.
Mentioning heterogeneous emulation (i.e., running various cpu architectures
concurrently in the same process) is an interesting topic, but it's way far
beyond the scope of current series, I feel that everyone starts to get lost a
bit here.
The above wasn't about heterogenous emulation but about single binary.
That still needs a way to select the machine to emulate.
Creating a single binary combining all existing QEMU architectures should
*not* have any impact on the existing cli. It's just a code reorganisation,
without any user visible change. Please notice it's just a single binary, not
something introducing heterogeneous emulation.
A missing piece in this series is a new driver (i.e. a new main()) forwarding
(argc, argv) to the correct entry point, and adding an option '--target' to
allow people to override or disambiguate the automatically detected target.
So it would have impact on existing CLI as it needs introducing at least
one new option. Please note QEMU options are single dash so this could be
-target or -T for short then one could do qemu-system -T arm -M raspi.
This is another possible CLI for this. For machines that only exist in one
arch the target option may not be needed.
This detection will be based on symlink name used to invoke the binary. For
the binary itself, why not simply call it: ./qemu, or ./qemu-system (if the
scope is only system emulation).
This might not work if people want to rename the symlinked name although
checking only the prefix could solve that.
To come back to heterogeneous topic, even though we can be sure everyone will
have an opinion on the command line interface for that, I'm not sure this is
the first question we should answer. There are more important technical
questions and refactorings to solve, before even thinking about how to use
it.
We haven't discussed heterogenous emulation yet and what exact command
line syntax to use can wait but discussing what command line option is
needed and how to represent it might influence how the internal
implementation will be or how easy it will be to implement such command
line so it's good to consider that now as it may influence the design.
You'll need to store target somewhere so the command line can list it or
select it so deciding if it should be an Object property or Machine or
Device property might also have impact on the possible command line syntax
and vice versa so maybe it's not something you can totally ignore.
A simple and good first step could be to have a "magical" board combining
different processing units having different architectures. Having this will
already imply to tackle a lot of technical issues. Then, maybe, it will be
productive to debate about what the command line interface should look like
to have something generic. Maybe it's not even something we'll need.
This isn't something that was discussed above and I agree it's not
something to discuss yet.
Regards,
BALATON Zoltan
