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.
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. 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).
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.
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.
Regards,
Pierrick
