Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common

["Daniel P. Berrangé" <berrange@redhat.com>]

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.bouvier@linaro.org> writes:
> > 
> > > On 4/28/25 4:07 AM, Markus Armbruster wrote:
> > > > Peter Krempa <pkrempa@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-philmd@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 :|