On 29/4/25 10:23, Markus Armbruster wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:
On 4/28/25 4:07 AM, Markus Armbruster wrote:
Peter Krempa <pkre...@redhat.com> writes:
So what should libvirt do once multiple targets are supported?
How do we query CPUs for each of the supported targets?
It's kind of a similar question we have to solve now with QEMU code.
What happens when a symbol is duplicated, and available only for several
targets?
In this case, we found various approaches to solve this:
- unify this symbol for all targets (single implementation)
- unify all targets to provide this symbol (multiple impl, all targets)
- rename symbols adding {arch} suffix, so it's disambiguated by name
- create a proper interface which an available function (multiple impl,
selective targets)
In the case of query-cpu-definitions, my intuition is that we want to
have a single implementation, and that we return *all* the cpus, merging
all architectures. In the end, we (and libvirt also) should think out of
the "target" box. It's an implementation detail, based on the fact QEMU
had 'targets' associated to various binaries for a long time and not a
concept that should leak into all consumers.
Will the result be the same if we query them one at a time or all at
once?
Pierrick's stated goal is to have no noticable differences between the
single binary and the qemu-system-<target> it covers. This is obviously
impossible if we can interact with the single binary before the target
is fixed.
Right.
At this point, we can guarantee the target will be fixed before anything
else, at the start of main(). It's obviously an implementation choice,
but to be honest, I don't see what we would gain from having a "null"
default QEMU target, unable to emulate anything.
This requires fixing the target before introspection. Unless this is
somehow completely transparent (wrapper scripts, or awful hacks based on
the binary's filename, perhaps), management applications may have to be
adjusted to actually do that.
As noted filename will not work. Users can specify any filename and
create override scripts or rename the binary.
True.
I would prefer to not open this pandora box on this thread, but don't
worry, the best will be done to support all those cases, including
renaming the binary, allowing any prefix, suffix, as long as name stays
unambiguous. If you rename it to qemu-ok, how can you expect anything?
We can provide the possibility to have a "default" target set at compile
time, for distributors creating their own specific QEMU binaries. But in
the context of classical software distribution, it doesn't make any sense.
I don't wish to derail this thread, but we've been dancing around the
question of how to best fix the target for some time. I think we should
talk about it for real.
Mind, this is not an objection to your larger "single binary" idea. It
could be only if it was an intractable problem, but I don't think it is.
You want the single binary you're trying to create to be a drop-in
replacement for per-target binaries.
"Drop-in replacement" means existing usage continues to work.
Additional interfaces are not a problem.
To achieve "drop-in replacement", the target needs to be fixed
automatically, and before the management application can further
interact with it.
If I understand you correctly, you're proposing to use argv[0] for that,
roughly like this: assume it's qemu-system-<target>, extract <target>
first thing in main(), done.
What if it's not named that way? If I understand you correctly, you're
proposing to fall back to a compiled-in default target.
I don't think this is going to fly.
Rather than using non-constant argv[0] Pierrick suggested to add a
single CLI option '-target' which selects the corresponding TargetInfo
structure to use at runtime. I.e. for ARM:
https://lore.kernel.org/qemu-devel/20250424222112.36194-12-phi...@linaro.org/
For distros qemu-system-arm could be a shell script prepending
'-target arm' while passing the arguments calling qemu-system.
If a distro wants to name a binary 'qemu-kvm' it can drop the
-target option and hard-wire its target_info() to a distro-specific
TargetInfo implementation, or &target_info_x86_64_system.
Developers rename the binary all the time, and expect this not to change
behavior. For instance, I routinely rename qemu-FOO to qemu-FOO.old or
qemu-FOO.COMMIT-HASH to let me compare behavior easily.
We could relax the assumption to support such renames. Developers then
need to be aware of what renames are supported. Meh.
The more we relax the pattern, the likelier surprising behavior becomes.
We could mitigate surprises by eliminating the built-in default target.
Users invoke their binaries with their own names, too. If Joe R. User
finds qemu-system-<joe's-fav-target> too much to type, and creates a
symlink named q to it, more power to him!
Distributions have packaged renamed binaries. qemu-kvm has been used
quite widely.
In neither of these cases, relaxing the pattern helps.
The least bad solution I can see so far is a new option -target.
Ah! Same same.
Instead of turning the target-specific binaries into links to / copies
of the single binary, they become wrappers that pass -target as the
first option. We need to make sure this option is honored in time then,
which should be easy enough.
If you invoke the single binary directly, you need to pass -target
yourself. If you don't to pass it, or pass it late in the command line,
you open up a window for interaction with indeterminate target.
Target-specific interfaces could exhibit different behavior then, even
fail. That's fine under "additional interfaces are not a problem".
Thoughts?
