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.
