On Tue, Apr 29, 2025 at 11:35:52AM +0200, Philippe Mathieu-Daudé wrote:
> 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.
IMHO QEMU ought to just "do the right thing" with a qemu-kvm
binary out of the box.
If we define a clear naming scheme of 'qemu-system-$TARGET" for picking
a non-default target, then we can declare anything not following that
scheme should assume native build target and thus 'just work'.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
