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

[BALATON Zoltan <balaton@eik.bme.hu>]

[-- Attachment #1: Type: text/plain, Size: 4105 bytes --]

On Thu, 6 Mar 2025, Daniel P. Berrangé wrote:
> 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

I think -machine m68k:virt could work, -M help would list machines like:

arm:raspi
i386:pc
etc.

Management apps could easily find : to separate arch but those that don't 
care about arch would just work and list more possible machines. Some 
machines like pc or mac99 that may appear differently in different single 
arch binary might need to get resolved first. Maybe need a way to search 
machine list by pattern e.g. as -machine x86_64:help.

I tend to agree with Peter that if a multi binary qemu-system-arm would be 
able to also create the 64 bit machines that's not a problem as long as 
all the 32 bit machines still work the same. This would just make 
qemu-system-arm and qemu-system-aarch64 the same or maybe you can set the 
search pattern from command name so qemu-system-arm -M help would be the 
same as qemu-system -M arm:help.

Allowing renaming binaries and still keep single arch behaviour probably 
needs to keep a way to build single arch binaries so you can't convert 
everything to runtime check and drop #ifdefs.

Regards,
BALATON Zoltan

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