Re: [RFC PATCH 04/18] qemu: Introduce 'qemu/legacy_binary_info.h'

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

On Thu, Mar 06, 2025 at 12:34:13PM +0100, Paolo Bonzini wrote:
> Il gio 6 mar 2025, 10:27 Philippe Mathieu-Daudé <philmd@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

  * Require --target CLI arg, meaning query-machines remains
    unchanged, as does instantiating machines

Any other options ?

The last is the simplest option if we just make --target be defaulted
based on the binary name.

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 :|