Re: [PATCH 10/12] target-info: add -target and program-name selection

On 8/26/2026 5:46 AM, Daniel P. Berrangé wrote:
> On Sun, Aug 23, 2026 at 11:07:28PM +0800, Yonggang Luo wrote:
>> - Parse -target before TargetInfo is fixed; CLI overrides the program
>>   basename.
>> - Tokens are target_name or target_name-be / -le; -target help lists
>>   registered names in sorted order.
>> - When -target is omitted, infer the token from g_get_prgname(): strip
>>   .exe, take the longest dash-separated registered suffix, and retry
>>   without a trailing w for Windows GUI binaries.
>> - A basename that matches no registered token falls through to the
>>   unique default. Combined binaries with no suffix require -target
>>   when more than one default TargetInfo is registered.
> 
> IMHO this -target argument and the target interference from
> program name is a mistaken direction.  We're being led off
> course by the attempt to make the new qemu-system be identical
> to qemu-system-$TARGET.
>

Heterogeneous emulation has been discussed for a very long time in the
community. The main breakthrough that we (precisely Philippe and I) made
in 2025 was to offer a simple path towards it. The approach is as simple
as "let's put the code together and make sure it links", and it worked
incredibly well, bringing our attention to all the details we needed to
take care of one after another. No more, no less.

By implementing *strict* identical behavior with existing binaries, we
indeed didn't add any new feature, but:
- we reduced total number of compilation units by 30%
- we cleaned up a lot of headers and did a lot of refactoring
- we have a systematic approach to add new targets in single-binary
while being able to reuse all existing tests without any change.

From my point of view, what you see as a detour was precisely what made
us progress so far in a year.

> If we ignore historical compat and treat qemu-system as a
> clean break, then I'd suggest that 'target' is not a concept
> to be exposed to the user at all.
>

If your only problem is with having a new -target option, I would be
happy to just keep the behavior to derive the target from current binary
name. That's a very small compromise on my side, and -target is just
here for convenience. It's not the end of the path.

> The user cares about the machine (and CPUs) they want to run,
> and their choice in this respect is what should determine the
> target(s) QEMU needs to enable. We should take
> 
>   qemu-system --machine vexpress-a15
> 
> that tells us we need the arm target. If we need to distinguish
> arm7 vs aarch64, then the choice of -cpu should determine 32
> bs 64 bit.
> 
> This extends better into the future world where we have
> machine type that could involve CPUs from multiple targets.
> 
> IOW machine config option / QOM class is what we should pivot
> off rather than a global target config option.
> 
> This likely implies that the MachineClass should gain a class
> method to query the QEMU_ARCH_XXXX bitmask required. Initially
> restricted to only a single target, so you can wire that through
> to the current global target info at startup. Later expanded to
> support multiple concurrent targets.
>

While it sounds nice on paper, you will be doomed to ambiguity with this:

qemu-system -machine virt -cpu max

What is your next plan? add an environment variable to solve it?
Name aliases that require us to use gdb or -d qom_debug to know what is
really instantiated?

Deriving target from argv(0) or -target is explicit, predictable, boring
and reliable, and it's exactly what we need now.

There are other paths for heterogeneous, and I would ask you some
patience, so we can talk about it at/after KVM Forum 2026, where I'll
present a talk about Heterogeneous emulation and some of our exploratory
ideas on how to run this.

Meanwhile, let's all focus on having a boring/predictable single-binary
please, and then we can all have fun reinventing the wheel.

> With regards,
> Daniel

Regards,
Pierrick